EmacsConf 2024 Notes | Hacker News Reader

EmacsConf 2024 Notes

sachachua.com

340 pointsJNRowe154 comments

> EmacsConf feels like a nice, cozy get-together where people share the cool things they've been working on and thinking about.

Emacsconf was indeed executed great this year, and nice and cozy were my feelings too. It's interesting to compare and contrast the ambience between Emacsconf and that of the other editors' like neovim conf and the release "parties" of Visual Studio Code and Jetbrains.

What was different about it compared to the neovim conf?

People can't seem to find an exit.

Wow, that's actually hilarious!! :D

You don't "exit" Vim, tis not a stage - you quit it. And then go to Emacs because tis a killer, a vocation from which there's no quitting - it is for life.

It’s wild doing the following on a shared production machine. I’ve seen 30+ sessions unattended for days:

    ps aux | grep vi

People not knowing how to quit vim is a meme but at the same time is real as ever.

I've probably had 10+ myself just because I have multiple half-finished projects open.

Maybe my error was XEmacs instead, I only put up with it until IDEs finally became part of UNIX culture.

For non-emacs nerds who didn't get the joke - command for exiting Emacs is 'M-x kill-emacs', also, you don't "delete-word" in Emacs, command for it is 'kill-word', there's also 'kill-paragraph' and so on.

Now I wish there were a way to yank emacs after killing it.

Yanking Emacs back to life? What kind of digital paganism is that? The Church or Emacs dictates using the mighty Daemon to summon it back to life.

I respect you for that joke.

People like the organizer.

I dipped into NeovimConf since I like learning from other conferences and other editors. People's workflow videos are always cool. The Emacs community merrily assimilates lots of great ideas from Neovim, and it's great to see ideas flow the other way sometimes. I tuned in last year too, and I particularly liked how they had a number of NeovimConf talks covering other editors like Helix so that people in the NeovimConf community could pick up inspiration. I like the way TJ and ThePrimeagen keep the conversation going through streams throughout the year. Someday the kiddo will let me have more focused talking time so I can try to make more videos and have more conversations. :)

There was an interesting discussion on Reddit after NeovimConf 2024 (https://www.reddit.com/r/neovim/s/TSFc3cVGGV) People were happy about the talks. Some seemed a little frustrated by interruptions from ads, getting off schedule, and a chat that might sometimes get a little distracted by meme potential. EmacsConf is a lot smaller than NeovimConf in terms of viewers - twitchtracker says NeovimConf got 3640 (plus more on YouTube) and we got about 400. We're, like, an order of magnitude smaller. That might be why self-hosting via Icecast is manageable for us. We started automating scheduling a few years ago because I wanted to accept more talks than could comfortably fit in a day, and since I was figuring out that infrastructure close to the conference, I needed something that I could handle by myself without going crazy. Even though my co-organizers are now more familiar with the fallback scripts for manual control, they prefer the automatic schedule. And community is a gift beyond anything I can code. I remember watching the IRC logs scroll past and feeling deeply appreciative of how wonderful and thoughtful people are, even during some of the tougher sessions we've had in the past.

Also we like doing captions and transcripts and putting up the videos as soon as possible. :) Text makes things easier to search and skim, especially from within Emacs. And videos, well, we've got them, we might as well have a little bit of code to publish them right away.

I reached out to teej_dv and ThePrimeagen on X to see if I could learn from their NeovimConf notes or in case any of our notes might be helpful. TJ said they don't really write things down. Makes sense because they're more video people. I hope they'll consider doing a postmortem braindump and maybe even sharing that publicly. I think that would be really cool.

For me, I lean heavily on automation, documentation, and incremental improvements partly because it's fun, partly because it helps me make the most of what little time I can squeeze in between interruptions, and partly because it ripples out and helps other people who often end up paying it forward. Emacs is very well-suited to this, of course. Every time we get to do EmacsConf, I learn even more and build up more tools along the way.

I think Vim and Neovim have a way bigger userbase than Emacs does, and I'm glad to see Neovim talks sharing workflows beyond the usual software development things. I do think there's something wonderful about the multiplicity of things that people use Emacs for, and how we've got this culture of both figuring out how to tailor Emacs to yourself and sharing those ideas with other people. I'd love to see what happens as Neovim and other editors build that critical mass of user configuration and community sharing, when people can figure out something for themselves by cobbling together stuff from other people. I think it's kinda cool how people shift from one editor to another, even. If they bring ideas from Emacs to somewhere else, or they bring ideas from somewhere else back to Emacs, things get better.

I'd love it if NeovimConf could also be a smoothly-running way to get stuff out of people's heads, connect people with other people, and inspire more awesomeness. I'd love it if people could do that sort of stuff with all sorts of other mini-conferences about their interests. Could be fun!

Thanks for sharing your thoughts! I too like to peruse the things that neovimmers are up to as they come up with some pretty neat ideas. There does feel like there is a productive synergy between Emacs and neo/vim.

I wouldn't believe how well it was run if I wasn't there. Sacha is a powerhouse, the amount of code she wrote in elisp to make this conference happen with the quality it did is just amazing.

Thanks Sacha!

Awwwww, thanks! =)

You know how it is... It's fun to write Emacs Lisp to automate things, smoothen my workflow, reduce the risk of mistakes. 15 minutes here, 5 minutes there... Micro-improvements add up!

I had no idea that there was a NeovimConf! It's kind of a shame that it's so low in the search rankings that searching directly for it seemed to turn up only hits for Neovim configuration files, so I hope that I may be forgiven for linking here: https://neovimconf.live .

honestly the community Emacs has really sets it apart, and it's a piece of software where the GPL makes sense and shines and this is super clear in the Emacs community.

It gives me hope for the longevity of the editor, and indeed, in the short ten years I've been a casual user it has only gotten better.

Long live the Emacs community

Emacs is good because the barrier to entry is so high. Anyone who sees elisp and doesn't run for the hills is the type of person who has interesting ideas.

That was the defining reason for me to switch from vim to emacs :) still have the date on my calendar and I celebrate my emacs-versary with M-x tetris :D

I still chuckle whenever someone tries to remake Emacs using Lua, completely missing the reason Emacs is so powerful is because it's written on a Lisp.

EDIT: looks like even in this thread people are suggesting to use Lua instead of elisp. smh

Kids that dismiss Lisp without even grasping the amazing power behind it, remind me the story of Yanomami languages of Amazonian tribes. Apparently, there's word for 'one' and for 'two', but there's no word for 'three', in their language, only a generic word that basically means 'a lot'.

Now imagine trying to explain to them the concept of subtracting a hundred from a billion and the most straightforward way to deal with that is a decimal numbering system. I think they'd kill you for blackmagicfuckery on the spot.

Well, if that comparison feels condescending, let's imagine ancient Romans - with all their sophisticated culture, economy and traditions. They wouldn't kill you, but still the idea of a number such a billion would probably terrify them. They'd probably be like: "dear sapientissime señore, we respect your wisdom, but we rather use... Lua"

Romans knew about thousand based multipliers with a mark over the letter.

Okay, please share your wisdom, tell me how would they express "1,000,000,000 - 100" using Latin numerals?

Oh, I found the answer on my own, with the help of LLM. For a billion you can use M̅M̅, which technically would mean a thousand thousand thousands, and to denote the calculation above you'd write - M̅M̅CM. But my point still remains relevant - this is the modern extended version of Roman numerals. In ancient Rome they typically never would go up to a billion.

Lua can be viewed as a pretty solid lisp dialect. You've got the compiler available at runtime, first class functions and coroutines, sensible language runtime. Type system is pretty much the same. It doesn't do the phase separated macros out of the box, but metalua does. Performance is rubbish and the syntax is a parse away from the s-expression ast but whatever, the semantics are right.

I mostly agree.

Probably Stallman would object that Lua doesn't have read (apart from eval) and print.

As for performance, LuaJIT performance is better than any Common Lisp or Elisp, and dramatically better than the first 35 years of Elisp, before native-code compilation.

Any common Lisp? SBCL is no turtle.

Compared to LuaJIT it is, unless you monomorphize and turn off safety checks, at which point you're basically programming in C with Lisp syntax.

There are plenty of powerful programmer editors, yes being mostly written in Lisp dialect makes it powerful, but also makes one lose too much time yak shaving instead of programming the actual task.

XEmacs, much better than Emacs back then, was my rescue for not having IDE culture back in my early UNIX days. We're talking back when Xenix and DG/UX would be known names to anyone working with UNIXes.

Nowadays, while Emacs key bindings and elisp might still be burned into my brain cells, I no longer reach out to it.

There was supposed to be one talk about an attempt to re-vitalize a Guile-powered Emacs. I am not sure if it's in there somewhere or not (but I haven't looked yet).

I imagine Emacs gaining native compilation capability took some pressure off that. But the appeal of scripting Emacs in languages other than Elisp still has some appeal, I think. Scheme or Lua would very nice for that purpose.

EDIT: There it is - https://emacsconf.org/2024/talks/guile/

I think just having a proper runtime for elisp would be great...

I am a guile person, but even if the Emacs folks would only allow elisp on guile it would still be a win.

> or Lua would very nice for that purpose.

There have been a couple of front-page threads on Lua recently and their comments really show how polarizing of a language that one is

I feel very strongly against Lua. I use it for WoW add on development all the time - I make so many mistakes with the 1-based index when porting algorithms. It is very very painful.

why not Fennel?

Wow I didn't know this existed. This is pretty cool. Will definitely play around with it.

What? Really? OMG, Fennel is so nice. I'd use it for anything that needs Lua these days - neovim, hammerspoon, awesomewm, mpv, wezterm, etc. It's very mature and it even has an lsp-server implementation and a dedicated conference. It's incredible how you can reduce some big, nasty, unavoidable boilerplate in Lua just into a few lines of Fennel.

Fortran has arbitrary-based indexing forever (as does Ada). The default is 1 but it can be specified as anything. I don't see why this capability is so rare.

I think it's one of those features where the original intended audience of the programming language are supposed to be non-programmers (or presumably, 1-based indexing is intuitive?) but for seasoned programmers who have been used to 0-based indexing, the change is quite stark.

It's the same concept with AutoHotKey and the original intention of Lua (super small user-defined script for the masses).

Whereas Fortran and Ada probably had some forethought that went into enabling that functionality. I will have to check but I remember my algorithm class started with 1-based indexing and the reason was it was intuitive to explain. But when experienced with C/C-inspired languages, the old adage becomes relevant: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."

> the original intention of Lua (super small user-defined script for the masses).

Lua was originally intended to be a language/data format for a Brazilian oil company geology software.

https://www.lua.org/history.html

It has that in common with Lisp!

I was hoping to see something about EAF[1] this year, as I think the big thing emacs is still missing is a good way to drive interactive graphics, but EAF is still super janky and underdocumented.

It'd be good to see this (or something better!) make progress.

[1]: https://github.com/emacs-eaf/emacs-application-framework

Ah man, I'm gutted I didn't "attend" this. Been an Emacs user more than 15 years and people like Sacha were there at the beginning for me and a huge reason why I got into Emacs back then. I feel so lucky to have got into it back then. I see colleagues struggling with their tools which they can't fix or even tweak, but I can't imagine any of them putting in the time now to learn Emacs. It's truly the editor of a lifetime.

> It's truly the editor of a lifetime.

This is the main reason I use it as well.

Emacs is far from perfect. It's slow, lacks some of the bells and whistles of other editors, and can be downright frustrating to use at times.

But damnit, it's _mine_. It has allowed me to create the perfect editing and programming experience _for me_, and no other environment gives me that freedom and enjoyment. Vim and friends come close, and I continue to use it as my secondary editor (and couldn't function without vim-mode), but Emacs allows much deeper customization and Lisp is so elegant for this.

As editors come and go, it's comforting to know that Emacs will always be there for me. Warts and all. <3

I was really impressed with the online presentation of EmacsConf 2024. Everything captured and published in org-mode: Transcripts, Comments, QA, Video links. Was really nice to peruse.

Wondering if the Lem project is “accepted” (or worth a test drive) by the Emacs community. I’m a long time Emacs user, occasionally leaving but always returning. Lately, Lem has my attention. https://github.com/lem-project/lem

For those not familiar, Lem is very approximately an Emacs, natively written and extendable in Common Lisp, multiplatform, NCurses & SDL2, etc. LSP. And fast.

Lem is really great. I hope it keeps gaining mind share because it's superior to emacs in a lot of key ways.

What is better, from your experience?

I'm a happy Emacs user, but think having more options is great, and I've delved into some Common Lisp and certainly am eager to learn more. So I'm thrilled to see Lem continue to be developed.

Emacs is "better" only because it has more features at present, and is somewhat more mature.

But emacs remains replete with bugs, the performance leaves a great deal to be desired, the UI locks up if you update your packages because the whole thing is single-threaded, and emacs lisp (the language) quite frankly sucks, a lot.

Lem is not very mature and has a lot of sharp edges but already in this state I can see that it will eclipse emacs if it continues its current trajectory.

Oh come on. Emacs is not that buggy. For a piece of software that's been developed for over forty years it's quite surprisingly stable. Most of the "bugs" I see are due to some tighter integration between different packages - someone upstream would change something that inadvertently breaks things somewhere else. It doesn't happen that often.

Also, Elisp isn't really that bad. Well, sure, Common Lisp of course is a lot nicer language, and of course, not having any good concurrency story doesn't add any points, still, Elisp isn't so horrendous.

That being said, I do really hope Lem would get traction, and people start building plugins for it. Alas, realistically I'm not sure how feasible that would be. Replicating anything like Org-mode, with tons of extensions may take many years. Lispers however are known for their tenacity and ingenuity, who knows, maybe it wouldn't take too long.

Concurrency is very important these days though. Yet it is an extremely hard to solve problem in Emacs, due to tons of mutable global state, ingrained for decades, very hard to convert to something that works OK when running concurrently.

I use Emacs every day. It is my editor and in general tool of choice. However, the longer the concurrency story is not improved, the more advantages do other projects accumulate, because this concurrency thing is part of everything. Even VSCode seems to be better at concurrency. What a shame.

I think the only way in Emacs to properly use multiple cores for speedup is to start external processes. Sometimes that is a natural thing to do. But one also needs to process the result of an external process. Say for example a huge git diff in a magit buffer. All that stuff needs to be rendered/fontified. Editor locks up. That's just really bad. And people discuss workarounds all the time, writing code with these limitations in mind, meaning, that this makes code more complex everywhere.

Agree with the other responder, largely. I've been bothered a few times by Emacs locking up, but never enough to be actually upset about it. Bugs, I don't see it, it is very very solid for me, I can't remember the last time something didn't work as expected. Hmmm.

Still very Lem-curious, though!

I tried it out twice now but it doesn't support multiple frames. So it's a terminal only sorta thing? Or maybe Wayland? Whatever, it doesn't support multiple decade proven workflows. Totally ok, but not superior.

Lem is a nice try, but the default theme is utterly disgusting and because it wasn't designed with themes in mind going with a sane theme is impossible (because some colours are hardcoded so they become impossible to see on a proper light background). The lack of an Emacs-like configuration UI and Emacs-like documentation is also unfortunate.

Sounds nice, how is the ecosystem of plugins/extensions compared to Emacs? Are there Debian packaging plans?

Latest release is of February. Has progress been made?

I’m running that February release as my daily driver on MacOS happily. Haven’t launched Emacs except by accident for a few weeks. I admit it’s an experiment but so far so good.

Lem always feels very responsive (threading or rendering architecture, I assume) and my meagre needs for Emacs keystrokes seem supported. One thing I’d love to see Lem support soon, though, is org-mode awareness.

It is clear from the commit history that the project is active and work on it continues.

I think that releasing is the run git tag, writing a ChangeLog from the previous version, and pushing to GitHub, but I don't think that this act has much meaning.

I think binary files that can be executed by just clicking on them are valuable, but they can be done independently of releases. It's very difficult to make them work on a machine other than your own using sbcl, so I haven't been able to do it continuously.

But when I think back on it, the act of releasing also shows that the software is still alive, so I want to release it

I remember that last year's talk on Emacsen included Lem and it was well-received. https://emacsconf.org/2023/talks/emacsen/ I hope Lem continues to grow!

I loved browsing the emacsconf videos this year, really nicely presented, and such cool stuff happening. Still have lots to watch, but so far in particular the infrastructural and UI type stuff seemed amazing, there's loads happening! Favourites included:

https://emacsconf.org/2024/talks/casual/ -- Charles Choi designing UIs for human beings rather than octopuses (this jibe is meant fondly, I am a happy octopus)

https://emacsconf.org/2024/talks/literate/ -- Howard Abram, literate programming

https://emacsconf.org/2024/talks/gypsum/ -- Emacs and emacs lisp clone in Guile

https://emacsconf.org/2024/talks/rust/ -- Rune, an experimental Emacs core in Rust

https://emacsconf.org/2024/talks/julia/ -- lovely talk about the synchronicity between Julia and Emacs

https://emacsconf.org/2024/talks/guile/ -- Robin Templeton relaunches Guile-Emacs!

https://emacsconf.org/2024/talks/mcclim/ -- eh, this talk accepted questions from lambdaMOO?

> The total hosting cost for the conference was USD 42.92 + tax and the BBB testing in the lead-up to the conference was USD 3.11 + tax, so a total of USD 46.03+tax. The web node and the livestreaming node are kept as 1GB nanodes the rest of the year (USD 5 x 2 servers + tax, so USD 110). Very manageable.

How does this compared to all other conf costs?

Oh, do you mean like the domain name registration? That's also pretty small. I think it was, like, 12 USD, but I don't have the exact cost handy at the moment.

We've been experimenting with sending tokens of appreciation (evil plan: stickers/pins might get other people to talk to speakers about Emacs), but Corwin's treating that as a personal experiment and not including it in the conference budgeting.

And of course, there's a lot of stuff that isn't counted in monetary costs, like the time that speakers put into their talks or the servers that people have shared with us.

But yeah, it's surprising what you can do on a shoestring budget and with casual volunteers. Definitely worth considering if people have been thinking about running their own conference. :)

Final Linode invoice came in, so it's USD 62.54+tax for December, so a total of USD 175.65+tax for the hosting costs for the year. Worth it!

Though this does not contain the cost in invested time. Try setting up BBB with Docker. It is not easy, unless you have done it before and are somehow an expert. I tried and gave up. Month or years later people still post in issues I opened. Since a docker deployment is also not the official deployment, there is little help from maintainers, understandably. It is also a huge setup, with many running parts.

Very cool though, that they managed to pull it off.

Oh yeah, I briefly tried to get BBB working in Docker and ran into lots of issues before deciding it was worth just paying for another server instance where I could run it all by itself.

Time-wise, I did Emacs-related things for 36 hours in Sept, 40 hours in Oct, and 52 hours in Nov. That included about an hour a week for Emacs News. To be fair, it's really more like hobby/fun time... :)

Nevertheless, thanks for all the work you put into making it happen!

I have followed Sacha for a long while, love her frequent Emacs updates. I am a rabid Common Lisp enthusiast, and I bought the Mastering Emacs book last year, I just need to pull the trigger and try doing a project in Emacs Lisp.

Common lisp -> elisp is an incredibly frustration transition. Get ready to really think in terms of dynamic scoping.

I did it the other way, and going back to elisp is /hard/.

I thought lexical scoping is standard now?

No: https://www.gnu.org/software/emacs/manual/html_node/elisp/Va...

In practice, everyone writing new projects uses it, but when you choose to interact with existing code...

Do you think TeXmacs should be included in EmacsConf, even though it is based on neither Emacs nor TeX, but merely inspired by them?

From an entirely armchair commentator, I think so - the exchange of ideas and enthusiasm among Emacs-likes can only benefit both projects and Lisp-based editors in general. (The reason I’m very armchair is because use LyX when I want to write technical documents, which does leave out one of TeXmacs’s really important use cases.)

This year we got to have a cluster of talks that were about not-entirely-Emacs things, and last year we had one about Lem too (https://emacsconf.org/2023/talks/emacsen/). We've figured out multiple tracks, so we can handle cross-pollinating with other communities while still keeping lots of stuff for people who want to focus on Emacs. Proposals welcome! =)

As someone who exclusively uses emacs for all their editing, some nice topics there; though a bit miffed it's all video only.

Although this, from the page linked, was pretty fun: https://www.youtube.com/watch?v=urcL86UpqZc

On the main page for this year there are all kinds of media available, audio, video, slides, transcripts, Q&A: https://emacsconf.org/2024/talks/.

My bad, thank you !

I really enjoyed the conference this year! It had a good mix of project updates, emacs internals, configuration, Emacs rewrites in different languages, org-mode applications, community, interesting packages, and things that went over my head.

I wonder how many users Emacs has lost to VS Code over the past few years. I'm one of them.

Feels sad. And also potentially shortsighted.

Is a matter of time until it will be enshitified, and they come back…

I guess there are two aspects to the the typical process of MSFT enshittification:

a) lack of regular revenue leading to bizarre product management choices (probably not a case, because of GH Copilot subs)

b) initial really talented team members gradually being replaced by bozos because of entropy and/or management (work on something new/important)

I suppose b) is the most obvious risk.

I think option A is actually part of their problem. Not because they lack revenue but because they are successful with it. You mention Copilot but VSC integrates with a lot of Microsoft owned cloud services as the “default” or “first class citizen”. I’m not sure why people would use the Azure extensions over the AZ cli, but they are obviously rather popular. It’s a lot like how Google search became the default search in a lot of products, except here it’s GitHub, Azure and so on.

On top of that they get some wild telemetry. Your privacy data is obviously safe, but the metadata they collect goes right down to your project structure. So Microsoft knows what sort of projects and in what sort of languages everyone uses. They know what you’re putting into your Azure cloud and they know if you’re not using Azure. I imagine these things are rather valuable to the biggest tech company in the world.

Obviously they’re going to focus their development on upselling Microsoft products to you. Which will only get worse as they succeed more and more. Because why wouldn’t an enterprise company do that?

Yup. The prospect of having to someday switch to VSCode unnerves me. It's not because it's technologically inferior to Emacs or because of my habits, muscle memory, dogmas, or childhood traumas. It's because of Microsoft. I just can't blindly trust the good intentions of a mega-corporation. A behemoth that expends huge amount of resources constructing a modern code editor packed with numerous features that they then offer at no cost. When I used IntelliJ and paid for it, I understood precisely what I was buying, I understood their revenue model. Then I switched to Emacs - which is only theoretically free - as it cost a substantial amount of time, dedication, and energy. I still understand who benefits from my choice - the community, me, and the wider industry too. Every time I activate a VSCode instance, I'm unsure of the exact cost that I'm incurring. It already felt like a hostage situation when they took over GitHub. If everyone is now must become a VSCode user, I don't even understand how people don't realize how dystopian that is.

I don’t see why you would ever have to switch to a certain IDE, but I can see from some of the other comments a lot of people seem to be unfortunate enough not to have the choice. One of the reasons I like emacs (again in in doom so it could be Neovim) is that it’s basically an IDE I can use forever and easily get working on any computer by pulling my dot files from my git repo. I say easily but it’s obviously not easy on windows considering you sort of need WSL, C server and to install some LSP support.

I understand why people like VSC, but at the same time I’ve seen people go from other IDEs to VSC and now many are going yo Zed. Mean while I can just trundle along in the same IDE. Some of the emacs purists haven’t had to learn a new IDE for decades and likely never will.

To each their own of course.

> I don’t see why you would ever have to switch to a certain IDE

Alarmingly, basic proficiency in VSCode becoming a must in many software developing teams and I don't like that. People really seem to have zero concerns about Microsoft aggressively pushing their proprietary agenda, neatly wrapped in "open-source" packaging.

I’m genuinely wondering why you would chose VSC over emacs. Granted, I’m on doom emacs and it’s mainly because I’m too lazy to config Neovim, so it’s not like I’m really a purist. I even use VSC occasionally when I’m in a context on my lovely windows work computers where I don’t have access to WSL, but it’s such a horrible experience. It’s slow, the plugins are ass and the LSPs are horrible for basically anything which isn’t Typescript.

I don’t even think VSC is “that” bad despite what I made it sound like, but it’s probably as temporary as any other modern IDE. In a few years “every” VSC user will probably have moved on to Zed. Meanwhile your emacs (or vim) dot files will setup the only IDE you’ve ever used on any machine.

I started using GNU Emacs in the mid 1990s. I like the ergonomics of the interface. It's muscle memory since long. I tolerated the LISP aspect.

In VS Code I use the "Awesome Emacs Keymap" extension by Yuichiro Tachibana (Tsuchiya):

https://marketplace.visualstudio.com/items?itemName=tuttieee...

What won me over? GH Copilot + the overall packaging. It just works. Good, polished UX. Emacs needs to catch up on this front.

Copilot is available on Emacs, but yes, a lot less polished.

I've been using emacs for 30 years and have tried VS code several times but the muscle memory on Emacs has prevented me for switching. I've gotten LSP on emacs working well enough but the performance just isn't there. So today thanks to your suggestion I tried it once more with the Awesome Emacs Keymap extension and right away I ran into not having dired mode to switch files.

A quick google search got me vscode-dired (incase anyone else runs into it):

https://marketplace.visualstudio.com/items?itemName=rrudi.vs...

Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-mult...

that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension)

We'll see how it goes!

edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.

Depending on the language you use VScode might not be any more performant because it probably uses the same LSP on top of electron instead of elisp. I write Rust/C++ on a sizable project and since everyone depends on rust-analyzer* all IDEs are just unbearably slow and mostly useless in language integration beyond basic refactors and click to go to definition.

* except RustRover but that comes with its own set of issues

yes its rust. Looks like you're right. Well is back to good old emacs for me!

> I have way too much custom elisp to build and debug Rust/Go/C++

What kind of emacs scripts do you write to help debug Rust?

Nothing special or too sophisticated. On the one hand I use Just (a command runner) to standardize specific build and test commands that call cargo with various flags. Here is a simple example from one of my repos: https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfi...

Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.

> LSP on emacs working well enough but the performance just isn't there.

Have you tried https://github.com/blahgeek/emacs-lsp-booster? Also, build Emacs --with-native-comp flag

> It just works.

That "it just works" thing gets me all the time. I just don't get it. Some things surely do work nicely out of the box in a proprietary specialized tool, like for example JS/TS-related things indeed are very nice in VSCode. Just like Java-related stuff works great in IntelliJ.

But programming is far more than writing code. I can argue that writing in plain English for a programmer is perhaps far more important than writing in a PL.

And for any kind of plain-text manipulation, Emacs absolutely has no match today. Of that, I'm certain, because I have watched and followed many VSCode/IntelliJ power users and long-time users, and I do occasionally use those tools personally as well. There are so many practical example use cases where Emacs just kicks things out of the ballpark - from sending requests to LLMs in the midst of taking notes, to controlling video playback, and annotating PDFs - typing those annotations while browsing the document.

And then that "it just works" fallacy. No cookie-cutter solution ever can make a true coder happy. How can one not get annoyed by a bunch of minor, seemingly not-big-of-a-deal issues over a long period of time? Like having to use the mouse for certain operations without a good alternative, or fixed keybindings that can't be fully customized, or the search bar not remembering your last search position and parameters? It's like buying a car with seats at a fixed angle and not even being able to change that.

I mean, sure, Emacs may seem dauntingly complex at first glance, but the initial investment in learning this infinitely hackable tool pales in comparison to the countless hours lost wrestling with the unchangeable constraints of less adaptable alternatives.

> I tolerated the LISP aspect.

I don't know the extent of what you meant by that, but I guess you've "acquired a vehicle," using it to commute and go grocery shopping, and never even realized that you had an actual spaceship all this time. Emacs is most importantly "a Lisp Machine" with a built-in text editor and not the other way around. It is exactly Lisp that makes it so fascinatingly hackable. One chooses Emacs, Lem, Light Table, etc., specifically because of Lisp, not to "tolerate" or "suffer" through dealing with it.

I switched because all my coworkers use VSC, just easier to have extensions like linters and goto definitions synced, we can help each other with any issues in the workflow.

Still use emacs + org mode for notes though, and spent quite a lot of time getting VSC to act like emacs in terms of shortcuts etc.

> Still use emacs + org mode for notes though,

Sounds like you didn't switch, but rather added another tool in your toolbox.

The constant comparisons to VSCode frustrate me because they're often presented as "either-or".

I use Emacs. And I use VSCode.

> The constant comparisons to VSCode frustrate me because they're often presented as "either-or"

I can say the same for Vim... My primary editor is Emacs, but I use vim if I want to edit something quickly in the terminal (config files, git commits, etc). If the codebase is bigger then I use the JetBrains IDEs...

I installed VSCode but I just don't like it. Until today I didn't find a use case for it being added to toolbelt. But I must admit that it almost won the editor wars, people just suppose that you use it.

Do you use EViL mode?

No. I have used exclusively Vim for some time before going to Emacs, and I switched because the package management in Emacs was better and because the plugins were more polished. Then I wanted to do "the official way", using the default Emacs keybindings, even though I find the Vim keybindings better.

I switched in late 2015, things were different back then. If it was today I think I would probably jump to Doom Emacs or Neovim.

> It’s slow

What?

> the plugins are ass > the LSPs are horrible for basically anything which isn’t Typescript

What??

I need to edit projects on a remote machine nearly every day. (I do cross-platform Python dev so I need to run and test code on Windows and Linux VMs while working on a Mac.) Compare VSC’s Remote Edit plugin to TRAMP and let me know what you think. For me it’s not even a contest. TRAMP just simply doesn’t work in a majority of use cases and I’ve only had a few small hiccups with the VSC Remote Edit. Getting LSP plugins working over TRAMP on another machine is hell. I just use Emacs for org-mode and Magit now.

Anyone comparing tramp to Vscs remote editing is delusional, and I say this as an emacs user.

VSCode remote editing is a broken piece of shit.

[Yeah, yeah, I know, I shouldn't be running NixOS and I should use a Microsoft (c) approved OS instead like all the cool kids. Wake me up in 100 years when Microsoft ceases to exist.]

For fully local things like docker containers or across lan, its comparable if you use SSHControlMaster.

Also, the emacs approach uses very little resources. This matters if your LSP server takes 80% of your RAM. Vscode takes 20%, emacs/tramp doesn't.

I can’t tell from this comment if this means you like VSC remote editing or dislike it

Most of my work projects require remote machines. But I edit local files most of the time (in Emacs). Unit tests may be run locally sometimes (docker or even on the localhost). Other tasks/tests run remotely and setup may be rather involved (VSC would be of little help here) but it is easy to use/extend (Python glues together some ssh commands and cloud APIs). The code may be synced (non CI case) using a customizable wrapper around entr & rsync (more efficient, more control, more reliable than VSC plugin)— it helps with the fast feedback loop.

This is not a fair comparison though, since you are relying on having some probable non-free software running on the server, while Emacs is able to give you remote editing and keeps your server clean.

You would have to compare what VSCode does to running Emacs server side and connecting with Emacs client to the server. Then it would be a fair comparison.

At the very least it's useful to use the tools that your coworkers are using. If you're helping a new grad out you do _not_ want to recommend that they use emacs over VS Code. And, when they have questions about VS Code, it's useful if you can answer them.

Maybe you don't have to use VS Code full-time, but having a knowledge of it is useful.

Personally, I started using VS Code because support for frontend is much better there than in JetBrains IDEs and it has great remote editing capabilities. I would prefer to use JetBrains IDEs (I did for many years, and I still go back for Java), but VS Code is just better. I would never use Vim for editing full-time, though I do use lunarvim when I need to quickly edit a remote file.

But I am not the Microsoft support guy, or maintainer of VSCode. It happened in the past, that even though I don't use VSCode, I knew how to help someone, but I would never go as far as endorsing it, especially not to a new grad. If anything in the direction, it would be VSCodium, which the no-carers don't even know exists. Other than that, I would tell them they have to make their own choice and if they happen to choose a tool I know, I can help them out, perhaps. If they want to learn Emacs and ask me questions about how I do something, I would be glad to help them learn this freedom respecting tool, over something like VSCode.

I use doom too. It’s slow vs VSC for me and doesn’t have a lot of code intelligence actions easily accessible. The LSPs are great for languages I code in, Go and Python.

What do you mean by slow? Like, slow at doing what? I can't think of a specific feature that is slower on vscode. Emacs is actually rather slow...

Starting

Remote access because vscode uses a daemon but emacs uses scp for tramp.

Remote access has been way faster on vscode for me. I'm not sure what the daemon has to do with speed here, if anything it's one of the reason why remote SSH on vscode is so good.

I think the point is comparing 2 different things. VSCode with a helper daemon running on the server, and Emacs not configured to run as a daemon on the server side, accessing the server via SSH and scp.

I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.

Merely for consideration, ControlMaster gets one out of the business of establishing a fresh ssh session per ssh/scp operation: https://man.openbsd.org/ssh_config#ControlMaster (and its friends https://man.openbsd.org/ssh_config#ControlPersist & https://man.openbsd.org/ssh_config#ControlPath )

> Emacs is actually rather slow.

It depends on so many different things. Aside from platform specifics (sure, it can be painfully slow on Windows), Emacs might feel slow for various reasons, but it doesn't have to be. Built-in Profiling tools are godsend and if used properly Emacs can be quite impressively fast. My Emacs starts quickly (in less than a second), and it is very pleasantly snappy.

I switched from Emacs to VS Code some years ago after being a hardcore Emacs user for many years. For me it was customization fatigue. Just an endless accumulation of Emacs Lisp one liners and functions that I have no use for outside of Emacs. In comparison, I don't even know where my VS Code dotfiles are. I don't need it to be set up with my customizations, I just use it out of the box and add extensions when I need to.

I was an Emacs user for years, then discovered Helix. I tried it on a whim and it turns out that I really enjoyed a modal editor that requires minimal config. I'm not sure if it's due to my an age, but I no longer want to constantly tweak my setup and just want a solid out of the box experience.

Yeah if I'm on a machine that I isn't my primary system, and I don't want to spend forever configuring my whole setup, I use Helix or (Neo)vim.

> I wonder how many users Emacs has lost to VS Code over the past few years. I'm one of them.

I think Emacs users care more about the total population than one particular outmigration.

I don't have actual data, but if I compare to the amount of activity (blog posts, tweets/toots, packages, etc), then (heavy) Emacs usage seems to be monotonically increasing.

Almost everyone I know who switched to VSCode was using Emacs primarily for work, and mostly limited to SW development. That category of users may be large in absolute numbers, but most of the Emacs ecosystem is not driven by that category (i.e. even if that category shrinks to a tenth of its size, it won't have any impact on Emacs development).

Just take a look at the talks in the conference. The vast majority are orthogonal to SW development/programming.

I think your analysis applies to Neovim too.

Non-programmer usage of neovim outweighs programmer usage?

I consider myself a non-programmer and use nvim daily on my PC for config editing, note-taking, anime playlist management, writing emails (inside aerc). Next time I try programming, I'll also use it for that I'm sure.

vimwiki!

Are you saying that most emacs users aren't in "SW development/programming"? Of course not.

Would someone not very carefully reading your comment think otherwise? Yes, probably.

I’m continually surprised how many non-programmers or occasional programmers use emacs. Writers seem to love it.

> Writers seem to love it.

Of course, how can you not love it? All the tools you need for writing are at your fingertips. You can have a thesaurus, spellchecking, translation and search, dictionaries, etymology lookup, word counter, Flesch-Kincaid reading ease tester, ChatGPT, Anthropic and other models, dictation, formatter, converter, exporter and so much more. Why would anyone ever exposed to that power willingly part with it?

Which packages do you recommend for each of these things? I don't have most of them in my Emacs.

You can simply 'M-x list-packages' and search for things.

- Thesaurus - there are a few different packages, powerthesaurus, le-thesaurus, etc. I use mw-thesaurus, at this point mainly out of habit, it's the first Emacs package I ever made and it served me so well, I never had reasons to look for alternatives.

- Spellchecking - I suppose flyspell still holds the majority, I prefer jinx.el, it completely replaced flyspell for me

- translation - also multiple choices, from translate-mode, org-translate, ob-translate, lingva, immersive-translate, etc. I use google-translate - for no particular good reason, it's just an old habit.

- search - consult-omni, it takes some initial tweaking, but then you can simultaneously search on Google, Wikipedia, YouTube, your browser history, etc., while typing the query once.

- dictionaries - sdcv

- etymology - define-it, wiktionary-bro

- word counter - is built-in; reading ease testing - writegood.el

- LLMs - multiple choices, gptel and chatgpt-shell are the most popular.

Thanks!

I suspect, that most of those users did not create such an elaborate setup, that has all those things. But perhaps, if there is a ready made config for all of it somewhere, maybe they are using that?

You don't really need an elaborate setup; it's sufficient to know how to install packages and explore some possibilities. It usually takes someone experienced to convince them that Emacs is truly the best choice for dealing with plain text. I'm not a musician, but I suppose if I was an aspiring and very talented guitar player and someone would convince me that Gibson Les Paul or Fender Statocaster is just the hands-down the best choice for the job - nothing would ever stop me from finding a way to have and use one, right?

And to leave you with a practical recommendation, not just philosophical rambling, here's https://github.com/pprevos/emacs-writing-studio. Note that I haven't used it myself. I don't know anything about it, beyond its existence.

I guess I should clarify. I'm not surprised how much writers like it. I'm more surprised by how many non-programmers are enthusiastic about diving into elisp.

Right. I had the privilege and pleasure of watching and guiding people with and without a previous background in programming to learn a Lisp dialect. Some beginners, for various reasons, would pick Clojure or Emacs, or in one case, even both at the same time. Interestingly, they had no problem approaching new concepts. Meanwhile, programmers with previous experience in other programming languages sometimes struggled, became confused, and irritated. I think this makes sense - when you don't know any programming, you approach it without prejudice, there is nothing "weird" about things; you don't get confused about Lisp-1 vs. Lisp-2, dynamic and lexical scope, naming, types, etc.; you have no reasons to dislike or hate things - when something works you get excited. And it's not too difficult to find some joy with Emacs these days - you only need to find a starter kit like Doom, open a scratch buffer write an expression and eval it. Once someone is guided through the initial steps, they'd write their first Lisp function or an expression, get to see it working - of course they get very enthusiastic.

I'm saying that the bulk of the community that keeps it alive and growing are either not SW professionals, or are but their use of Emacs goes well beyond SW use. As such, even if they "switch" to a tool like VSCode, they'll still primarily use Emacs for most things (email, document authoring, TODOs, etc). And Emacs as a SW will continue to grow as a result.

A significant portion of the Emacs "influencers" are not SW developers (think Protesilaos). Quite a few very popular Emacs packages are made by non-SW folks.

Which, as I pointed out, is why most of the talks are not related to SW development. Because that's not why the power users use Emacs.

In my (large) company, the bulk of Emacs users I've met use it for SW development, and little else. As such, while they may be really good users for the SW development they do, they tend to be fairly ignorant about the rest of Emacs (not heard of org mode or magit, some even think XEmacs is the improved Emacs, etc). Globally, such folks may well be in the majority, and if the bulk of them stop using Emacs, no one would even notice.

In fact, as someone who's been using Emacs since before VSCode existed, I simply did not notice the (real) exodus to VSCode. If you follow only the Emacs ecosystem (Emacs reddit, blogs, social media), the online engagement has exploded in the last 15 years. You would never guess that Emacs may have lost users overall (if it did).

Why would emacs users care what editor anyone else uses? Emacs seems like the sort of thing you use and develop for if it solves a problem for you. It's not a business; it doesn't need to win popularity contests.

I think it's interesting to think about why people choose things. You can then decide "we want these qualities as well", or "we don't want those", or "we want them but haven't figured out how to get there without paying too high of a cost we want in other things".

Not a goal in itself to capture everyone, of course. But it's a data point!

"Data point" is simply this - Emacs and Vim have seen way too many popular editors and IDEs over the years and VSCode is just another thing in a long list of "contenders" - Brief, Wordstar, Borland Sprint/Turbo Pascal/varios 'Builders', QEdit, TextPad, Norton, Delphi, Adobe shit, Macromedia stuff, Microsoft crap, Eclipse, Netbeans, etc.

Emacs proceeds strategically, not tactically. Even though it outlived so many different editors it was only a single decade, a point in history when it was considered kinda, sorta mainstream, the rest of its lifetime it wasn't.

Emacs is just like Lisp itself - it never dies, and never gets to be hugely popular. Anyone wishing either speedy death or widespread popularity for Lisp (and Emacs) will likely remain disappointed. Those who value Lisp and Emacs will continue using them, even decades from now. Those who never learn to appreciate either - will keep ignoring them.

I mean Lisp "never dies", but there have been plenty of Lisp flavors that have come and gone. We don't write Lisp, we write some flavor (each with vastly different properties and values).

There's nothing wrong with looking at the ecosystem and saying "huh, this is a pretty good idea". Emacs (the community as a whole) didn't ignore the LSP, and thanks to that it gets first-class support for tools that otherwise would have required someone to show up and "do the work" to get it to happen.

I do think we're in agreement about "strategically, not tactically". Like Emacs _is_ doing its own thing. It's just that sometimes you can see good ideas from other places.

The thing is Emacs, just like Lisp, can incorporate all those neat ideas without drastically transforming itself. I don’t know any strong features other editors have that users can’t replicate unless powered by closed source code. It won’t be as polished, but that mostly because users have different workflow.

Yup, Lisp is extremely malleable and egalitarian and unrestricted - that's why there's almost universally at least one dialect of Lisp exists for any non-lispy language and almost every known programming paradigm.

The only rule it insists on is the parentheses, and it's quite ridiculous how people dismiss the entirety of this foundation for incredibly powerful ideas and abstractions, solely for that reason.

Yeah I don’t think we’re in disagreement here. The community can do a lot with the flexibility granted to it!

I’ve tried twice to make the move to VS Code and keep coming back to Emacs. I would often be overwhelmed by my obsession to tweak things (ADHD..) but switching to Doom Emacs and sticking to the standard config helped with that. Learning some Elisp to write custom functions and embracing org-mode has made it near impossible to switch to another editor now.

I was one of them but I went back. It’s just soooo good, and VS Code sits in my uncanny valley of almost-but-not-quite native in a way that bugs me.

I tried vscode, but couldn't picture leaving emacs for it.

The percentage of the pie is smaller, but the pie has grown so much larger that in absolute numbers, there may not be any decrease.

> And also potentially shortsighted.

Looking at the recent releases, it feels like the vscode enshittification has already begun...

If vscode could replicate the fuzzy-search -> filter -> collect-to-buffer flows that I'm used to with emacs, I'd be right there with you.

I don't think there's an argument to be made that we're at risk of losing something. So much of editor progress in the past ~years is shared -- treesitter, lsp backends, linters and snippets, etc. It's hard for me to imagine how the editor ecosystem could collapse.

Could you elaborate on those flows? Sounds useful. Is it vanilla Emacs?

It’s very hard to describe without a visual but the gist of it is that the combination of the following 3 packages make it possible dynamically create queries, refine the results to precisely what you want, and then either perform some action on them or just plop them into a buffer for later use. There’s some notion of a type of the result, which means that the actions and results can be richer than just plaintext. Ie: you can imagine a query over a list of commits, where it displays while you’re searching as only the commit shortrev and subject, but where you can viably define a filter on the commit date or commit author. You can then export that list to a temporary buffer, and pressing enter on any given commit will show you the full diff and the full commit message. Orderless means you’re not crafting regexes directly, but just some combination of words in any order or casing.

Another example: grep in the current project for any function matching foo bar baz in any order followed by an open paren, restrict the search to only header files, export to a buffer, run search in replace in that temporary buffer, review the changes, then commit the modification to disk in every matched file with a single keystroke.

https://github.com/minad/consult/

https://github.com/oantolin/orderless/

https://github.com/oantolin/embark/

I can’t see myself leaving Emacs. Maybe for LunarVim, in an extreme case. But otherwise, no.

Amazing work again! EmacsConf was as fun as ever this year

Sacha is awesome!!!

Reply on news.ycombinator.com