As a die-hard Emacs user, this is also something that has been occupying me lately. There is too little thought going into the deficits of Emacs; many people I convinced to give it a try went back to Sublime, VSCode etc. Emacs has two main shortcomings, in my opinion. The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors; Emacs completely ignored these. The main argument has always been "won't work in a tty", but there should come a point where tty is deprecated or at least treated differently. The other is evolving the language. Elisp was great for its time, but compared to modern languages its age clearly shows. There are no namespaces, it can be dead slow, support for networking is limited, regular expressions are weird etc. I think there should be more work going into modernizing the language, which can also be used to introduce facilities for GUI elements and networking code, especially async.

I strongly believe that TTY compatibility is a feature which should not be discarded. But that doesn't, I think, prevent the kind of features you mention: they just need to be first-class UI features like the minibar is.

Agreed that Elisp needs to be upgraded. I think that it should just be replaced with Common Lisp, which has namespaces (packages), and is very fast, and whose implementations support networking & threads just fine. Of note, part of why Emacs regexps are so unusual is that they are pragmatic: since they will be used to match Lisp source so often, () are not the metachars they are in other regexp dialects.

> Emacs regexps are so unusual

Parentheses are also not metachars in Vi (and Vim) regexps by default, and are not metachars in POSIX BRE (basic regular expressions).

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

The grep utility, for instance, understands BREs by default; you must use grep -E to get ERE (extended regex) in which ( and ) are grouping characters, or else the deprecated egrep command (not in POSIX).

> Emacs has two main shortcomings, in my opinion.

Eh, no.

Emacs has a shitload of bugs (sorry for the language), and an ad-hoc configuration and package installation that inevitably turns your Emacs installation into a bespoke ball of mud.

(Goes in hand with 'malleability', I guess, but still a very subpar user experience.)

I'm not going to "defend" Emacs here, it's a piece of software and you use it if it suits your purposes, but I find it to be quite stable for the feature set it offers. Also if you put moderate effort into it, it's possible to achieve a reproducible packaging and configuration state. I can check out my .emacs.d (https://github.com/afroisalreadyinu/emacsd/) on any Linux computer, start Emacs and work on it as if it's my own computer.

I spend most my time in emacs; my experience is it's pretty buggy. Probably mostly packages & their interactions than emacs per se, but for me emacs is all about the customizability & the packages...

Yeah there's this dilemma. Emcas, out of the box, seems stable enough (and performs well enough?). But for many of us, the features it offers ootb are nowhere near enough. So you start installing packages and it quickly turns into a clusterfuck and you have bizarre little bugs and interactions everywhere. And it still doesn't work exactly the way you want, even if the bugs were not present.. so you have to spend a huge amount of time trying to figure the clusterfuck out so that you can start working on it and make it right. And figure out why it got slow. Or sigh and give up.

It isn't helped by the fact that some devs insist on using bleeding edge melpa packages and their stable versions are broken. Other devs' bleeding edge versions are prone to break..

Emacs, with its packages, is one of the most chaotic things I've seen. I don't know if there's any hope for me to tame it in a reasonable timeframe.

Ha, yeah, you've captured it nicely. I have a TODO list 25 items long of problems to try to track down; occasionally I'll pick one off, but I think the list is growing faster than it's shrinking.

It's an open question, but I suspect it's not impossible to have both a robust and flexible system...think Emacs, but instead of the wild-west of Lisp as the extension language, something more in the vein of Rust...

Since you use evil.. does term-char-mode work? Can you send C-x or C-z to the application? (without a workaround like (term-send-raw-string "^X"))

> The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors;

What do you mean? Emacs has them too, just not nice ones. Also, emacs is not an IDE, so there is some limit on what kind of interfaces people will build.

But yes, the GUI-parts of emacs are a big liability for future growing. While emacs does has offer all the nice visual tweaks, they also all sucks because of bad implementation and limitations in emacs itself.

I do love the fact that emacs runs on a TTY, though. It means that useful programs in emacs are useful TTY programs. For instance, the ebook reader, nov.el, is the best available epub reader for the TTY right now. It would be awful to lose that.

The defaults. They aren't very good, IMO. Many users don't want to spend time with customizing, they want a system which works instantly with language plugins, and so on. VSCode does a very good job at that.

Emacs is for people who like to deeply personalize their editors. That's why I use it. But it takes time and learning elisp and many people are unwilling to do that.

But I believe people trying emacs are attracted by it because something in them makes them crave customization above out-of-the-box productivity.

My theory is that the awful defaults are a test: a baptism of (pretty ugly) fire. It's designed to make you take one look and walk away in amused bewilderment... which I'd say is the right choice for most people! People want "it just works tm". Emacs is not that kind of application.

If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.

I’m not sure this is true. The enormity of the amount of things that need to be configured before it becomes usable leads new people to use things like Spacemacs etc. This means they rely on other peoples’ config, and aren’t able to customise the editor for themselves.

The same issue exists in Vim. So many nice features of Vim (such as file management using buffers) are underused, because by default they aren’t configured in a usable way.

Otoh Vim has some good stuff out of the box that emacs sorely needs. Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required, and I have not found anything like that for emacs. Ctags works out of the box. It's a bit weird that cscope integration is worse (you need a script that scans up your directory hierarchy to find the database; ctags support has this built in). In emacs you can install the xcscope package but it's miserable compared to vim's built-in cscope support, and doesn't integrate with evil's tag stack.. sigh.

> Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required

For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.

I remember using emacs for C programming with make. M-x compile worked out of the box. I don't think emacs culture would suffer if TypeScript worked out of the box today.

Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands in emacs 9 times out of 10. Emacs still does some fundamentals better (undo), can be used in a terminal and, if you avoid bloatware like spacemacs, also offers better performance. If one is willing to ignore the spyware and proprietary component aspects, vs code by now is a better choice even for most power users, IMO.

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things

I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development.

For me though it's still not even close.

I find this hard to believe. Not that you may like one over the other, but that one is superior.

Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.

That's also built into VSCode. The feature is called "Remote".

Not the same, from what I have seen. But, more pointedly, I have been doing this specific workflow for over the last decade.

So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things

Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with.

With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently.

In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.

> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands

I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.

VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.

From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.

It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.

I tried typescript lsp in emacs (tide) and it gave me a lot for free (realtime type check, formatting). What else VSCode has ? nicer hints (dom based) and refactoring ? Genuinely curious.

Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.

From my observation, the IDE-parts of VS Code are what put most computers to their knees. VS is very performant when acting like a regular text editor, even better than emacs in certain cases -_-

But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.

That's odd.. tsc doesn't seem to be the issue (I barely notice it on my machine). But I'm no internal dev so maybe.

  emacs is by now quite inferior to VSCode for most thing

I think this statement illustrates a problem that comes up again and again in tool discussions.

I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together.

The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better".

This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.

I wouldn’t call that it’s only success. It’s an application that’s been used and maintained for 40 years. It’s the application that practically spawned the Free Software movement. It’s one of the most portable programs I’ve ever seen. The basic interface has been cloned (with less malleability) dozens of times.

It may not be the most used text editor today but overall I’d rank it one of the most successful applications in history — along with perhaps Netscape and Excel.

(Replying to myself.) For what it's worth, I somewhat regret the wording of the parent post. I was hoping for a thread on lessons from Emacs generally applicable to the topic of malleable systems — maybe things like: (1) periodically integrate the community's best "packages" into the "core" else you'll have a mess (also consider: LaTeX), (2) figure out how you can continue to change defaults without fear of breaking old users' workflows — whatever, I was hoping for more lessons — but instead it (I should have known this!) became a thread mostly about Emacs in particular.

> what prevents or prevented Emacs from being even more successful?

Because is big, stuck in it's own past, with many useless quirks. Additionally the malleable system has a price, which for most is bigger than it's benefits. Emacs is always stuck in a loop of fetching up with the rest of the world, living in it's own utopia and creeping away everone who can't dive deep fast enough.

Most people are pracmatic about their tools. Tools should just do their job and don't get in the way. Emacs doe not deliver that, and the people can be quite dogmatic about certain things. It changed in the last years, fresh blood and concepts are spreading their influence, but we will see in another decade whether this actually had some longlasting effect or was jsut another circle of quirk-building.

Everything you write I see the other way around.

I've been using IDEs for nearly 30 years, from QBasic in DOS, Turbo Pascal, Visual Basic, Delphi, Visual Studio, Eclipse, RubyMine, IntelliJ... and every time my career shifts a bit, I ended up learning a new IDE with new keystrokes and new idioms.

Changing IDE every 3 to 5 years gets old after a while. You learn not to learn too much of the IDE, because a lot of stuff beyond the basics of text editing won't come with you to the next IDE.

Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. When you say "stuck in the past", I say "stuff I did 20 years ago still works".

You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.

YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.

[1] IntelliJ is far inferior to Eclipse for incremental compiles and running tests, but Eclipse has a horrific UI, weird modal system, and a parallel project management universe in workspaces. Neither have editors as good as Emacs.

Yes -- at first I saw emacs' age as an annoyance, now I find it to be its greatest strength.

Yes, elisp could be more "modern," even by lisp standards. Yes, twiddling a bunch of global vars and then calling global functions is not an ideal way to program to an API (this is at least sometimes the case in emacs).

But the payoff for accepting these shortcomings is you get to draw on literally decades of development and a large pool of knowledgeable ongoing contributors. I've seen calls to have emacs support Rust, JavaScript, python, etc. But the X in "emacs should support X" seems to change almost yearly. Learning to accept elisp means learning to respect all the work that went before, all the code that just silently runs and works every day. Which in turn means your own contributions are much more likely to be doing some good for years and years.

> Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc.

If you are at the point where you use emacs for everythings, then it doesn't matter anymore how alien emacs is. But until then it's a long path, and not many are willing to walk it.

But even then you must accept some sacrifies and ignore that what emacs can't do. If you are with it for so long, you likely don't know and miss all the fancy new stuff, and at this point you don't need it anymore. But new user are differnt there.

> You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.

I would not say always, there were times when development of emacs was much much more worse then today. I jsut think those darkest times are completly gone and what in the past were single drops of blood is now a steady river for the next decacde.

Every IDE is alien when you come into it. It took me ages to get used to Eclipse, and even then I greatly enjoyed jumping ship to IntelliJ. Visual Studio deeply irritated me with its different key bindings and editor behaviour to Borland IDEs, I ended up writing a bunch of VBA macros to take care of some of the more subtle differences, until VS stopped integrating VBA!

> Every IDE is alien when you come into it.

I don't think so. Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. But Emacs is not even doing that. Simply because it was made long before this lingua and concepts were established. Vim is similar in that regard, though not much as worse as emacs, if we ignore the conceptional difference.

Any complex application has it's quirks and special parts. But with emacs you have on top that even the basic parts are special and full of quirks. So instead of needing to adapts to 10% or 50% new ground, it's more like 80% or 100%, and for many this can be too much.

> Most modern Apps follow established lingua and concepts on the fundamental and often middle levels

This is not at all true of the IDE pair (Visual Studio / XCode) I use at work.

I do all my code editing in spacemacs and use the IDEs as heavyweight build / debug / code-search frontends (not for lack of trying to do these things in emacs, mind you). The process of doing each of those things is completely different between XCode and VS.

  Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. 

You can repeat that statement in 2020, 2010, 2000, 1990 ... the only problem is that outside of a very small subset what is "established" has changed. And likely will again.

> I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.

I'm in a similar boat to you, in a different language environment. With OmniSharp, I'm able to do 80% of my C# development in emacs, and could probably do more if we were on .NET Core rather than .NET Framework. But I still have to go into Visual Studio for managing project files, and occasionally for debugging. While working remotely, I intensely wish I could just SSH into my Windows workstation and do my work in Emacs rather than having to use the kludgy remote desktop software we use.

> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.

If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.

I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it.

It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while.

I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).

Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.

I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable.

IntelliJ handles this project pretty much without breaking a sweat.

I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.

> Additionally the malleable system has a price, which for most is bigger than it's benefits.

And yet here we are, talking in a web browser, the most malleable modern environment of all. We’re not running some forum-only app, like we used to have.

Disputable. Are web browsers the sytem or web-technologies (html, css,...)? Emacs has also browers, but with limited abilities, does that make emacs more malleable than web browsers, despite offering just a subset of them?

Anyway, I think one reason why web browsers are so successful despite offering that malleable experience is that 1) it was designed for this specific usecase, and at some point even enhanced direction from document- to app-environment, and 2) someone else is paying the price for it, so the users don't care and can just consum.

If emacs would receive as much money and competence as web-technologies and browsers received, it surelye would be a first-rate environment with excellent support for all users on all skill-levels. But then it probably would be just a web-stack of different name.