I've been using Emacs for more than 20 years, these are all (for the most part) non-issues, brought up by folks who either are new to Emacs or never read the documentation / dived below the surface.
1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea.
2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK).
3. There are multiple ways to do this. Read up on setting the mark.
4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes".
5. SVG support is already there and more is on the pipeline.
What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out.
Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")
> What I've noticed in my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out.
The problem is being used to software that "just works".
I've tried out to figure out how to to stuff with Emacs multiple times, but apart from sticking with org-mode for some use cases, I always have up after a while.
I don't see why I should "master Emacs" when there are usually better tools for any given task.
I resisted switching (from vim to emacs) for a long time, but it's just not true that "there are usually better tools for any given task": magit and the other git integrations in emacs are significantly better than the equivalents in VSCode or IntelliJ (anecdotal, but I've never had issues figuring out version control in emacs whereas I've made significant messes trying to use the VC features of VSCode and IntelliJ); the ad-hoc programmability of emacs is second to none (just the other day I whipped up a quick one-off refactoring tool to fill in names missing in the LSP diagnostic errors: other editors might have an equivalent feature, but nothing makes it as easy to combine features in ad-hoc fashions as emacs). notmuch is, so far, the best email interface I've found. And, I could go on: I've occasionally tried switching back to "normal" editors, but each time I find that I'm missing some configuration that was trivial to put together in my emacs configuration and is only available in my new editor if I'm willing to make significant compromises.
Emacs is a tool with an enormous set of available functionality that has been continuously developed for 35 years. Moreover, its major strength is its programmable and nearly infinitely-extensible nature.
And yet, it does "just work", from the moment you first run it -no previous experience needed- it does present you with a familiar "editor skin". It does offer you an interactive tutorial. It does come with comprehensive offline documentation. It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.
So, taking all of that into account, when you say "just works", I read "I don't want to spend any time whatsoever to learn 35 years of features and a software system that is by far the most user-empowering in existence today". Your loss.
:facepalm:
Yeah, my 8 years old niece will be taught "Informatics" in the school. Starting in a few days, actually. I'm sure she will enjoy Emacs over Notepad, since Notepad doesn't have any interactive tutorial.
> It does come with comprehensive offline documentation.
To avoid using precisely that, some years ago, I created myself a little extension of the engine-mode which opens up a browser and searches on the internet using a proper search engine. Here's the code:
https://github.com/Bost/dotfiles/blob/c262e4dd7c5a498ce5d75c...
Enjoy
> It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.
I managed to learn how to write my own plugins, macros, spacemacs core extensions, etc. I hope one day I'll learn how to use the emacs interactive documentation, too. Eventually.
Emacs is definitely not a SW to use if you're not going to read the docs. There's no good argument that Emacs should be, especially given what you say:
> I don't see why I should "master Emacs" when there are usually better tools for any given task.
I use Emacs for all kinds of things - not just programming. If I pick any one, there's definitely a better tool out there. Emacs's strength is the ability to tie it all together. If all a person wants is a good text editor, I would not recommend Emacs to them. Emacs is one of those things where you get more out of it the more you invest in it.
And it's totally reasonable to decide not to invest in it.
I guess that's what might be the difficulty for newcomers: having an idea of what exactly I could use Emacs for that justifies the high upfront investment compared to other tools with a more familiar UI.
Doom Emacs and other distros are great because they allow to just dive in with minimal configuration effort and sensible defaults. Without it, I certainly wouldn't have started using org-mode.
It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.
> It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.
It isn't. You could just go through the included tutorial for Emacs, and watch a tutorial for org, and you'll immediately be productive in org.
And you definitely don't need to learn elisp. I was a power user for almost a decade before I learned elisp. The most I could do was use setq.
The point of my comment was that one can easily be productive in Emacs, but if you want to do things that set Emacs apart from other tools, you'll need to go further and read more docs. Someone could learn just the basics and write documents/code with Emacs fairly quickly. But those people will continually ask "What's the point - I could just use an IDE which follows semantics I'm used to."
Doom/Spacemacs are great - just not for everyone. It's good to have them around, and it's good to have better defaults in vanilla Emacs. However, there are a lot of config choices they made that I guarantee would have turned me away from them as a newbie.[1] They are a lot more opinionated than vanilla Emacs, and would likely turn off as many new users as they will attract.
But it's good to have more options.
[1] For one, I could never wrap my head around vi keybindings - and I tried them before I tried Emacs.
2. It makes perfect sense if you actually learn how Emacs works. It provides superficial elements like GTK-look-and-feel (scrollbars, menubars). Most Emacs experts disable all of these anyway, thus nothing of value is lost. On the other hand, toolkit-less Emacs tends to be a lot more stable. That was definitely the case for GTK since it had well-known bugs that the GTK developers refused to fix that would crash Emacs. I suggest you compile graphical Emacs on Linux without any toolkit (or with Athena/Lucid/Motif) to see for yourself.
3. Because there are trade-offs involved and the (informed) user should be responsible for enabling them.
The fact there are known workarounds for certain problems shouldn't prevent us improving and fixing the underlying causes (in a step-by-step, backwards-compatible way).
With that said, I'd rather not see Emacs go all-in on threads or GTK, since they generally feel like WorseIsBetter anti-patterns:
- GTK 2 seemed OK, but unusable for me due to the 'display disconnection' bug. GTK 3 is full of red flags: a constantly moving target, little thought given to third-party applications, pretty much killed off third-party theming, etc.
- Threading is famously error-prone, which is completely unnecessary for high-level languages like Emacs Lisp. Co-routines, async/await macros, delimited continuations; even an actor model would all seem like better fits.
GTK3 is actually feature frozen, it's not a moving target. Development has moved to GTK4. Also, it has always supported third party themes, however the convention is that they were always considered unsupported because they can break apps.
Similar age, back in 1995 XEmacs was my refuge, because most UNIX world was foreign territory for IDEs and developer editors like Ultraedit.
With the way UNIX landscape evolved, I seldom use it, although the last time I used it in anger was around 2006, the muscle memory is still there, but really, the IDEs I missed in 1995 are now available everywhere.
1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea.
2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK).
3. There are multiple ways to do this. Read up on setting the mark.
4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes".
5. SVG support is already there and more is on the pipeline.
What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out.
Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")