4 ms·
As usual it boils down to the right tool for the job. Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will hav
by Hedepig 6y ago
As usual it boils down to the right tool for the job.
Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.
Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
- TeMPOraL 6y agoI thought about it a lot, and realized there's one big obstacle for Emacs to be as close to a silver bullet as you can get - reconciling the following needs: - Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI. - Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other. - Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web. The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot). Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM. (And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)