Is Emacs 29 stable enough for daily use?

Hello, I just spent almost 2 hours building Emacs 28.0.91 with native-comp only to realise the pgtk stuff is on 29 :| I also see Doom isn't yet supported on 29

I've been using it daily since it was released without problems

That Doom doesn’t support version 29 is news to me, I’ve been running Doom/Emacs 29 with pgtk on WSL2/Ubuntu for at least a month without any problems. I hope it’s similarly stable for you, if you give it a try.

I've used always the latest version in master during years and i had problems like twice with some native-comp bugs. So yeah.

Emacs 29 is the current development version and therefore unstable, so the answer to your question depends on which bugs are present at the time you built it, because it's a moving target. If you're building from master then expect bugs, and be sure to report any that you encounter.

It hasn't been released

I have been living on a master branch since it was called 27.0.50 or something. I find master more than stable for everyday use. I prefer it to what is going to be 28 when it comes out due to speed and some other improvements not found in 28.

I think Emacs as a software reached stable state since years. Master branch is relatively stable for daily use. Since a few years of using master I haven't have a single bug that affects me. I think due to project maturity and development practices, Emacs master is more stable that what many projects call release branch. The community is so obsessed with stability, that thinks get merged to master only after some validation steps are through. Emacs master == debian unstable, as far as stability is concerned.

I use 29.0.5 from git since quite some times, I think I've hit one build fail and one elisp-level issue. I still use it.

I've been on the master branch for months now, without any issues. If there were some, they were quickly fixed.

I've been using 29.0.50 (with native-comp and pgtk[0]) both on macOS and Linux for a long time and it's all smooth, no problems. I'm also using it with Doom Emacs. [0] on Linux only of course.

Correct, but as others in this thread are saying, it's remarkably stable. I've been using 29.0.50 since shortly after it was merged with master. The only issue I've had in all that time was compiling it with pgtk support. I submitted a bug and just switched to using the regular GTK3 build option instead. I only re-compile once every 2-4 weeks so I might just be lucky, but it's been incredibly stable.

It works but it's not supported, as in, the dev team won't move mountains for a 29 only bug for now. It shows up as an "error" every time you run doom doctor.

Just as a counterpoint, I've been through a few builds and had them disappear at random, most recently when I wasn't even interacting with it, presumably for a SEGV. I'm afraid I didn't report it <hangs head>. Howerver, a very broadly useful approach, beyond Emacs, is to try to avoid having your workflows depend on accumulated state. If I have to restart my Emacs and continue it really doesn't change anything apart from the couple of seconds startup and a few seconds to load all the modes and lsp when I revisit a project. Make opening Emacs and getting to work as frictionless as possible.

I also use emacs master, and I agree with the stability comment. I have hit the odd broken build on master (one as recent as last week), but those are extremely rare, and they are usually fixed very quickly.

Published, then. Or made available

Doom is not supported on 29? I'm running Emacs 29 + Doom fine here.

I build from master every weekend. I sometimes run into issues with external packages but they're often fixed within a day. Thanks, maintainers.

You're doing git wrong. Git checkout emacs-27 and build there. Let master be master.

I think it was like 2 occasions in the last two or three years I have encountered when master was broken, and I think both were related to native comp and resolved within days or so. I don't remember exactly anymore. There was also that memory leak situation early last year, but that also affected different versions, so it wasn't just the master if I remember well.

If you’re comfortable building regularly and having small changes appear underneath you, you can “live from” git head without too much trouble. Develop the habit (or build script) to copy a stable build to a safe place every some often, for those rare times when you need it.

It's technically not supported but there's nothing stopping you from using it on 29

You are misunderstanding what I wrote. I was maybe a bit too fast when I typed the above comment, so I am sorry if I was unclear. To make it clear: I don't build Emacs 27. I have been building Emacs from the master branch and using it on the daily basis as my main Emacs build, since the time Emacs was in version 26, and they bumped the version in master to 27.0.50. I hope it makes it more clear what I meant :). Cheers.

No, I know what you meant. That you can't `git pull` into master without breaking your install branch is only a problem for people who use git correctly.

I think I need some help understanding how version numbers work in Emacs. Does 29.0.50 represent a specific state of code, or do changes continue to be pushed to the 29.0.50 label? Why are you recompiling the same version number every few weeks?

What distro are you on? Likely there is an emacs-28 with pgtk available (like on Arch, Guix, I'm sure others), probably pre-built if you prefer too.

I have been using the master branch for over 6 months. The only bug I encountered was clangd with eglot in the last month. But thanks for the hard work of the authors, the bug was resolved within 2 weeks.

I'm using the [Arch User Repository script](https://aur.archlinux.org/packages/emacs-git) of emacs based on the master branch. When they change the script they bump their number, so I'll usually recompile then. I think the current version starts off at .1 - so emacs 27.1 was the initial release for emacs 27 and we're currently at 27.2. Next version 28 gets its own branch - I think the working number is always a 0.50 so the emacs 28 branch is version 28.0.50. There was an announcement that there will be no more new features for 28 so it will continue with testing. Once its ready it will be released as 28.1. The main new feature - native compilation - wasn't ready to be added to 28, so it lived on the emacs 29 branch. I think when the 28 branch features get frozen, the 29 branch got merged into master as version 29.0.50.

As others have said, 29.x / `master` branch is relatively stable. Personally I’ve been using nightly builds from master as my daily driver since around January 2020 to get the native json parser that eventually shipped in 27. I primarily use macOS, where builds are typically self-contained .app bundles, so in the rare case of a change/bug causing issues, it’s easy to just switch back to the previous build that was working. And on Linux I do a similar thing, by setting PREFIX to a unique path that includes date/commit and then symlink things a bit (I’m working on a tool to automate this btw :P). As for the stability of master, in the past two years, I’d say it’s been very stable. I’ve personally ended up reverting to older nightly builds only about a handful of times, and only twice due to bugs in Emacs itself. The rest were package incompatibilities with latest changes in Emacs. And for the bugs, they were minor and definitely not something everyone would run into. I’ve been updating the latest nightly build on macOS roughly once every other day to once a week. And I’ve actually been maintaining a [list of commits](https://github.com/jimeh/build-emacs-for-macos/issues/6) where I’ve personally had no issues. The update frequency is somewhat sporadic though as it’s based on when I feel confident about it, which sometimes doesn’t happen due to bugs with my personal config, or simply because I kept updating daily for a while and haven’t used any specific build for very long.

Let me clarify again: I don't build in master branch. Never did. I said I am using master branch to build Emacs. That is what mattered for this discussion, in regard to the OPs question, not that I am building Emacs in master branch per se. I thought how I go practically about it is not important. But since you have brought it up, here is what I do. A long time ago I used to create a branch for my personal build, build Emacs, and install it. Then I have stopped installing Emacs, and have been just using it directly from the source, still building in a custom branch. And I always created new custom branch for the build so the old one is available if the new one fails. Nowdays, instead of creating a custom branch, I create a worktree and build Emacs in my private worktree. That way I don't need to switch branches since worktrees let us checkout different branches at the same time. With worktrees I can have different Emacs versions built from the same master if I wish. I have my systemd pointed to a link in my ~/.config directory, which I switch to the latest custom build when I know the build is working. Anyway, thanks for your tips, and yes I agree with you, building in master branch wouldn't be a very good idea, and git will probably scream next time you do a pull.

I run emacs with some custom patches so I got used to building the master branch version and just kept using it. I spend most of my work day inside emacs haven't experienced any error that was caused by using the "unstable" version. In this process, I also migrated from a personal emacs config to doom emacs, and everything worked as expected (so far, at least).

Thanks, that helps. For anyone else curious, here's a quick summary of how things seem to work: * `X.Y.50` = current Emacs trunk (eg, `28.0.50`) * `X.Y.9X` = release candidates (eg, `28.0.90`) * `X.Y+1` = an officially demarcated version (eg, `28.1`)

I recently built from trunk on Ubuntu 21.10 (therefore Wayland) with native compilation and pgtk and I had 0 problems, really. It is very stable and any build or elisp bug introduced in a commit is usually solved within a few hours. I think that a quick check before pulling just to see the latest commits and their messages is enough, really. As for the Doom support, it just means that, if you end up finding a bug caused specifically by a change made on trunk, the Doom devs probably won't run to fix it on Doom and will likely ask you to file a bug on the Emacs bug tracker, should that be necessary.

I tried it for a day or two. Had to go back to version 28 because visual line mode kept bugging out -- I couldn't navigate to all lines within the visual line. Otherwise I didn't notice any major issues with it.

When master was 27.0.50 there was no emacs-27 branch, only emacs-26. You should probably learn how versioning works in emacs.

An astute observation indeed since after all `git checkout -b emacs-27 master` wasn't available until 2006 or so.

I used the last version today with doom + a react project (JavaScript) I m not a power user but I didn't see bugs

> git checkout -b emacs-27 master Please don't do this. `emacs-27` is a branch on the remote, and a local branch with that name should be tracking it. This is bad git advice.

is it possible to build emacs on macos?

Of course, the basics is not very different from building it on Linux. To make the Emacs.app bundle fully self-contained however gets a bit more complicated as it involves embedding shared libraries and re-linking any binary files that refer to them. There’s a few different projects around that make the whole process simple, and a few that provide pre-built binaries of various flavors too.

You can hit unstable builds when new major technology is introduced: things were pretty rocky after the Cairo rendering was merged, and I remember some rough spots right after the native comp branch was merged. Other than those two times, it's really stable. I haven't used a packaged / official release in years.

[removed]

Sadly it is impossible, and that is why no macos versions of Emacs exist.

Largely accurate, but: * 28.0.50 progresses to 28.0.90 etc in the pretest stage, and from there to release candidates, before finally being released as 28.1 * Native compilation *is* part of Emacs 28 (if you build `--with-native-compilation`). You might be thinking of the pgtk branch which was bumped to Emacs 29. * There is no Emacs 29 branch to be merged into master: Emacs 29 *is* the master branch. At some point in the future, when the features for Emacs 29 have been frozen, an `emacs-29` branch will be cut (for ongoing bug fixes), at which point master will become Emacs 30.

I'm on Void, so I have to build it manually. I'd prefer prebuilt tbh, it takes so long to compile

> When master was 27.0.50 there was no emacs-27 branch, only emacs-26. Exactly :). So I have been building and using the master branch since Emacs was in version 26, at which point the version in master was bumped up to 27.0.50. I even wrote that in a comment above to fragglestick before you posted your commen. What part of my post was unclear on that front? And seriously, why would such detail even be that important for this discussion? I just wanted to give approximate information about how long I have been using the master branch as my daily driver.

Same here. Been using the latest Emacs crack that master can supply and I am yet to run into any problems.

Using Emacs 21 + Doom as my daily driver on MacOS. Not one issue (related to the Emacs version, that is).

What is the Cairo rendering? Is there a 2d canvas access in Emacs, or something like that?

IIRC, even when GTK is being used as the window toolkit, emacs manages most of its own rendering. The only thing it doesn't draw itself are the things outside of the main frame like the context menus and the menu bar. Everything else is done using Cairo and Pango. I don't think any of it is readily available from elisp, and it is all done in the ball of spaghetti that is the rendering backends.

Just curious, what `./configure` arguments are people running generally with master branch? Obviously everyones use cases slightly different, but curious what people are running.

I just ./configure --with-native-compilation Native compilation is the only reason I use master branch.

There is technically nothing preventing it (and it did work fine earlier), so as both doom and emacs are seeing heavy work now (Sept 2022), there are tons of issues with the combination of the two. Presently it's better to stick to 28.2

This is a joke, right? I've been using GNU Emacs on macOS for a long while...