Emacs 28.1's been cut

[removed]

Is there some place to look at the new features/improvements/advantages between 27.2 and 28.1?

Some of it will probably appear [here](https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases) eventually. With an assortment of changes listed there and then the rest when you click on the version number.

It's extremely detailed, but you can checkout the associated [NEWS file](https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?id=de7901abbc21114721057c907cc52455e228f826)

Inside Emacs `C-h n` takes you to NEWS, describing changes incorporated in the current version. So if you're running 28 you'll see those. Pass a numeric prefix to see the corresponding files for previous versions.

I will do a what's new post as always. Give it a day or so.

thanks so much! <3

Yay, no more compiling Emacs from source... Oh wait, I want pixel-wise scrolling.

300+ changes in this https://dpaste.com/4A6L6YSD5 impressive

Does this mean that the next stable Emacs 28.1 will be released soon? Or does the version bump signify something else?

Ctrl-F "* New" and there's over 300 hits, Emacs 27 was only a few years ago. At this rate I'll still be discovering handy new-to-me commands in Emacs until the day I die.

It has been released, note the 28.1 tarball on this page: https://git.savannah.gnu.org/cgit/emacs.git

oh nicee, time to update.

Yay, more compiling emacs from source! /hj

Is there a way to see what build parameters are used in the pre-compiled version? For example, will native compilation be supported if I install Emacs from my system's package manager? Also, building Emacs manually is the only way to be able to jump to the C source code right? Otherwise, since the C codes are pre-compiled, they will be in binary form and we cannot see the actual source code AFAIK.

Well considering emacs is like 250% elisp and this release introduces native compilation of elisp, wouldn't we all essentially be compiling emacs from source regardless of whether or not you're using official binaries/packages?

> Is there a way to see what build parameters are used in the pre-compiled version? Yes: `C-h v system-configuration-options` > For example, will native compilation be supported if I install Emacs from my system's package manager? It's impossible to answer that, obviously. *Ideally* your OS will have packages both with and without native compilation, so that users can choose; but it's all up to the maintainers of the packages in question. > Also, building Emacs manually is the only way to be able to jump to the C source code right? No, not at all. The location of the source code merely needs to be known. You can download the source and set `C-h v source-directory` accordingly. By default Emacs will look for C code under the `src` sub-directory of that value, but it may prompt you if it can't find it.

For macOS, if you want a pre-built Emacs.app bundle with native-compilation enabled, my [emacs-builds](https://github.com/jimeh/emacs-builds) project has a release available now: https://github.com/jimeh/emacs-builds/releases/tag/Emacs-28.1 A Homebrew tap is also available with Casks in the readme.

Oops it is not yet updated here: https://ftp.gnu.org/gnu/emacs/

How come 28.1 is cut when 28 itself is not yet on the GNU server? https://ftp.gnu.org/gnu/emacs/ .1 should be the first bugfix release, but there is no stable 28 tar there either.

Compiling libgcc-jit for the native comp feature is particularly long for me. Emacs itself isn't that long to compile. And IIUC there are still critical differences in the C code between versions.

Had a little "WTF? Why's it been cut? What's wrong?" before realising that "cut" as in "cut a deal", not the *n*-other meanings that semantically resolve around deletion or omission of some kind. English is so beautifully messed up!

Whats needed in the config to make it work? Does it work with M1?

As far as I know it should work out of the box. Installed packages should be compiled in the background first time they’re launched. I don’t recall the exact name of the top of my head, but look for a buffer called something like `*Async-Native-Compilation-Log*`. As for M1 support, I’m still waiting for GitHub to add M1-based GitHub Actions runners ([issue](https://github.com/actions/virtual-environments/issues/2187)). However, I’ve had multiple people report that the x86_64 builds I can offer right now do work on M1 machines via Rosetta2. Though that’s obviously not ideal. My [build script](https://github.com/jimeh/build-emacs-for-macos) does work on M1 machines, but unlike on Intel machines, the app can’t be launched until it’s been signed. Which requires a Apple Developer program membership.

Emacs has a different way of naming releases. The release candidates are the 28.0.N versions. When the bug reports slow down, they "cut" a branch to make the first official release, the 28.1.0 which will then increment the last number with each patch.

Hehe. Cutting a release is common jargon in software engineering. Happy cake day, btw.

Sounds great… it seems you have _some_ of the emacs-plus patches, but could you summarize the main differences between your emacs-builds, and say emacs-plus and emacs-mac formulae?

What option do u use when configuring ( ./configure ) for pixel-wise scrolling?

Is there any AUR binary package for emacs 28 and onwards? i am asking this because I don't want to compile due to some reasons.

Sure, my builds are most similar to emacs-plus, and I even borrow some of the patches from it in my build script. Main difference is the app is fully self-contained and works even without homebrew being installed, and of course, they’re pre-built using GitHub Actions. My goal is essentially a batteries included self-contained Emacs.app. The emacs-mac cask is based on a fork of Emacs that adds lots of mac specific things. Personally I’ve had issues around keybindings and stuff with those builds, and never got around to spending the time to try and resolve it. But those issues are most definitely due to my config rather than anything actually wrong with emacs-mac. There’s also the emacsformacosx.com builds, they aim to be as vanilla Emacs as possible, which means no SVG support, and from what I’ve seen of the 28.x/29.X pretest and nightly builds, no native compilation either.

So a better option is to compile it using brew instead of using the provided binaries/dmg images?

For M1 machines, yeah compiling with the emacs-plus formula is probably the best option. I don’t recall seeing anything about needing to sign the app with emacs-plus.

Your binaries started without any problems on M1. But it fails during bootup. *ld: library not found for -lSystem* *libgccjit.so: error: error invoking gcc driver* Installed: `arch -arm64 brew install gcc libgccjit` I have exec-path-from-shell but its not the first thing I run.

Thanks for the details ;) [you might want to add something along those lines in your README]

Gah, that one. It basically fails to find the bundle gcc shared libraries. Did you maybe use any flags that could have prevented `site-start.el` files being executed? The bundled gcc libs are setup in `Emacs.app/Contents/Reaources/lisp/site-start.el`. You can try `(getenv "LIBRARY_PATH")` and see if there’s any paths pointing inside of the Emacs.app bundle itself.

Indeed, been meaning to do it for months >_<

I'll keep compiling from source, only for that edgy sense of novelty every time I do it.

I didn't try it yet actually. Doesn't stop me from wanting :P

Thanks. For those of us not in the know the OP could have use the title "Emacs 28 is released", instead of talking about 28.1 being cut, to make sure everyone understands it.

It's not really released yet, as far as I can tell. The repo has been updated in preparation for the release, if I understand correctly. The release is to follow. So it's in `git.savannah.gnu.org`, but not yet as a tar-ball or precompiled release on `ftp.emacs.org`. I'd expect the source release anytime soon, and binary releases in the next version of your distro, or on the next repo/ppa update. `git pull` does work, though, after a `checkout emacs-28` (which was 28.0.92 before the cut and is now 28.1.50). Edit: there are tarballs available from the git server savannah, just in case you'r rather use those, than clone the whole git-repo.

Nope, only on git so far.

fwiw many distributions have started providing libgcc-jit as a package. Perhaps you could open an issue if your distro doesn't support it already?

My distro is GNU Guix, the last time I checked there wasn't an official package definition. It's not a big deal because installing it from an unofficial channel still takes one command, it just takes more time.

I see, glad it's not too painful to set it up!

I built 28.1 with `--with-native-compilation` and Emacs was noticeable **slower** than 27.2. There was a half second lag between invoking `M-x magit-status` and the status buffer being shown; all the LSP operations I tried timed out; loading a 1000 entry recentf file (with `M-x consult-recent-file`) also had a clear lag. I rebuilt 28.1 without the native compilation option and it's now as snappy as 27.2 was. Has anyone else experienced this?

Don’t we all? 😂

These two files, "etc/NEWS" and "etc/NEWS.27" in the git repo, on branch "emacs-28.1": https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-28.1 https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.27?h=emacs-28.1

The very first time you start Emacs, you have to give it a while for it to pre-compile all your elisp libraries in load-path before they become usable (assuming loading the libraries are not "deferred" at startup, in which case they will be compiled first time they are required). Emacs will continue to use byte-compiled versions until AoT versions become available so it will appear to be functional, but note that the compilation process itself is quite cpu intensive, so the slowdown you noticed could likely be because your entire computer slowed down to perform heavy background task of compiling. As for how long it takes to finish compilation, it depends upon your cpu and number of libraries you have installed. Last I tried, iirc it took me 20+ minutes.

Or just the first one, if you just mean the changes that are new in this latest release.

Very helpful explanations thanks a lot! Especially `source-directory` was something I really wonder. So in conclusion, in order to get what I want, I can install Emacs from my OS package manager, check if `--with-native-compilation` is included in `system-configuration-options`, clone Emacs repo somewhere and set `source-directory` to point that folder.

> The very first time you start Emacs, you have to give it a while for it to pre-compile all your elisp libraries in load-path before they become usable Does it a show a percentage of the compilation process somehere to see how it progresses? Is there a command to see what percentage is left to process?

> note that the compilation process itself is quite cpu intensive, so the slowdown you noticed could likely be because your entire computer slowed down to perform heavy background task of compiling. Optimally, it should be done only when emacs is idle for a longer period of time, so the user is not bothered by cpu intensive compilation. I wonder why it is not done this way.

I have been using emacs-gcc-wayland-devel-bin which is precompiled binaries with native comp + pgtk

Arch is [updated already](https://github.com/archlinux/svntogit-packages/commit/a4c872204b3ac73d1853eb39b6d6fc63f18353b3), but `--with-native-compilation` is not in the build options for the time being :/

Ooooh nice! I've been using your premade .dmg's for awhile now, thanks! Does this one work with vterm by chance? I seem to recall having problems running builds outside of the dmg that integrated with the dmg, so things like vterm were wonky? (But I forget so dont' think about it more than a second, if you see this it all ;)

I don't know of any percentage completion, but at least `*Async-native-compile-log*` shows you what it's up to.

> Cutting a release is common jargon in software engineering. Myself, I prefer the term "minted."

I’m not sure what you mean with outside the dmg that integrate with the dmg. Mind elaborating? :) Though I’ve been using vterm myself for over a year with my builds without issue, both in GUI and CLI.

Heh, all languages have their own beautifully messed up quirks. In Swedish for example the word “gift” (pronounced “jift”) means both “married” and “poison” depending on context. Similarly “ren” means both “clean” and “reindeer” depending on context. This can yield some fun and useless sentences: - “en gift giftorm” == “a married poisonous snake” - “en ren ren” == “a clean reindeer” `</rant>`

tl;dr: More likely I should pull up vterm.el and dig around and see how it locates cmake, so probably not a question for you at all -- OKay just fired up the latest pre-built dmg; works a treat! However, entering M-x vterm leads to the usual 'hey, we need to build vterm's shared lib, shoudl we do that? y/n' -> y -> "can't find CMake". Openning a default shell and 'which cmake', its there (and runnable.) Macports iirc. I imagine the actual .dmg delivery mechanism is irrelevent (too early in the morning still at post above) since the 'install process' here is download the .dmg, mount it, copy the Emacs.app into Applications, and close the dmg .. so the app is entirely in the filesystem; theres various prebuild components (Emacs, probably emacsclient, libraries .. wouldn't know if theres any extra tools etc) packed into the Emacs.app dir bundle. So I guess my question is .. any idea why this build of Emacs wouldn't detect 'cmake'? But I'll have to go through vterm.el and see what the code is doing when its looking for cmake, since obviously its there. I've been doing too many dockers, VMs, AWS lambdas and other containerized things so was thinking about the .dmg as a container, not just a transport. Brainfuzz :)

Ah, right, that makes a lot more sense :)… Yeah I have cmake installed with homebrew myself which obviously seems to work. If cmake is available in your shell, but `(executable-find "cmake")` fails within emacs, have a look at [exec-path-from-shell](https://github.com/purcell/exec-path-from-shell). It can be used to pull in PATH from your shell so emacs finds the same sets of executables, even in GUI mode.

Thinking about this a bit more, I’m now curious to try and bundle both cmake and libvterm into my pre-built Emacs.app bundles. In theory this should negate the need to compile anything at all for vterm, or if you want to anyway, cmake is by default available within Emacs.

Maybe pack libvterm (and not cmake) which is in line for your turn key solution approach?

Yeah, agreed, making cmake available would be a bit of a special thing I think… lol

Selfish question -- any problems in this build that you've noticed? I'm using one of your 28.0 builds, and now this 28.1 If I run the 28.0 build, my .emacs loads okay and all is happy With 28.1 build it seems to work fine, but I noticed LSP isn't starting up; just doing "M-x lsp" for example and I'll see: Wrong number of arguments: #<subr string-match>, 4 I assume a new emacs version will recompile the native and bytecode, but perhaps not. I've not debugged more than that so I'm a lazy sod; jugglign too many problems at work right now and just living without LSP for a bit :)

I only used the 28.1 stable build for a bit, as I’ve been running nightly master builds (29.x) for some time. But I did try a Go project and lsp came up just fine, though now that I think about, I’m pretty sure it had not native-compiled lsp yet. However I’d be very surprised if such a serious bug with native-comp would have made it into the stable release. But if you’re feeling suspicious of native-comp, find your eln cache directory, and trash all `lsp-*.eln` files. That will cause them to be async regenerated next time lsp-mode is loaded. I’d also suggest ensuring you’re using the latest available lsp package, potentially switch to the master branch if you’re using a stable versioned release of lsp. I’ve found that being on bleeding edge of packages is generally the best idea when your Emacs is bleeding edge, or just released like 28.1.

Also, if you previously used one of my builds that did work, you can simply switch back to that Emacs.app for now and you’ll hopefully have lsp working again. The app bundle is self-contained specifically so rolling back to previous nightly builds is easy peasy :)

I'd recommend you download the tarball for the specific release you've installed, rather than cloning the repository. If you do the latter, you would then need to manually reset it to the specific revision for the release you installed, in order for it to actually represent that code you're using.

Yep for sure .. quite handy in exactly this situation :)

Located the \~/.emacs.d/eln-cache dir and blew it away, and fresh run; letting it rip while I go do dishes :) I doubt its a mainline issue, hence my selfish question to you (and thanks very much for entertaining me today!) .. most likely its environmental (somethign in my .emacs, or some turds from numerous builds from source, runs of your version, and other distributions all interplaying in some fashion.) I'm on the latest from melpa and elpa /packages/ (not the 'stable' which turn out to be months out of date.) I usually get a dozen updates available a day, so I update frequently, because its fun and I'm the kind of person who finds that fun :) &#x200B; On going to 28.1 the CPU spins up good and it seems o be doing something, but 'seems' hung so I'll just let it rip .. last round I ended up doing a couple C-g's and restarts and it came up on third try, so maybe I aborted a native comp part way through, or a byte comp part way through, or somethign weird like that, too. Or maybe its legit hung somewhere... always jugglgin too many things at once, never enough time to focus and go debug :/ Will check back in a bit

If it helps, when async native comp has been triggered you’ll have a buffer called `*Async-native-compile-log*` :) If you don’t have such a buffer, none of the packages loaded so far has needed compiling due to eln cache files already being available. As a random aside, [chemacs2](https://github.com/plexus/chemacs2) might also be useful if you’re switching/trying/experimenting a lot, as it lets you have multiple separate configs and easily switch between them.

Came back and Emacs had crashed out, but have to flit off again. I'll swap in 28.0 or whichever previous build I've got kicking around and see if it comes up clean again after nuking the eln-cache, which should be informative. 28.1 seems to actually run okay (barring lsp and thus possibly other packages not noticed yet), which is interesting. Don't think on it at all, I'll get some more evidence and see if 28.x is okay versus 28.1, go through the various logs and etc etc. Worst case is I remove macports and homebrew .. they need a refreshing anyway; is it possible there is some leakage from your build; perhaps I shoudl run ldd (if Mac has ldd? dunno, I'm from BSD/linux/win32 more than Mac background) and see if its linking over to something outside of the Emacs.app

I believe `otool -L` or `otool -l` will give you similar results as `ldd`. Pretty much everything except a couple of system shared libs should be embedded and linked to within the app bundle. Though if you’ve got a previous 28.x nightly build of mine that does work, it would have the same shared libs embedded and relinked the same way. Also if it crashed out, I’d say it’s worth just launching again before trashing anything as it might re-produce the issue much faster :)

I see, thanks.

Thanks! I tried again and indeed after a bunch of compiling, things are running more smoothly.

You can also keep track of what was compiled and when by looking at `~/.emacs.d/eln-cache/<emacs-version>-<hash>/` folder. This is where the architecture dependant ELF objects are stored.

fwiw, the shared libs werent' being leaky .. looks tight as a ship. Got myself all sorted out though... essentially, I just had to recompile (or at least ditch) the old .elc find \~/.emacs.d -name "\*.elc" -exec rm {} \\; -print # ought to do it for folks LSP and everything working a treat after doing that (and killing eln-cache) and restarting If I left .elc from 28.0 and started the 28.1, Emacs would crash out after hanging during first load or two, and LSP and such just wouldnt' work at all. \--> Byutecode does have an emacs-vresion embedded within it I think, so they should have certain thresholds that expire the old bytecode perhaps; or perhaps that exists and they just didn't think 28.1 from 28.0 would have a problem.. Wonder if this is going to be a problem for a lot of people, or just bad luck for me?

Ah, interesting. I don’t actively bytecompile anything myself. I use straight.el, which handles that automatically for packages. I have meant to look into bytecompiling my own config’s files, but it’s been years and I haven’t gotten around to it yet… lol

I am not saying I want you to rush it... but I am spamming www.masteringemacs.com, hoping to see that article. 😅

It's up :)

After som investigation of the compiler buffer I got this error first: ld: library not found for -lgcc\_ext.10.5 LIBRARY\_PATH returns: "/Applications/Emacs.app/Contents/MacOS/lib/gcc/11:/Applications/Emacs.app/Contents/MacOS/lib/lib/gcc/11/gcc/x86\_64-apple-darwin19/11\_2\_0"

That’s very interesting. Those paths being three means it should work. Can you try installing `gcc` and `libgcc` Homebrew formulas to see if that solves it? There’s an alternative way to setup the env var which I haven’t tried yet. I’ll bug you if I get that working if you don’t mind.

random trivia: "Gift" in German (and apparently in Swedish) seems to be a euphemism: a "given thing". English preserves the non-euphemistic meaning. (Something similar happened in Tocharian versus the other Indo-European languages: a word which shifted to "poison" in other Indo-European languages retained the meaning "give"/"gift" in Tocharian.)

I already tried to install gcc and libgccjut with homebrew without any success.

Hmm, is this launching emacs via Finder/Spotlight, or from a terminal? If it doesn’t work from terminal either, I’m afraid I’m out of ideas. Specially as I don’t have a M1 machine myself yet.

This problem is only for x86. Got it working on M1. Launching from finder.

There isnt a configure option. Its a new mode. Though you may need xinput2 compile option; i'm not sure.