Emacs 29 is nigh

Do you even get no stuttering with company-minimum-prefix-length set to 1 and company-idle-delay 0? I tried building --with-json, and `(json-available-p)` returns `t`, but it's still super stuttery.

You get plenty of, er, new old contributors as well! As long as the projects are interesting and compelling, people of all ages will keep comin' :)

I think there has been quite a few very fundamental enhancements to Emacs recently. The JIT which was added to 28 and now a pure GTk Emacs. This fixes some very long standing infrastructure issues and enables further exciting developments. A faster Elisp not only makes the editor feel snappier - it also opens up application development in Emacs. It becomes feasible and nice to develop much larger packages or even complete software on top of Emacs. The pure GTk Emacs cleans up the UI handling and I hope this also means for more widgets becoming available to Elisp. This would enable quite a lot of interesting additions.

> * The ease of concurrent programming, e.g. emacs-aio.

There's no such thing. emacs-aio is an extension bolted on top of generators and promises, which is how it was bolted on in Python too - so not bad by itself - but the problem is that nothing in Emacs core supports it. Async in Emacs is still, in 2022, a callback hell, and it's not even supported in newer APIs, like completion-at-point (which is awful - I understand that the origin of this is minibuffer completions and that it might be justified to do everything synchronously, but in-buffer completions should not freeze the editor!)

Now we have threads, but seemingly nobody uses them - not surprising, given that last time I tried I got a segfault pretty quickly (fixed since then). Still, threads? With locks and semaphores? Didn't we all agree that these are not the greatest primitives for concurrency? What about channels or async streams? Not to mention, the threads normally should be preemptively scheduled, while currently they are "mostly cooperative" in Emacs. IOW you can still run code in a thread that will not return control to any other thread, as long as it doesn't do IO. Which would be fine with coroutines, but these are supposedly threads! So you pay in memory for threads but get coroutines, but with pretty fuzzy notion of what's atomic. It's a cosmic horror story.

I'm trying to write a "guide to modern Elisp programming" - there were definitely very interesting and good developments in Emacs Lisp over the last 5 years, and generally the language, coupled with convenience libraries like cl, seq, s, f, and so on, became a very productive environment. EIEIO (and cl-structs) and multimethods (true multimethods, which landed at some point in cl-lib without much fanfare, though they really deserve more attention) are incredibly expressive if you don't mind a bit of syntactic overhead (clojure-style . and .. would be appreciated). cl-loop is incredibly versatile tool that lets you declaratively state almost any kind of iteration and reduction. There's object inspector, there's a package supporting many kinds of refactorings, and of course helpful for rendering information about commands, functions, and variables. It's overall great and productive environment... until you try doing async, unfortunately.

> This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. t care for things that are irrelevant in the context of modern day development.

It is not, that they/we do not get it in general. You are painting with a very broad brush there. Not all Emacs or VI users are the same. Not all of them/us are endlessly optimizing startup time. Often the opposite is true. We do not optimize it, because we start Emacs when the day begins and close it, when the day ends. Because why would we ever close it at other times? No need to.

It is probably more, that many see it as inappropriate functionality, when one has to close the application and re-open it to do something so simple, that comes out of the box with Emacs. We are used to have this functionality without restarting and we wonder how one could accept this kind of shennanigans.

With VIM or its variants I can tolerate it a bit more, as it is more minimalistic than Emacs in its approach. It is often used as a quick command to open a file on a server, safely (model editing) edit the file and exit (no jokes now!). A one-off operation, not a long session of developing. There are people doing long sessions of development in VI variants as well of course. I have done that in the past, with a heavily configured NeoVIM, using some plugins and it worked quite well.

I would guess, that many people see it as an improper way of doing things, when one cannot accomplish a task directly in ones main editor, but needs to close it or open additional instances of it. The question automatically arises, what the problem is and why it cannot be done in the instance you already had opened. Was the previous instance somehow bad? Does an instance have a half-life period or something, so that it needs to be refreshed?

> Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff.

If I configure for myself in my free time the "optimal tool" and then just copy its configuration into my on-the-job tool, it is my time to spend and does not take anything away from the time writing code on the job. In fact, it even increases my productivity, compared to what some people do with VSCode instances being closed and opened and all that. No one else has to worry about how I personally spend my time. Even if I wanted to spend a few hours a day optimizing my own tooling in my free time, I should be allowed to do so.

If others want to work with less optimized tools or do not want to invest time into making their tool work as well, that is their choice. Doesn't make it less painful to watch in screensharing sessions though.

>>You can run Emacs as a server, for example on a remote host

> vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.

Now you are just setting up a gigantic strawman. What kind of configuring around have you done, that took weeks or even months? Who would even be willing to do that, without looking for help from other people, who already have configured something similar? No single thing would take that long to configure. What you may be confused with it incremental improvement. Over the life of an Emacs setup, perhaps over a time-span of 10 years or so, it may well happen, that one spends weeks configuring things. Obviously not necessarily in one long marathon, but over time tweaking things. Half an hour here and there, to make life more pleasant and move beyond lowest common denominator functionality.

I agree, that one should not spend a lot of time configuring things before getting anything done, unless one has the time. However, default Emacs already is quite capable and I could easily work with that.

It would also only take me a minute to install a theme I like and perhaps magit. The return of time investment for magit is enormous, since I already know it, so I would install it right away. Hitting some M-x package-install RET magit RET takes less than a minute and makes every git interaction I am likely to need much faster.

The thing is, that with Emacs one gets things which one does not get in VSCode at all, no matter how long you configure VSCode. I personally expect more from my tooling and that is my choice. Who are you to decide what functionality I am to expect out of the box and what I am to not expect at all?