Emacs 29.1 | Hacker News Reader

Emacs 29.1

emacsredux.com

378 pointspimeys308 comments

So happy to see my favorite IDE for the last 30 years being actively developed and maintained. Multiple IDEs have come and gone over those 30 years, and I waved to them on their way as they arrived and then as they passed away into nothingness.

Every time a new IDE arrived, crowds cheered, and it was all the rage and fashion, while my Emacs was called "obsolete", "hard to use", "bizarre", and other things. I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.

If I could tell something to my younger self, it would be: keep faith in solutions that are open and have been around for a while, you will save a lot of time over the years.

This is an emacs-centric world view and many of the same arguments applies to open source software in general.

Most definitely not. In fact, much of open source is haphazardly developed without regard for backwards compatibility, often also introducing change for no good reason (the word "cleaner" should always raise red flags).

Source: a certain developer/admin/netadmin with >30 years of experience using open source software.

Same here. It's the oldest continuously used piece of software for me. I tried it first on a Sun Unix workstation at the university around the late 90s. I've tried komodo, vscode, sublime, vi and many others and still use emacs. The funny thing I don't even know that many key combinations and use only a few customizations.

I was pleasantly surprised when I was issued a mac at work that most of the basic editing commands on macos text widgets support emacs key bindings (ctrl+a/e/k/p/n).

Those keybindings are one of the very few features of macOS I missed after going back to GNU/Linux. It's such a nice thought, especially with macOS using the command key for most, uh, commands - it doesn't impose any burden on non-emacs-users, but for those who are used to those keybindings, it's bliss.

GTK used to support a similar thing up to version 2? One needed to enable it with:

    gsettings set org.gnome.desktop.interface gtk-key-theme "Emacs"

Sadly, I think support was removed. Part of the problem was that this and other themes were in conflict with preset bindings, e.g C-p for a print dialog.

Yeah, on macOS it works well, because the Ctrl-based shortcuts don't get in the way of the regular keybindings.

It wasn't removed. These days, the setting is still exposed in GNOME Tweaks.

Those are 'readline' keybindings actually, and available in many term, shells, repls... Sometimes, just a config away. See: https://www.masteringemacs.org/article/keyboard-shortcuts-ev...

No an eMacs user myself, but do you ever imagine a time when the software might be considered “done”?

TeX and LaTeX are pretty close to 'done'

Nah. LaTeX is undergoing major development at the moment to support automatically tagged pdfs, and the latex3 work is still, as far as I understand, still ongoing too.

The race between LaTeX 3 and Half-Life 3 is still as exciting as it ever was.

"[a program] is never finished, only abandoned"

No, I think there is always something you can improve or add. The point, I think, is to do it carefully, though, without breaking things. Python is an example of how not to approach software evolution. Emacs and Clojure are examples of how software can be maintained over the long term without breaking backwards compatibility.

When I was young (and, ahem, stupid), I didn't care — I was all gung-ho, shoot from the hip, and if something breaks, tough. As I matured, I learned that backwards compatibility and long-term maintenance should be valued and cherished. Not just because if you're not careful, you have to fix the things that break, but also because as you start doing more and more things in your life, you have less time for each thing and you'd rather move forward rather than spend time fixing things that break.

Python is an interesting example to choose as a negative example. I presume you are referring to the evolution from v2 to v3. The popularity of Python has exploded in recent years, possibly as a direct consequence of tough decisions and breaking backward compatibility. I guess it is a subjective topic and an individuals position depends on how they define success.

Yeah. I'm always a little confused by this. It's still one of the most popular languages and growing for a reason. It surely isn't perfect, but no technology is. The tradeoffs they made have worked really well for a lot of people.

When looking at stats for Python's growth we have to remember 2 things. The number of libraries on PyPi is inflated by the same spam phenomenon which has infected npm, producing ludicrous library upload stats. Second, a large section of the Python userbase is non-programmers using it in a lab context to crunch some data and produce a pretty graph. Might as well be R or Matlab.

True, I've seen this with my projects in general (even outside software), the quality goes down as the quantity (of people involved) increases.

True, I've seen this with many projects in general (even outside software), the quality goes down as the quantity (of people involved) increases.

I think that's just your own experience being extrapolated a bit too much. In my own industry I'm aware of a few dozen commercial products. Every single one has a first class Python API. Most only have the one Python API. All academic scientists and engineers in industry (in my field) use Python with a little Julia, Matlab, or C++. It's presence has grown a lot in the past decade. In IT, there's also Java, C#, and Go.

In a field as young as software, three decades is too long for almost any software tool to remain frozen. Many new ideas might have built up — especially as the world around you (and needs) changes. You might keep writing extensions for your tool, or release periodic updates, or freeze your tool and call it “done”, and write a new tool every few years… they are all different ways to handle the same underlying mechanics.

Not to jump down your throat, but "eMacs" is hurting my eyes.

I blame sTeve jObs.

eMacs is just about the only word that autocorrect refuses to spell correctly, no matter how many times I nudge it to. And they haven't even sold a product called eMac since 2006. It’s a recurring reminder that this phone is owned by Apple, not by me. Frustrating.

I'm also very happy with Emacs' continued existence. Frankly, I don't know what I'd do without M-x shell plus related hacks, but I think I'd have to reinvent the concept of having arbitrary numbers of named shells with infinite output/input streams attached to them, with searchable histories, etc. Just like the unix concept that everything is a file was super powerful, so is the Emacs concept that everything is text. And of course lisp helps smooth things out whenever there are rough edges.

>Emacs was called "obsolete", "hard to use", "bizarre", and other things.

As a daily emacs user, it is all those things. It's just also awesome if you put in the time to get over the hump and learn it.

The "out of box" experience for emacs is really, really bad.

> The "out of box" experience for emacs is really, really bad.

That's not much different from a piano :-). Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.

The lindy effect applies to lots of things in life

1. https://en.m.wikipedia.org/wiki/Lindy_effect

As someone whose daily code editor was XEmacs during the heyday of UNIX wars, because Emacs wasn't as a friendly for GUI users, I really wouldn't call it an IDE, those were the things IBM, Borland and Microsoft were giving me on PC side.

I doubt if Emacs was a commercial product, that many people would bother to use it, same applies to VI derivatives.

If the experiece is above anything else out there, certainly it is worth paying for.

> Emacs was called "obsolete", "hard to use", "bizarre", and other things.

Well, Emacs isn't designed for a common user, but for a power user. From my experience, first time using Emacs was really frustrated.

In contrary, VSCode, Atom, Sublime Text etc. were usable right from the start. But these IDEs didn't stick for me. Easy come, easy go, I guess.

Emacs and Vim, although took a lot of effort to configure them into usable text editors/IDEs, stick with me 'til these days and I'm continuing to use them in the future. The power of configurations are astounding and I can shape them into whatever I want.

> Well, Emacs isn't designed for a common user, but for a power user. From my experience, first time using Emacs was really frustrated.

That's not different from a piano. Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.

> I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.

"wasted" sounds a bit too hard to me. If you learn and use some tool productively for some years, even if this stops, the years were not wasted. Ephemeral things can also have value.

To be fair, this release supports LSP and TreeSitter (which is super cool), but these are features that were pioneered by other editors and available elsewhere long before emacs. These ideas wouldn't be coming to emacs if it weren't for the experimentation and polishing done elsewhere.

One of my favorite aspect of Emacs is its configuration file. I use an org-mode file for configuration - which means that we can have rich documentation along with the code - all neatly folded up. The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file.

Similar executable org-mode files are used to configure the environment (sway) and personal information management (email, calendar & contacts). The latter one got so complicated that I had to add an integration diagram using the draw.io app.

The other great feature of Emacs is that its keybindings are so pervasive. Most native MacOS text input widgets and modern POSIX shells like bash and zsh use Emacs-style key binds for navigation and text editing. Also anything that uses GNU readline supports them as well out of the box.

Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-...

Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode

I've always seen this as an anti-pattern. You can make the documentation in an .el file as rich as you want without losing all the niceties that Emacs offers for interactively working with source code (e.g. find-{function,variable} will jump to the ephemeral dynamically generated .el file, not the actual origin of the code which is in the .org file).

Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?

Matter of preference. As an example, I may have a lot of configuration related to package X under one Org node. I merely have to "comment" the node headline to ensure none of that code gets to the config.

Your comment reveals your bias - that the code is more important than the commentary. The counterpoint is:

No. You can't make the documentation as rich as you want. I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.

> I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.

Thanks for adding this. Literate programming with org-mode is indeed one of my favorite from Emacs.

> Your comment reveals your bias - that the code is more important than the commentary

Yep! That's the key, imo. I love using Org mode wherever I feel that documentation is primary. So right now, most of my code that lives in Org files at work is shell snippets I've used for managing and configuring software. The literate approach is all I need there: I'm keeping track of what configuration I've done, not writing a giant, complicated program. Then I get the added benefit: the Org files form a wiki that I can use to refer colleagues to whether they use or care for Emacs or not!

Similarly, tangling shell snippets into scripts lets you write tests for your documentation! The examples become scripts and then the scripts can be run and verified in CI.

> Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?

I understand what you mean. But it never seemed to be a problem for me. Anyway, the real reason why I ended up with org-mode is that I heavily customize Emacs. The only way to be able to handle that much configuration was to split it up into a dozen or so elisp files. Org-mode's biggest advantage (for me) is that it can manage complexity very well. The org-mode configuration file is neatly divided into topics along with their documentation. The topics are also folded up - so it's very easy to find certain configuration segment.

> The latter one got so complicated that I had to add an integration diagram using the draw.io app.

Amazing that this is offered up as a selling point. If I didn't know I was reading a thread full of emacs users, I'd think this was a parody of a thread full of emacs users.

> I'd think this was a parody of a thread full of emacs users.

Haha! Indeed! Let me just clarify what I meant. I have a personal information management (email, calendar & contacts) where all information is stored locally and offline. The advantage is that I will never be locked out of my own data. However, this setup has so many components for syncing the info online and to interact with it. Quite frankly many of those components should be integrated into a single application. For example, mbsync can sync mail to a mail directory. But it needs go-imapnotify to trigger it when I receive a new mail. It's so frustrating that I considered writing those applications myself.

In short, Emacs has nothing to do with the complexity. Instead, Org-mode and emacs has actually allowed me to manage that complicated configuration in one place, with lots of documentation. The draw.io diagram was for the information flow between different software components for the PIM and email setup - not for Emacs itself.

Coming back to the complicated setup for PIM, I see a lot of new developments that promises to make it simpler. Hopefully, I won't need the org-mode power in the future to rein in the complexity.

> In short, Emacs has nothing to do with the complexity.

There are many cases where if I didn't have it's features like this I would have to sacrifice ease of use of my full system or hold tons of edge cases in my head.

> The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file.

Can I see (an example)? Wondering how much goes into that init.el.

Not OP but here's mine: https://github.com/nathanvy/dotemacs

The .org file gets processed and the source code blocks extracted into an elisp-only file which is what actually gets executed.

Some people prefer an alternate approach[0] with the "stub" init.el that just loads other modules.

[0] https://github.com/cute-jumper/.emacs.d/blob/master/init.el

Thanks for sharing both of these examples!

Sorry I couldn't post earlier. Here is a sample:

https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...

Thanks!

Treesitter and eglot are excellent. I am moving from vscode back to emacs and do far it’s been a great experience. Should’ve done that a long time ago.

Off-topic: what is an emacs quality alternative for docker? It’s such a piece of garbage for something so pervasive.

What aspects of Docker trouble you so?

I use containers on Mac and Windows for development (and we deploy on linux). Docker for Mac is _unusably_ slow in my experience. The VM that it runs is a giant resource hog and a battery hog, and doesn't support ipv6 [0] Docker Desktop itself is (another) resource hog, wildly buggy, and painfully slow. It's the epitome of "shitty electron app".

On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].

[0] https://github.com/docker/for-mac/issues/1432

[1] https://github.com/docker/for-win/issues/599

[2] https://github.com/docker/for-win/issues/1976

I was typing this on my phone, but yes. This. Thanks!

To add: Mac OS X docker actually, after a while, without errors, stops responding to running dockers and you cannot remove them without reboot. It’s total garbage, but cannot move from it as everyone uses it.

So, emacs-stable alternative for docker. Maybe that should be a movement; emacs-alternative-for. I have many already; software that is fast, can run for months/years and doesn’t get slow vs stuff you need to actually reboot for to run ok. I mean emacs is bloated (yeah right, compared to whatever others are pushing out?) but disk space, even sdd is almost free; it simply runs for months without memory growth or performance degradation. The only reason I stop it because of reboot for sec updates.

I've switched to orbstack on Mac. My experience is significantly better.

It's the opposite of emacs-stable for docker, but it's what I want out of docker.

Maybe we mean different things when saying that; I mean that I can throw anything sensible at it and it keeps on chugging. I know if I do something weird, it might die. During dev sessions I don’t do that, I just want to run vanilla containers like mariadb, node etc and pray they don’t randomly crash (they do).

Ah, ok. Yeah it works great. When you said emacs, i assumed you meant long term stable, libre philosophy.

Orbstack is what docker for Mac should be.

I've been using Colima (which uses Lima, and QEMU under the hood) and it works fine for me. https://github.com/abiosoft/colima

Isn't this a kernel-side problem, though? The whole metaphor behind docker is "containers are super-fast and easy". And they aren't on OS X or Windows, you have to use a VM. And that's slower.

There are tortuous and awful arguments around about whether this is inherent or not, or whether the tradeoffs are worth it or not, or where the blame lies. And I'm not interested in getting into any of that.

Nonetheless the core idea behind Docker is slow on a Mac, because the Mac doesn't implement anything like the kernel feature on which it was built.

I don't believe so, no. I think it's an artifact of docker being engineered to run on Linux and taking the "easy" option of running a VM.

I have no affiliation with OrbStack, but am a happy user. Orbstack is an example of what docker for mac should be. It's fast, lightweight, and it works.

If you're developing for Linux via Mac or Windows and you're comfortable at the CLI, just forego Docker Desktop, install regular Docker (or podman) in a VM, and work that way.

If you can, avoid using x86 Linux containers on Apple Silicon. Build some aarch64 ones for development and test your x86 images in CI and on the machines of devs using x86.

Similarly, if you can avoid deploying your environment via Linux containers on macOS, do it. Use Nix to get reliable dev envs, and then use Nix to build your production containers. You'll have to take your time and learn something new, but it's insane how much faster it is and you can avoid dealing with all kinds of hassles with filesystem mounting and port forwarding and so on.

> If you're developing for Linux via Mac or Windows and you're comfortable at the CLI, just forego Docker Desktop, install regular Docker (or podman) in a VM, and work that way.

That's pretty much what docker desktop does anyway, except it bridges the host with th containers in the Vm. I don't think it's worth throwing out all of the interop there because Docker the 2-billion-dollar company can't handle basic networking on windows and Mac.

> Use Nix to get reliable dev envs,

I'd really rather not throw away all of the _good_ docker has - despite my complaints, I still use it every day.

> That's pretty much what docker desktop does anyway, except it bridges the host with th containers in the Vm. I don't think it's worth throwing out all of the interop there

On WSL, incl. WSL2, you get bridged networking 'for free'. I'm not sure what Docker Desktop adds there. I'm not really on Windows anymore. But WSL is part of the picture when it comes to Docker's awful performance and memory leaks on Windows. If you can give up WSL/Hyper-V in favor of a better hypervisor, you can get much better performance.

> I'd really rather not throw away all of the _good_ docker has - despite my complaints, I still use it every day.

I guess we differ there, in that I don't really think Docker (which is really useful) is a great fit for local development— especially on non-Linux. There are other teams at my org who develop using Docker, and for those I've spoken to it's been a real win compared to what they had before! I respect that. But my team currently only uses Docker in CI and in cloud deployments rather than for local development, and I'm pretty happy with that.

I did the same a while back.

I've been enjoying podman.

Thanks will try.

> Off-topic: what is an emacs quality alternative for docker? It’s such a piece of garbage for something so pervasive.

Nix and direnv via envrc-mode.

I'd really love Emacs to have native JPEG XL support. For I use Emacs as a pictures viewer and the only thing preventing me from converting all my family pictures from JPEG to JPEG XL (it's a 22% saving which results in JPEG XL files that can be converted back, bit-for-bit, to the original JPEG file) is the lack of Emacs support for JPEG XL.

Does anyone know if it's coming? Anything in the JPEG XL or JPEG XL libs license that makes it a problem to incorporate in Emacs?

Why not add support? Nobody owns emacs any more or less than you!

Well ofc and I know some elisp but I take it integrating libjxl (now using the "new BSD license") or another library supporting jxl is one of those things requiring C guru skills. And it's been a really long time I haven't written a line of C code.

Moreover I take it that, say, for someone who added WEBP support to Emacs, adding JPEG XL would be kinda a no-brainer.

But I fully get your point...

Emacs can handle JPEG XL files as long as you build it with ImageMagick enabled and ImageMagick is built with JPEG XL support.

You can try evaluating (imagemagick-types) to see if it's enabled. If it fails with "void-function" that means that your Emacs was not built with ImageMagick enabled. If it returns a list of file types but the list doesn't contain "JXL" then your libMagick might be too old or not compiled with JPEG XL support.

Ah that's interesting, I wasn't aware. I'll try that and recompile if needed, thanks a huge lot for the info!

> ... then your libMagick might be too old

I did check: I'm running the latest Debian stable, Bookworm, which basically just came out and it ships ImageMagick 6.9.11 but apparently JPEG XL support was only added in 7.0.10.

Oh the joy of running Debian! (I'll see if I bump ImageMagick to a more recent version or not).

Looks good. For me, the best recent feature is native compilation so Emacs feels super fast and responsive. I often use macOS and I wonder is going to GTK will help a lot there?

Native compilation has been in emacs since 28.1.

AFAIK native GTK should be unrelated to macOS since macOS version uses its own cocoa frontend

As another commenter has said native compilation has been there for a while, but you may need to explicitly enable it if you’re installing via brew or similar. The macOS port doesn’t use GTK or X unless you specifically link them. What problems are you having?

I wonder if the latency would be comparable to neovim/vim? I've only tried Emacs without nativecomp and the really noticeable input lag left a bad impression.

As someone, who jumps between neovim and emacs on a regular basis - no, neovim is much faster. If speed and general snappiness is your most concern you should stay with neovim.

But, emacs is in most cases fast enough, faster than vscode and has other advantages.

In my experience Emacs is slow when I enable evil. I do like vim keybinding, but using evil negates most of the benefits for me since it introduces unbearables pauses. That is with Doom emacs under Linux.

They can be disabled in the init.el, I’ve done it for a year or so. Emacs-keybindings are less ergonomic, but also have less cognitive overhead imo.

The exact setup I tested (evil+doom) but without nativecomp, same feedback

Native compilation makes a big difference, but neovim is still snappier, especially if you’re using lots of packages or a framework like doom or whatever

Tui emacs is a bit slower than nvim, but close enough.

Gui emacs is much, much slower than nvim

How do you compile Emails on OSX? I use `brew install emacs-head@30 --with-cocoa` and I feel that org-mode is bit laggy. Is there a better way?

Add `--with-native-comp` to that.

Thanks, time to try this

Oh, I just realized I'm using https://github.com/d12frosted/homebrew-emacs-plus . I recommend using that over the default formula.

I use this one https://github.com/daviderestivo/homebrew-emacs-head

download the source, unpack, cd into directory, ./autogen.sh, ./configure --with-imagemagick --with-json --with-mailutils --with-modules --with-rsvg --with-gnutls --with-xml2 --with-native-compilation=aot --with-pop --without-compress-install --without-dbus, gmake (gnumake from brew), src/emacs to test, gmake install, pickup the app in nextstep and done I think.

(thats on intel monterey though)

makes me wonder, is the target of native compilation something general like 386 ? can i share .eln between x86 computers ?

Really happy to see this. I've been using Emacs 29+ for the past while and have enjoyed simplifying my configuration now that use-package is OOTB. I think now is a really excellent time to try Emacs if you haven't already.

I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:

https://emacs-config-generator.fly.dev/

I tried generating a file [1] and got this error when running emacs:

> Symbol's function definition is void: package-vc-install

[1]: https://emacs-config-generator.fly.dev/config?font_family=Me...

Hm, what's your `(emacs-version)`? `package-vc-install' is only available in Emacs 29+.

Looks like it’s acually 28, my bad; thanks, I’ll update and retry later.

> Emacs is now capable of editing files with very long lines. The display of long lines has been optimized, and Emacs should no longer choke when a buffer on display contains long lines. The variable 'long-line-threshold' controls whether and when these display optimizations are in effect.

Yes!

NEWS: <https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=...>

Official release announcement: <https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>

What an amazing release. Thank you to all that contributed and made it happen!

And they haven't even started taking full advantage of Pure-GTK and Treesitter. This release will cause an explosion new packages based on them.

What kind of new packages would spawn from the introduction of PGTK?

This video discusses the work on pure gtk: https://www.youtube.com/watch?v=LPwr8WeE8jU . I found it by following this story. It talks about Emacs essentially becoming a GTK widget and possibility of nesting GTK widgets in Emacs. I'm not fully aware of what they will lead to.

Oh, that is extremely interesting!! It would be great to hear more about this!

Took a new job and ended up putting emacs aside. Using Google's Lit framework is unbearable on emacs. It has some deeply nested html/js in template strings and emacs can't keep up with the nesting.

Is this with or without Treesitter?

Either. The best results I have had was with web-mode which has some basic support for it. I also tried using LSP mode and the two Lit extensions for the Typescript server but that did little to help either.

Figured it out! I had LSP configured to use the two lit typescript-ls plugins but because I was using web-mode, that language-server was never kicking in. Going to try getting treesitter to do the highlighting and then hopefully LSP will provide some nice-to-haves now.

Probably needs its own extension like in vscode.

It should be able to. Emacs has good built-in support for navigating around substructure as long as you're operating with a mode that recognizes the substructure.

I'm not familiar with Lit, but if emacs can't grok all the nesting, how is it even remotely human comprehensible?

With proper syntax highlighting it's fine. But this is why I have moved away, it's hard to read without good syntax highlighting. I don't know why extensions aren't handling it. Web-mode does but only the first level or so of nesting.

Sounds like a good application for treesitter

Every single time i open up the tutorials on how to learn emacs, a million other priorities come along. I know there are die hard fans of it, and I'd love to learn it, but with VSCode, vi, tmux, and all the MacOS tools i know, I'm not sure I'll get around to learning it before i burn out completely from engineering

I hear you. The only way I could get around trying to learn Emacs was to stop and actually use it as my daily driver (making a pact with myself not to use another editor for 15 days). Given "normal" editor keys (cursor keys, page up/down) work out of the box in Emacs, this wasn't hard (you could enable CUA additionally for regular cut, copy, paste, I stuck with kill and yank though).

Emacs is daunting, I've used it since grad school in the 80's, and I'm still familiar with only a couple of hundred packages/extensions available out of thousands that are available. Likewise, I use maybe a couple of hundred commands and key bindings (out of thousands available--Emacs interactive help with finding the commands makes this possible).

I can imagine how hard it must be to learn the basics buried within a mountain of functionality. The way I learned to use Emacs originally was by learning to use a stripped down Emacs-like editor that ran on my home PC running MS-DOS. This editor used the same basic key bindings and supported the fundamental operations one uses to edit files: navigation, directory browsing, reading and saving files and so forth, all with the same keys that full blown Emacs uses.

Instead of installing Emacs, try installing micro-Emacs (its actual name is mg). This should run on Linux, MacOS, or Windows. On the Mac, you can install mg using homebrew. This is a perfectly good editor, and it uses the keys and commands that make up most of the ones I use every day. It just has fewer features, no Org mode, no image browsing, no support for git, no Email clients, no GPG support, no Voice output, no games, etc. It's just a solid text editor that will run in text mode.

Within a few days of using mg, you will be able to navigate around a document, open and save files, browse directories, and know how to get basic help within the editor. Then try Emacs and only add extensions as you need or want them.

Does intellisense like autocomplete now work out of the box? Is company bundled in, as of recent versions? Is there any dependency on Clang to get it working for C/C++ code?

You still need to set up an LSP server, so not exactly out-of-the-box. Something like clangd or ccls for C/C++.

Eglot is the built-in LSP client. You need an external server. If you do C or C++, clangd is likely what you want. Install it (apt install clangd) and enable eglot for C or C++ files in your Emacs config, (add-hook 'c-mode-hook 'eglot-ensure).

And if you are in a legacy system with no clang then?

Emacs is usually batteries included, couldn't an lsp server have been part of the package..

Then it would just have a dependency on Clang, and you couldn't use Emacs at all (since you can't use Clang).

AFAIK, the only alternative to the clangd language server is ccls: https://github.com/MaskRay/ccls

That'd increase the package disk footprint by a large value since there are many languages supported by Emacs by default.

emacs has never been in better shape

For a 50 year old project, they have been quick to adopt new technologies like Tree Sitter lately. It definitely feels there is a lot of activity behind the scenes to remain as relevant as ever in face of editor fads such as VSCode and (ducks) NeoVIM.

Gnu emacs is only 38 years old. And vscode is a fad...?

VSCode is very much a fad, much like Eclipse, Atom, Sublime and any number of others before it. Emacs and Vim just keep going whilst others fade away.

I agree that sublime is a fad and maybe atom. Sublime’s biggest mistake imho way their proprietary model combined with a plugin system, it’d probably be better to either make it free or make it very ease to use. I don’t see eclipse or VSCode as fads though. To my knowledge eclipse is the only way to develop Java code on Linux platforms without paying for richer tools (let’s face it, eMacs or vim doesn’t have much support for Java). Also Microsoft seems very invested in VSCode

> eclipse is the only way to develop Java code on Linux platforms without paying for richer tools

All the people I know are using IntelliJ CE.

I'm a long-time Emacs user, but VSCode is definitely not a fad. Microsoft is all-in on it, and it appears to be by far the most popular text editor.

https://survey.stackoverflow.co/2023/#section-most-popular-t...

https://trends.google.com/trends/explore/TIMESERIES/16907280...

> VSCode is definitely not a fad. Microsoft is all-in on it

Similar to those who were all-in on Eclipse, Atom, Sublime?

I do think vscode will stick around longer, but not convinced it'll be long enough to not feel like a fad.

The two URLs I provided don't convince you that this isn't a fad? Of all the SWEs I know, every single one who previously used Eclipse, Atom, or Sublime is now using VSCode. Some of my Emacs & Vim friends have switched, too. I can't imagine what would change this trend in the next 5-10 years. Perhaps a new editor with an integrated LLM coding assistant that's FAR ahead of all competitors? Except VSCode is currently leading there, too.

I think we're stretching the definition of "fad" a lot here. Editor being one of the most popular for 10 years (not yet there, but will be for sure) can't be considered "fad".

>Similar to those who were all-in on Eclipse, Atom, Sublime?

But all these (except sublime) including vscode are basically the same type of IDE. Yes, implementations change, but their share of the "market" remains about the same.

Eclipse and vscode are the same type of IDE? What?

VSCode is not a fad - it has huge support from Microsoft, is the most popular code editor by far, and is a very good tool that's beginner friendly and allows for customisation. It is already almost a decade old. Visual Studio has been around since 1997 so there's a good chance VSCode will be around for a good few years too.

IT is a fashion business, and fashion is fickle.

There will always be an editor which is an order of magnitude more popular than emacs or vim, because it is an order of magnitude better. It doesn’t much matter which one it is. People will switch to it, and be productive. And when something better comes along, they will move to that.

I strongly disagree that any editor will be an order of magnitude better than Emacs or Vim. Some new editors will be better in certain ways, or add cool new features before Emacs/Vim do, but there's nothing completely better than them. I doubt there ever will be.

Emacs requires fiddling. Once you get past a certain age, you no longer want to fiddle with your tools; they should just work. A tool that just works may well be therefore orders of magnitude better than Emacs.

I think that downplays how much fiddling other tools take. I've never used another similarly powerful editor that didn't require similar amounts of configuration to be useful. And if getting some random plugin working means you have to tweak its code, it's almost certainly going to be fast and easier in Emacs than in the other. With Emacs, you can generally just replace a function after its been loaded. In other things, you may be forking a repo, editing/compiling it, and figuring out how to get the editor to load your version of it.

> In other things, you may be forking a repo, editing/compiling it, and figuring out how to get the editor to load your version of it.

This is more a theoretical problem in VSCode. If you just want to start programming using a mainstream language or framework, in VSCode it's literally a matter of saying 'code .', downloading whatever extensions it recommends for the language it autodetected, and starting work with autocomplete, debugging support, and all that ready to go.

Read @bborud's comments in this thread. He had been using Emacs for even longer than I, and he switched to VSCode and is not looking back. Because Emacs requires fiddling to keep running and VSCode does not. And that makes VSCode better.

The experience with distributions like Spacemacs, doom emacs or lazynvim really isn't that much worse than vscode, you select the language you want to code, it installs a reasonable set of plugins and you get to work.

VSCode is here to stay. After eight years it is by far the most popular programming editor and only becoming more so. The sun was already setting on Sublime and Atom by this long after their initial release.

computing is a pop-culture; that which completely ignores what went before it, and continues to spend much of its time naively re-inventing the wheel

Indeed, but VSCode is "sticky" in the way those other editors are not. It now has a critical mass of developer interest such that language and framework developers now put out tooling for it first (if it's not the only editor with official support). Other editors will have to make do with third-party tooling from a dwindling pool of contributors, falling farther and farther behind the state of the art.

will we ever escape javascript in our lifetimes?

I used Emacs for all development work from about 1990 to 2018. About 28 years of development work in a dozen different programming languages. I also used Emacs for reading Usenet News and my email. I also used it for calendaring, planning, tracking work and a few other things.

Gnus made Emacs a great Usenet news reader, but I could never get it to fit with my email regimen. And eventually Usenet died too. For about a decade I used a mail client that someone else originally wrote, but which I modified over the years to do email like I wanted to. But this became really tedious to maintain alone so I have up.

Along the way I tried various IDEs like the tools from IntelliJ and Eclipse. None of them took. In fact, I figured it had to be me, so I promised myself to spend a few months every 2-3 years or so trying to get used to IDEs. (I still can't stand the IntelliJ and Eclipse tools).

I think what made me switch to VSC was that I eventually grew tired of the constant annoyance of having to fix my setup so it would be reasonably useful for Go development. Emacs support for the Go language server was slow and shaky, and eventually I got so tired of having to make a patchwork of Emacs packages work that I gave Visual Studio Code a second chance.

And the second time around it stuck. I'm not entirely sure why it stuck, but it did. It's been 5 years and I'm still using it. And I'm still not entirely sure why. I think it is mostly that I'm a programmer - not an editor enthusiast. Emacs was a pain in the neck to keep running when I switched. I liked Emacs, but VSC has better support for just about any language you care to program in.

I ditched Emacs because I'm interested in writing code. I'm not interested in spending a day figuring out how to keep barely working Go support running so I can get work done. It's a tool. And when maintaining the tool starts eating into my productivity, it isn't worth the effort.

The problem with Emacs is that it doesn't have a sufficiently large community. Which in turn means that if you are interested in creating tooling, your efforts will have a much bigger payoff if you choose something millions of other developers use. This is a vicious cycle.

Last I checked, VSC had about 14 million users. Out of a global population of 25'ish million developers. That's slightly over half the global developer population. That's a pretty big market. I think a fair guess (given the stack overflow surveys) is that less than a million people use Emacs as their primary development environment. Which I find surprisingly high, but it should give people hope.

Is VSC a fad? Who gives a crap? What matters is that, for me, and for a lot of other people, it is a better tool than Emacs. Because it is. If VSC is replaced by something else that works even better, and VSC disappears: who cares. Better tools is a good thing. Getting overly attached to tools that offer less is just weird and unproductive.

could you summarize in 1 sentence?

I don't know if their sentiment could be summarized into one sentence, but I recommend reading it in full.

Why?

Enshitification is coming to VSC, and when it does, you'll be back.

Maybe VSC will worsen over time. In which case I'll move to whatever is a better alternative when the cost of moving feels lower than the cost of continuing to use it. Just like what happened when I stopped using Emacs.

I'm assuming that "you'll be back" means I will start using Emacs again for programming.

Well, for that to happen Emacs would have to provide a better programming experience for the environments I care about than VSC does. Right now it doesn't. If or when it does, I might consider it again.

I did the exercise of installing Emacs 29.1 yesterday and trying to set up a Go programming environment from scratch. After about one hour of head scratching I had something that barely worked and I wasn't entirely sure how to get it all the way there. That's not a good user experience. It is going to be an even worse experience for someone who hasn't been an Emacs user for a few decades.

It would make me happy if Emacs was a better alternative. It just isn't. If someone has the time and commitment to fix that I'll certainly consider it, but we know that at best, that's going to be years away.

configuring vanilla emacs from scratch is certainly a lot of work. There's various distributions (Doom emacs, Spacemacs) that while not perfect have a pretty decent 'new user' experience without too much work. I don't use Go too much but I've done some projects in it. I just uncommented (go +lsp) in Doom's init.el, ran doom sync, restart emacs, and everything just worked, I didn't feel that need to configure anything further.

it's a bit wider and better than eclipse/atom/sublime

there's also the devcontainer and vscode server thing which make vscode a sophisticated commodity

i don't use it, but i've seen the previous eras, the eclipse haydays .. and vscode doesn't feel the same

Eclipse and Sublime do still exist and receive improvements. And VS Code is at the moment far too big to fade away in the next years, maybe even decade.

Sorry, for some reason I thought it was started in the mid 70s.

But yes, compared to Emacs , Code is a passing fad, and I doubt it'll be around in 15 years, let alone in 38

Emacs did start in 70s ('76, I think), GNU Emacs is later.

vscode is the bitcoin of editors

> For a 50 year old project, they have been quick to adopt new technologies like Tree Sitter lately.

From the following it sounds more like a first step towards true adoption:

> built-in support for TreeSitter. This means that a few years down the road we’ll have many Emacs major modes that are much faster, robust and feature-rich.

They have even started an Android port. It's on F-Droid already - though it's not very usable yet.

The F-Droid port comes from here: https://sourceforge.net/projects/android-ports-for-gnu-emacs

Newer builds have better usability (although there are definitely still quirks). I recommend using it with the Hacker Keyboard for easy Meta-key access.

I didn't know that! How is this related to the official android feature branch?

Is there a way to get the keyboard to show yet?

Is hackers keyboard available on latest android?

It's a shame modern distros don't ship with it...

Yes! I have Ubuntu at my office and is difficult to get the latest emacs. I found a PPA but it has a bit of lagging behind..

My approach has been to install Guix, and with Guix install emacs-next (and python-wrapper, and python-pip).

I'm still a Guix newb, so all I can say is that there may be some tweaking to be done if you're using non-default paths, (e.g. XDG Base Directory Specification) [0].

[0]: https://mail.gnu.org/archive/html/guix-devel/2019-03/msg0045...

There's a snap that's updated very quickly:

https://github.com/alexmurray/emacs-snap/

In fact, it's already updated

Does this have native-comp enabled? Or do you still have to build from source for that?

No, it's enabled by default. Last I built Emacs, it took me more than an hour to build.

The default branch has native-compilation, tree-sitter, and json enabled. See here for the enabled flags:

https://github.com/alexmurray/emacs-snap/blob/master/snapcra...

It would definitely be nice to have an updated PPA, but compared to some apps, Emacs is simple and fast to compile - just a ./configure followed by make. (The first time, you need to install a few dependencies, but that's automated too, something like apt-get build-dep emacs).

> fast to compile

Last I tried building Emacs, it took me more than hour. I now use a snap that's updated very quickly and is already updated to 29.1:

https://github.com/alexmurray/emacs-snap/

It takes under a minute with an ancient i5 for me, so I'm not sure what would cause yours to be so slow.

I have a script to build it myself, took a little but of time to get right, but now it works nicely and I can stay at the bleeding edge.

All these answers got me inspired. Might as well try this. But for the sake of not reinventing the wheel, Would you mind sharing? Maybe as a github gist or any pastebin would suffice. (PS. I'm already afraid the GCC version of my Ubuntu 20 throws issues hehe! Let's see!!)

Sure, here's the gist of it with some unrelated stuff removed. This was made for Ubuntu 18.04, but the deb will work on 20.04 as well.

    apt-get update
    apt-get install  -y git software-properties-common make checkinstall autoconf texinfo

    add-apt-repository -y ppa:ubuntu-toolchain-r/ppa 
    add-apt-repository -y ppa:ubuntu-toolchain-r/test 
    apt-get update

    apt-get install -y gcc-10 g++-10 libgccjit0 libgccjit-10-dev libjansson4 libjansson-dev libgtk-3-dev
    apt-get install -y libjpeg-dev libxpm-dev libgif-dev libtiff-dev libgnutls28-dev libncurses-dev

    update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 10
    update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-10 10

    git clone --depth=1 git://git.sv.gnu.org/emacs.git  --branch=master # or use emacs-28.1 or whatever tag
    cd emacs || exit

    ./autogen.sh
    ./configure \
     --with-cairo \
     --with-gnutls \
     --with-harfbuzz \
     --with-jpeg \
     --with-json \
     --with-mailutils \
     --with-modules \
     --with-native-compilation \
     --with-pgtk \
     --with-png \
     --with-rsvg \
     --with-tiff \
     --with-wide-int \
     --with-x-toolkit=gtk3 \
     --with-xft \
     --with-xml2 \
     --with-xpm \
     --without-compress-install \
     --without-gconf \
     --without-gsettings \
     --without-imagemagick \
     --without-toolkit-scroll-bars \
     --without-xaw3d \
     --without-xwidgets \
     CFLAGS="-O3 -mtune=native -march=native -fomit-frame-pointer" \
     prefix=/usr/local

    make -j"$(nproc)" NATIVE_FULL_AOT=1

    checkinstall -y -D --install=no \
      --pkgname=${pkgname}-nativecomp \
      --pkgversion=1"$(git rev-parse --short HEAD)" \
      --requires="libjansson-dev,libharfbuzz-dev,libgccjit-10-dev" \
      --pkggroup=emacs \
      --gzman=yes \
        make install-strip

The core issue is there isn't a 'emacs.tiny' package that contains a small subset of emacs features.

This makes it difficult to install emacs on a resource constrainted environment like a embedded system, and hard to justify installing on a server. (Yes we can use tramp but it's not always a option)

It's a real shame and why I still need to know vi and vim.

Most emacs users I know retain a modicum of vi/vim knowledge for those situations where emacs isn't available. It's more because of the ubiquity of vi/vim, though. There are mini versions of emacs available like MicroEmacs and mg, the latter being more compatible with GNU Emacs.

Debian and derivatives (like Ubuntu) have the “emacs-nox” package, which should qualify for your needs, I think?

It's a step in the right direction, but the issue is that there's so much that can't be removed from Emacs with build flags, eg. `lisp/play/`. Even setting the `-games` USE flag in Gentoo only removes cross-user score sharing[1], because (although less likely with games) you never know what modules might depend on within the standard distribution. Emacs is a big ball of stuff that no one's been willing to tease apart, even when it comes to modules that are probably not going to be loaded at runtime.

1: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/e...

One option is uEmacs (or one of its many forks such as mg). It’s tiny.

Built it this morning on Gentoo!

Which version am I running yet? (I know it's not too old for I regularly compile Emacs from source)

    ELISP> (emacs-version)
    "GNU Emacs 29.0.60 ..."

Ah... Time to upgrade ; )

I haven't touched my emacs config in a while, looks like it's due for a big update! I'm excited!

Thank you Eli !!!

For Clojure there's nothing better than Emacs + CIDER/nREPL. I've tried Calva/VS Code, Conjure/NeoVim and Cursive/IntelliJ but none of them come close. Maybe it's the ELisp foundation facilitating code-as-data.

Sadly this doesn't play well with fzf-el (at least not with fzf-find-file). I've entered a ticket on the fzf.el github, but it seems a mostly dead or dying project.

Anyone else use fzf successfully with 29.x?

Is performance any better than 28 on Mac？ I recently tried putting 28 on my work M1 and magit diffing on the status screen, where you can roll up diff hunks by hitting minus, was unusably slow on large files. My own Linux laptop has no such problem.

That's actually a git issue - git is notoriously slow on OS X, and magit uses git heavily in a way that is correspondingly slow.

What does a new release like this mean for popular frameworks like spacemacs or doom emacs?

E.g. for lsp support, are the frameworks switching to the native one or are they going to rely on their current setup for now? Or is there no common approach?

In Doom emacs, you can add the +eglot switch to your lsp tool to use Eglot (the new setup) instead. https://docs.doomemacs.org/latest/modules/tools/lsp/

For Spacemacs remember to use the devel branch, not stable which hasn't been updated in ages.

Right, emacs upgrade is now added to the list of things to do on my day off tomorrow.

First I thought that emacs/vim are about productivity. You invest some time to learn its concepts and train muscle memory. In the end of it turned out that you have to forget about spending weekends away from your PC. Not much time was actually saved. My conclusion from all this: this is just another way of doing things with no huge benefits but with bigger portion of loses (at least because this is not mainstream).

Use helm-M-x and which-key, and avoid anything but use-package and customize. You don't have to eat the muscle-memory elephant all at once.

Or just install spacemacs and get a lot of that set up for you for free, plus a bunch of other cool stuff.

Spacemacs hinders your growth with Emacs over the long run. It hides Emacs internals from you and jumps through a lot of hoops to make Emacs feel modern. But the beauty is skin-deep and the second you start wanting something off-script, you'll find it getting in your way, with online threads and such catering towards vanilla rather than frameworks.

I disagree 100%. There is literally nothing you can do within init.el that you can't do within `.spacemacs`, and you will rarely have to venture outside of `dotspacemacs/user-config ()` except to add layers or packages to the appropriate config variables so they can be installed automatically for you.

I've been using emacs for over 10 years and had zero issues with making the transition. On the contrary, it's simplified my emacs life quite a bit. The only thing I have not been able to get working is `eaf`, but that's clearly not the fault of spacemacs.

Of course there isn't. It's all elisp under the hood. Realize though that you started with vanilla and moved to Spacemacs. Most people are going to do it the other way around. Start with Spacemacs and you're guaranteeing yourself a rough time, because you won't have the understanding of vanilla you need in order to customize it. I wound up dumping both Spacemacs and Doom once I finished reading Mastering Emacs. I may move back in the future but for now I'm much happier with a simpler system.

The main advantage of encountered is that it doesn't go away.

I've been in contexts where I can't use vscode and I've been in contexts where I can't use intelliJ and so on. The contexts where I can't use emacs (specifically, emacs configured to my preferences) are thin on the ground.

It's a space alien user interface and software abstraction relative to most out there, but the payoff is I never have to put it down.

In what context can you use Emacs but not another editor?

When I'm on shell only and can't bring up an X session for a GUI.

This scenario is fortunately pretty rare these days, especially since vscode supports remote editing, but it still happens from time to time and I can still resolve the issue by just dropping emacs on the target machine and working with it in terminal mode. And vscode is a relatively new option here; If I cast the bones, I predict it will be around for awhile.

In that scenario you can often use Tramp - run Emacs locally and let it use ssh and scp to modify the files on the target system. Does the VS Code remote editing require some kind of server component on the remote system or does it manage it through ssh and shell commands?

Thankfully the cases where the only available editor is /usr/ucb/vi are starting to get rare.

I'm well-familiar with Tramp and love it dearly.

It has several does-not-play-well failure modes that vscode remote doesn't. My favorite is that if I have an ssh out and the session goes down, then (in a way not unlike how a terminal ssh'd out will act if the session goes dead) emacs will just freeze. But apart from those, it's super-great and I do love being able to just treat some random data on some random server or user as a buffer and bring to bear on it everything you can hit a buffer with. That decontextualization, that fitting of one abstraction (the buffer) to so many contexts, is one of the best things about emacs.

Yes, vscode does what it does by installing a remote on the target machine and operating from there.

I rarely see Emacs freeze even with Tramp, but admittedly I rarely see broken connections. I think in that case VS Code will throw up a modal dialog telling you to reload the window, and after reloading you have the option to sever the connection.

For me the main problem with Tramp is the slowness - opening and saving files takes just a tiny bit too long. I'm sure VS Code's approach with a remote server can be faster.

More like someone who works on their own car. Yeah, they lose the occasional weekend to the maintenance, but they love that they've had the same car for 35 years.

However with Emacs, there are a few thousand other people working on the car too, so despite the fact it's the volkswagen beetle you bought in 1972 and your butt shape is indelibly formed in the cockpit, it has _also_ got electric power train, full self driving and JATOs. :)

I used Emacs every day for 28 years. Until I got really tired of having to put it up on the jacks, as it were, for a weekend every now and then. In order to deal with the fact that everyone who works on Emacs seems to think everyone else is just as enthusiastic as them about spending their weekends fiddling with Emacs.

It isn't for me. At least not anymore.

Dealing with Emacs is a lot like dealing with software written in Python: probably great if you really like going trough long descriptions of how to get something to work. Not so great if you are more concerned with using the tools rather than fiddling with the tools.

Yeah, that couple hours a year is a real killer.

Nothing kills it!

Except maybe a file with really long lines.

This has been addressed in Emacs 29.

From the NEWS file:

Emacs is now capable of editing files with very long lines. The display of long lines has been optimized, and Emacs should no longer choke when a buffer on display contains long lines.

Finally! Thanks.

I am an Emacs enjoyer. My biggest issue with Emacs is that development is still done via a mailing list and patches. I wish they would adopt a Git front-end (web UI) workflow.

As an occasional developer of PostgreSQL which also does development on the mailing list I see pros and cons with it. It is harder to discuss lines of codes in a review on the mailing list but the nature of the mailing list (threading, etc) promotes much more nuanced and constructive discussions about patches on a higher level. Something which I have yet to see in any project on Github.

Gitlab has some threading support but not very good one.

It's really not that bad, it's just different. There's pros and cons.

https://git-send-email.io/ has a great tutorial for getting started.

There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.

I think the mailing list flow is a hindrance to attracting the next generation of contributors.

The "next generation" of Emacs contributors will be Emacs users and will not have any issues using email for collaboration.

Git was made for email. Needing a separate service for it is mostly cruft, when you have mailing lists. Yes, github has mass appeal, but a lot of software has been written with just email collaboration.

As for attracting low-quality contributions, I don't think they matter. People who use Emacs and depend on it will contribute. Interest in Emacs has increased and so have the available features.

This! I'm happy that Emacs isn't the greatest editor or the most-used/-popular; it needn't compete with say VSCode or vim.

There's a decent, loyal user base, importantly not the free-loading, entitled kind who water it down; they're like-minded, appreciate the philosophy behind it, don't mind tinkering with some LISP here and there, contribute their creations as answers or packages, and above all form a nice community helping each other.

As lazy as it seems, I’ve made a couple contributions to Neovim whereas I probably wouldn’t have bothered if I first had to figure out a mailing list flow.

Personally, I think that it's the copyright assignment that's the biggest barrier. For someone who figured out how to use Emacs, it shouldn't be very hard to figure out how to use a mailing list too.

This. A mailing-list-driven workflow is not as difficult as it appears, and Magit makes everything a breeze. However, I cannot complete the copyright assignment process, and consequently I am unable to contribute to the Emacs proper beyond a few lines of trivial changes.

It is so discouraging that I stopped working on the Emacs core [1] altogether: your contributions won't be acknowledged at all, even if someone volunteers to rewrite your code from scratch.

[1] I've been hacking some GUI-related features, but I'm not motivated enough to complete them. I also tried to write patches for my bug reports, but alas, my "CA-free" quota is already used up.

I don't think the Emacs maintainers would want to accept contributions from people who cannot figure out email.

This is absolutely true and is one of the stronger arguments for the Linux kernel to adopt something like GitLab as well. Being able to take PRs for smaller contributions while still keeping core development on mailing lists (probably with an email bridge between so things aren't missed) seems ideal to me, but that's extra work for maintainers and whatnot

> There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.

The further I get into "emacs for everything" the more I appreciate using email for everything.

You can use emacs as web client

I love Emacs (it was my main editor in the last 20 years) but i can't justify anymore to use it due to lack of modern feature, ease of use and maintenance of the .emacs files. Maybe i'm getting too old to constant exercise my memory or to tinker configuration files. Nowadays i just use VSCode and occasionally nvim.

You can use M-x customize to pick configuration options from a menu.

What modern feature is Emacs missing?

I feel the comment was bait.

Exactly. I have been using git for my .emacs files and there is little I really miss from Emacs for editing files and even quite a lot of coding.

- fast loading (vscode loads much faster on my computer; specially if I have a lot of open files)

- code "peek" (that little windows is super useful)

- good integration with debugger (again, vscode kills it here). For example: how to look a at a numpy array in emacs (in vscode there's a data viewer for that)

- robust LSP (for example, when I complete a formatting string f"{... on a big file, emacs simply becomes unresponsive for a minute or so (it's much quicker ona powerful computer though); pylance is simply superior on edge cases.

But although I'm a long time emacs user, there's one thngs where VSCode is much better, it's discoverability. I've learned much of what I need in 2-3 weeks, without ever looking at a manual.

Note: I'm a regular emacs user since since about 10 years (I came for the freedom, stayed for the community). I'm using VSCode since about a year.

I'll be happy to ear a way to make my emacs better.

Doom Emacs loads very fast so theoretically it's possible to configure Emacs to be fast too (mine starts in a second, cold start is a little slower).

But I think most people don't care about it enough because they either never close Emacs and/or use it in server-mode where emacsclient is pretty much instantaneous. Can I ask why you don't like doing that?

Because I conserve energy: I turn my PC off at the end of each session (so about one/two times a day). And because the "sleep" mode is not reliable (I have a 14 years old PC, upgraded in RAM and GPU and SDD; and here I conserve hardware).

So having things take time on start up is an annoyance to me (but I live with it, I was just saying that emacs is slower than VSCode)

So your point is that emacs is slow on slow hardware?

I’m sure vscode would chew through resources during a heavy session, have you benchmarked more than just the startup of the application?

my overall feeling on my own (slow) PC is that VSCode is faster on load (or, to be exact, I perceive it be to be faster) and provides a few features that I don't have on emacs.

You're right: once VSCode is in memory I think it uses more of it. But that's barely nothing when compared to rust-analyzer (which emacs LSP uses too).

I use Doom Emacs with the Yamamoto port of Emacs [1] on MacOS (M1) and the startup time is quite slow: it takes around 6-7 sec. for the editor window to show up. It doesn’t bother me too much since I usually start it once a day and just never close it, as you mentioned.

However, I also have many plugins installed, so it might be just that. I wonder if it is possible to install a separate instance of Emacs, then I would be able to test the performance without all the plugins and configuration.

[1]: https://github.com/railwaycat/homebrew-emacsmacport

> - fast loading (vscode loads much faster on my computer; specially if I have a lot of open files)

who ever does such a thing? Emacs starts up on my machine soon after I login. It remains open until I logout. Current instance has 123 buffers (files). Loading speed just isn't important to me as a full-time native (C++) developer.

> - robust LSP

I tried LSP a bit. Gave up because it just didn't really help me with my actual work. Could understand why someone with less experience programming would find it helpful, but it just wasn't so for me (I use emacs dynamic completion a lot)

Emacs on my system is ~8sec load time, vs ~5sec load time for Code. I have not optimized either (but I have decided on using Straight as package manager on Emacs, which is arguably faster than the built-in).

I use LSP a lot (through eglot with Emacs-29). For each "mode" in Emacs there are alternatives to LSP, mostly what was there before LSP, which may be equally good. However, I found that switching to LSP simplified my setup, and having the same functionality/keybindings between modes is great, e.g. my projects switch me between Python, Rust, and Java, earlier that was basically three different "IDEs", while today they're very similar.

> Emacs on my system is ~8sec load time, vs ~5sec load time for Code

yeah, but i don't give a damn. I do this once every few weeks.

ps. also, emacs is < 3 secs on my system, so even if i did care ...

Run emacs as a server when you start the machine and use emacsclient to connect with it. Way faster start times.

What is "dynamic completion" ?

I have it bound to Ctrl-\ ... Emacs scans backwards through the current buffer, then all other buffers, to look for completions for the word at the cursor. Press it again (after one completion) and it will cycle through other possible completions (and keep doing this as long as you keep pressing that).

It's great for completing variable names, but also if you writing just regular text, finishing longer words and so on.

That sounds like

    M-x dabbrev-expand

which is bound to M-/ by default (and yeah, I love it). Though I do like the context sensitive completions that lsp provides as well. They are particularly good for showing you structure members (since the language server knows the types).

> Could understand why someone with less experience programming would find [LSP] helpful

Have you considered the possibility that people with more experience programming than you might find it useful?

Yes.

Then that covers everyone.

Parent does have quite a bit of experience:

https://en.wikipedia.org/wiki/Paul_Davis_(programmer)

I'm so used to empty boasts and humblebrags from tyros on HN that I overlooked the real McCoy. That's on me.

I hope to one day be cool enough to write my own Wikipedia entry

So renaming all the symbols in your whole project with just one command is not for you ? Navigating to declaration/searching all the usages of a symbol etc. All that isn't for you ? And these are the two most basic features You make it sound like LSP is a small gimmick that appeals to less experienced developer while it's actually a huge productivity boost that has literally no link to being experienced or not.

I also think that parent's comment is overly dismissive of LSP. But for me, Emacs with lsp-mode does the things that you describe.

I mean, I wanted to love LSP. Everything I read about it suggested that I would. But I tried it out for two weeks, working (as normal) on my 600k LOC C++ project, and found it somewhere between irritating and not-actually-helpful.

I appreciate that people who started programming with such tools probably come to rely on it the way I rely on dynamic completion in emacs (which is a lot).

Considering C++ is almost impossible to write reliably good tools for it's entirely possible that LS for C++ is simply not very good and that with languages that can reliably provide a good LS experience you'd view this differently. I don't think it has anything to do with programming experience level. I've programmed for 24 years and I find language servers great when I can have them. 20 or so years on top of this is unlikely to change anything.

For what it's worth I'd use CLion for C++, most likely, if I ever wanted to go back to C++ outside of tiny sandbox projects.

P.S. Language servers are great for smaller ecosystems where no one can really afford to make or fund much beefier tools like IDEs, so a language server can be created by a community member and be used with pretty much all relevant editors almost instantly, meaning the ROI for the community is massive.

Emacs has code peek.

With lsp-mode it has that little window: https://emacs-lsp.github.io/lsp-ui/#lsp-ui-peek

Personally I use eglot with consult which temporarily switches the entire buffer to do the "peek" functionality rather than popping up a tiny window: https://github.com/minad/consult

I wonder why everyone's having such long startup time for emacs - like 6 to 8 seconds. Mine has a lot of add-on packages and it still manages to start up in 2 seconds (It's a server. So that happens only once in a session). I haven't done much optimization either - unless you count a lot of autoloads that you automatically get with use-package.

> maintenance of the .emacs files

What maintenance? I have not changed a single line of my .emacs file for 3 years.

I have to admit, I added a couple of lines since 1995. About 10 or so

I changed from .emacs to .emacs.d/init.el when it became possible, because that seems neater. Some years later I decided to see what fancy packages the young folks like, and started using vertico, orderless, marginalia, embark, and consult. I'm still going to reserve judgment on embark and consult, but at least the first three packages are certainly great additions.

if your .emacs has 10 LOC it makes it definitely easy. My .emacs is ±360 LOC.

My point is: the api of of emacs is fairly stable. And your point is?

I have ~80 lines outside the customize variable block added by emacs. Nothing too fancy but there are a few hot keys and functions that I can't live without.

In the same boat. Still like it a lot, but I started using VS Code for serious coding. But unpopular opinion here. So expect to get downvoted a lot.

Edit:

The unpopular opinion is to say that one has stopped tinkering with Emacs for hours and started using a tool like VS Code or intelliJ to do actual coding work.

VS Code is extremely popular here do I have no idea what you are talking about.

Relax, we‘re talking about an editor, not someone‘s religion.

Blasphemy! Repent and join the Church of Emacs!

Is what I should say to you since you were involved in the editor war while I was not. I have not even said anything on this topic other than that there are tons of VS Code users here so the "unpopular opinion" makes zero sense and just feels like you were being rude to Emacs users (of which I am not one). I downvoted you because you were doing editor warring.

IntelliJ is lightyears ahead of VS Code or any other LSP using editor including Emacs for what it’s good at, namely working with Java in complex ways.

I will use IntelliJ or Eclipse over Emacs or VS Code for Java development any day. But having used both VS Code and Doom Emacs for other development, the latter is quicker, more featureful, and more discoverable, just as easy to configure, and more extensible.

I think "tinkering for hours" is overstated. My vim/neovim and emacs setup usually take no less than 30 minutes (including installing favourite plugins/packages). Then I can use them to get my work done.

Well, I'm not that obsessed with tweaking every bits, though. When I'm using vim/emacs, I never intend to configure them into IntelliJ replacement.

The only people tinkering for hours are either having fun making customizations, or are debugging something gnarly. If you just leave your config alone, you have to do approximately zero maintenance. Maybe a version upgrade breaks a package. Maybe. Otherwise, I'm tired of this canard. Emacs doesn't make you do anything to your configuration you don't choose to do yourself.

Modern features:

1. lsp-mode/eglot

2. package management

3. treesitter grammars

4. Portability - win/linux/mac/unix/android

5. Graphical User Interface - you can browse the web and watch YouTube in Emacs. Customize has buttons, forms, menus.

6. Treemacs/Treeview/speedbar: you know the multipanel view in Intellij or the project explorer in Intellij/vscod? Yeah, that.

7. Actual macros and function definitions, without needing to post them as an extension.

8. Interactive repl.

9. 5 different terminal emulators built-in.

10. Automated fuzzy everything with helm-M-x and helm. Exactly like Command-p in vscode.

11. github, gitlab integration with magit.

12. Copilot, tabnine, and chatGPT integration.

13. Hundreds of themes.

14. We've had shareable, secure remote collaboration for over a decade with wemux.

15. Use any ttf.

16. Mouse editing and command binding.

17. Use every build tool with projectile-compile-project.

18. Refactoring with lsp.

19. Autocompletion and jump to source.

20. Session save and restoration with desktop-save.

21. Slack integration.

22. Debugger with dap-mode.

23. Individual test only runs with dap and avy-lens.

24. blame with.magit-blame.

25. Pixel scrolling.

25. Transparency with seethru.

28. Rest client with variables and session storage (like postman, but free).

29. Browse compressed files as if they are normal directories and save to them.

30. Containerized deployment via flatpak.

31. Docker, docker-compose integration, kubernetes, aws, datadog, Azure integrations...

All of this fits in around 500 lones of copy_paste/cloneable emacs configuration, most of which is use-package declarations. Nary a defun or global-bind-key in sight, and because emacs is a full elisp ide, and it is actually executable code, it's debuggable on launch, unlike myriads of json files.

I'm trying to think of anything else that can possibly be interpreted as 'modern' from a ux standpoint. I certainly can't think of a feature that Intellij has that emacs doesn't that is core to the ide experience. And most of my emacs tools are better than the vscode version of them, at least in terms of invasion into the editor buffer or integration with the editor ux.

The one thing that's not modern is the standard copy and paste commands, but that's super easy to customize. I guess you can't drag and drop buffer frame borders in multiple buffer layouts if you hide scrollbars, and the message buffer isn't resizable...

But vscode has basically all of it out of the box. Maybe after installing one or two extensions, which it recommends for you and you can install via a GUI.

As someone who uses emacs most often: VSCode is shaped a lot more closely to a modern aesthetic by default. If you've been following along with emacs all this time and keep up to date with the latest changes, you can easily accrete the configuration to make your emacs look like a modern tool, but it doesn't start configured that way.

> But vscode has basically all of it out of the box.

Are you sure ?

I think you might want to contemplate that "Fashionable" is semantically equivalent to 'dated'. You are excited that it's dated to 'now'.

I know you see this fashionable UX as an advantage, but what I think about is how you're going to have fashionable evolution in UX thinking inflicted on you. It feels to me like someone coming into my shop and moving all my tools.

Gratuitous example from an adjacent area of nerdliness: Were you around when Microsoft decided to drop the UX they'd been using for a few decades and change to "The Ribbon" ?

> You are excited that it's dated to 'now'.

Yes, I am. That's very convenient for me.

> Were you around when Microsoft decided to drop the UX they'd been using for a few decades and change to "The Ribbon" ?

I was, and you're right. Microsoft functionally owns the chrome for vscode and it isn't as configurable as far as I can tell as emacs at that layer. There's certainly a possibility they will make a decision later to mess everything up.

But for now, my previous observation stands. I have to do less configuration out of the box to get vscode into a daily use work configuration than a naked emacs install.

I highlight this because it's not an unsolvable problem for emacs. It requires making a recommended default configuration that will be more correct for the 95% use case and advocating that configuration on the install channels for the tool.

> I highlight this because it's not an unsolvable problem for emacs. It requires making a recommended default configuration that will be more correct for the 95% use case and advocating that configuration on the install channels for the tool.

For people interested in this, I know about Doom Emacs [1] and Spacemacs [2].

[1] https://github.com/doomemacs/doomemacs [2] https://github.com/syl20bnr/spacemacs

Why downvote this guy for essentially just pointing out that Emacs isn't terribly useful out of the box if you want to develop software? This is objectively true, isn't it?

It is like assembling IKEA furniture if IKEA furniture didn't come with a usable manual and there are nine different descriptions online of how to assemble your new chair. Of which 5 don't actually produce a chair and two that are strangely incompatible with how you prefer to situate your couch.

Rather than be angry with people for pointing out something that is very likely to be true, how about listening to _valid_ user criticisms? And perchance see if something can be learned from it?

This is valid feedback.

> Why downvote this guy for essentially just pointing out that Emacs isn't terribly useful out of the box if you want to develop software? This is objectively true, isn't it?

I don't think that's true.

Do you include installing emacs packages as out of the box as you would vscode plugins though?

Well, it is or it isn't.

Here's what you can try: do a clean install of both, then document the steps you had to take to get VS Code + Go plugin to work vs getting Emacs to within a reasonable fraction of what VS Code will provide. Post your Emacs config when you are done. (As well as links to the sources where you found working configurations).

PS: good luck nailing the language server stuff on the first try on Emacs.

Quite easy - install doom emacs, comment out the ;;(go +lsp) in init.el and run doom sync. You are done and can do go development now with 1 line of config.

vscode recommends plugins to install as it encounters file types they would be appropriate for. It's not strictly out of the box, but it's fairly close to out of the box... Out of the box, vscode comes configured to guide the developer to enhance it as needed.

vscode has a lot for itself, but i see my colleagues use it, it's still too mainstream and enterprisey. the git interface adds more confusion and reduces speed..

No disagreement. I find myself just using terminal instead of the vscode git interface almost all the time.

I don't understand why this was downvoted.

Vscode out-the-box is much more complete for coding than Emacs out-the-box.

While my Emacs-foo is not that great, I have relied on it for a lot over 25 years of programming. Recently, though, I gave Vscode a try, and while it's buggy as hell when you load up on the extensions you need, it's not that bad!

Slow? Yes, compared to a Vim or Emacs similarly set up. A wee bit bloated? Certainly, compared to my Vim and Emacs configuration.

But, really, it's the one I recommend to new developers. Not Vim, nor Emacs, even though I use those myself.

postmodern features: [e]lisp metalevel customization

I am a long-time Emacs user and used to maintain my own config, but I switched to Doom Emacs [1] a year ago. Doom Emacs is like a pre-packaged/pre-configured emacs distro. You still need to configure the features that you want to use, but it's a lot easier (and faster) than having to do everything from scratch, and definitely if you already have some emacs background anyway. For me, it makes the newer, more advanced, features more accessible. Since switching, I started to use Emacs more again.

[1] https://github.com/doomemacs/doomemacs

i tried Doom Emacs and the first thing that turned me down was the VI bindings, which i disabled right after install. But yeah it does the whole configuration nightmare more easy to maintain.

Is the configuration still "paste this mystery lisp code somewhere in a config / ini file in x,y,z place" or is it finally plug-and-play like in VSC?

M-x customize exists since forever, and is more plug-and-play than VSCode ever was.

The real problem with Emacs is the shitload of bugs that case weird, undocumented and annoying behavior. A scripting language like elips is not meant for programming something as large and complex as Emacs.

I dislike customize though whereas I like the GUI interface to settings in vscode.

I agree Emacs has too many bugs (but I haven't found anything that suits me better for maintaining notes and to-do lists and such).

I've found very few in many years' use. You may be a more competent user than I. Please report bugs, the devs are very responsive.

> The real problem with Emacs is the shitload of bugs that case weird, undocumented and annoying behavior.

Could you name a few of these "bugs"? I use Emacs for practically everything and bugs are very difficult to encounter, even on Emacs HEAD.

> A scripting language like elips is not meant for programming something as large and complex as Emacs.

Well, that's just plain wrong. A lot of vanilla Emacs functionality is written in Elisp.

Core Emacs is simple enough to mostly be bug-free.

But any elisp package will have lots of annoying small day-to-day bugs and glitches.

> But any elisp package will have lots of annoying small day-to-day bugs and glitches.

I disagree. That's a broad and false generalization. Most packages are bug-free. If you're submitting to MELPA you need to make sure your package works and follows some guidelines for namespaces and organization, which can all the checked within emacs itself. Every package on a package tracker is vetted by at least one external dev.

Emacs functions usually require little to no modification for years, because the core is very stable.

My experience is the opposite: I can keep my init.el in version control, and it contains Lisp code that I can run and debug by hand if needed. If some mode doesn't work right, I can step through its code and examine its variables. If I want to know what a key combination does, I can ask Emacs and it will tell me something like "M-s l runs the command consult-line (found in global-map), which is an interactive native-compiled Lisp function in ‘consult.el’." So I know that the combination is defined in global-map, and the function is defined in consult.el, and I can easily find the code.

In VS Code it's certainly easy to install an extension. Some mystery thing happens, and there are new commands available and some programming language support might be enhanced, but it is all very opaque. If I wanted to debug the code, I have no clue where to start. I'm sure it's there somewhere but all this looks to me much less discoverable than in Emacs.

You will not have this issue if you bother learning emacs lisp first. C-h is your friend.

As a multi-decade Emacs user, this sentiment was never correct, and needs to die. You can do insanely powerful stuff in Emacs without learning elisp. I myself was a power user for 9 years before I learned elisp. While it definitely gets you to the "next level", learning it was not a revolutionary improvement.

Learning elisp is indeed absolutely not required. But it is hard to use emacs for many years without learning a bit if elisp by osmosis.

The amount I knew was trivial: How to set a variable, and perhaps one or two other things. I didn't know how to do conditionals and for loops.

For my config, beyond setting variables I mostly copy/pasted. It gets you very far.

In the menu bar, click “Options” → “Manage Emacs Packages”. Install whatever packages you like. You can even configure third-party package repositories.

GNU Emacs is now dependent on TreeSitter which is a MIT-licensed project and LSP which is a Microsoft project. Also built-in support for non-gnu packages to install. Soon it will be a non-gnu project entirely. I think it's a bit sad that the ideological basis is beginning to be abandoned but I think there is not enough believers in the ideology anymore.

I would say most modern editors (Helix, Neovim) do TreeSitter and LSP better than Emacs today and probably for many years to come

MIT code could be used in GPL, but other way round is not possible. As long as there is a line of code with GPL license, entire project will be GPL.

Not really, only when it can be shown that the project is derivative of the GPL code (for example, hard dependence on GNU-only library for some of its features vs. "one of the multiple possible implementations we can use is GPLed")

X-windowing system is also MIT-licensed, were they every avoiding that license?

> GNU Emacs is now dependent on TreeSitter which is a MIT-licensed project and LSP which is a Microsoft project

Not really dependent (you can build and use Emacs without either).

> I think there is not enough believers in the ideology anymore

I don't know what ideology you're talking about, but the only one I've ever had is the Emacs ideology: use the best program ever made and be happy.

Tell me you know nothing about licensing without telling me you know nothing about licensing...

Seems you have prior form in not knowing what you're talking about https://news.ycombinator.com/item?id=32632468

Eh, I've been looking and haven't found anything for other editors that actually tries to use TreeSitter for anything beyond highlighting. The Emacs structural editing packages are still very WIP but at least they exist.

(And also some have been based on the out of tree implementation that's been around for a while now)

Example: https://github.com/mickeynp/combobulate

There are quite a few packages for neovim that use treesitter for structural editing, folding, jumping and viewing.

Well, they really need to up their SEO, because I found one

>LSP which is a Microsoft project

Emacs' LSP client Eglot and many of the LSP servers have nothing to do with Microsoft. Honestly, LSP is one project that I'm thankful to MS for. Personally, I value open standards like LSP more than any single FOSS project.

LSP I can probably understand, mostly for performance reasons. Native json parsing and native compilation goes a long way, but clients written in elisp seems susceptible to edge cases where it's not performant enough because UI and IO runs in same thread in Emacs. Not insurmountable even without multithreading, some newer clients that uses better IPC or the dynamic module system are not constrained by Elisp requirement and seems to be doing fine in terms of performance.

The dynamic module system is generally a win for pragmatism over ideology, and it has been around for 7 years already. You can't do everything, like say extending core graphics of Emacs, but you can do a lot in any language of your choice if you feel constrained by Elisp. Tree-Sitter feature is built on top of that so it's not clear to me why do you think Emacs can't do better than say neovim. I use neovim and tree-sitter daily and generally don't think tree-sitter itself is rock solid yet, I run into indentation and slow query issues semi-routinely. But I am much more impressed with the work happening on Emacs community that leverages tree-sitter for advanced tooling [1].

[1] https://github.com/mickeynp/combobulate

Why is it a problem that LSP was originally invented by Microsoft? It's an open protocol with many free-software implementations. You don't have to use any Microsoft code if you don't want to.

Besides, even if that wasn't the case, Emacs has long had a policy of interoperating with non-free software. It runs on versions of Windows from 98 to 11. That's not because its developers don't value free software, but because they realize that this is a more effective way of convincing people to use free software than insisting on absolute purity.

Reply on news.ycombinator.com