Emacs 28.2 is released

Version 28.2 of Emacs, the extensible text editor, should now be available from your nearest GNU mirror: https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz The tarball is signed; you can get the PGP signature file at: https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz.sig https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz.sig You can choose a mirror explicitly from the list at: https://www.gnu.org/prep/ftp.html Mirrors may take some time to update; the main GNU FTP server is at: https://ftp.gnu.org/gnu/emacs/ To verify that the downloaded tarball is intact, download both the tarball and the corresponding .sig file, and run this command: gpg --verify emacs-28.2.tar.xz.sig (and similarly for emacs-28.2.tar.gz, if you download that format). If the GPG command fails because you don't have the required PGP public key, run this command to import the key: gpg --keyserver pgp.mit.edu --recv-keys \ CEA1DE21AB108493CC9C65742E82323B8F4353EE Alternative keyservers to try are keyserver.ubuntu.com and keys.openpgp.org. You can also run sha1sum or sha256sum and confirm that these checksums match: SHA1 emacs-28.2.tar.xz d61863db02b732547e6d6c77081e3348734458be SHA1 emacs-28.2.tar.gz b019ec832c73cd8548981fe2bc11a7d6e812ddb9 SHA256 emacs-28.2.tar.xz ee21182233ef3232dc97b486af2d86e14042dbb65bbc535df562c3a858232488 SHA256 emacs-28.2.tar.gz a6912b14ef4abb1edab7f88191bfd61c3edd7085e084de960a4f86485cb7cad8 Emacs 28.2 is a bug-fix release, with no new features with respect to Emacs 28.1. For the complete list of changes and the people who made them, see the various ChangeLog files in the source distribution. For a summary of all the people who have contributed to Emacs, see the etc/AUTHORS file. The online manuals and website will be updated shortly. Printed copies of the Emacs manual are available for purchase from the Free Software Foundation's online store at: https://shop.fsf.org/product/emacs-manual/ For more information about Emacs, see: https://www.gnu.org/software/emacs

[Changelog](https://raw.githubusercontent.com/emacs-mirror/emacs/emacs-28/ChangeLog.3)

Arch Linux's repository already has the new version it seems. I'm starting emacs as systemd daemon and I was getting weird errors after updating and before restarting it. I had to run `systemctl --user daemon-reload` and `systemctl --user restart emacs` to get it working again. Just in case anyone is having similar issues.

Where can I find this? I don't see 28.2 at for example [http://gnu.mirrors.hoobly.com/emacs/windows/emacs-28/](http://gnu.mirrors.hoobly.com/emacs/windows/emacs-28/) and it's not showing up in my Ubuntu jammy distro with \`sudo apt update; sudo apt upgrade\`

​ Oh i see the 28.2 sources are there a couple levels up. I guess it takes time for the platform builds to complete. Maybe I should try building myself..

I would be surprised if it didn’t break this way haha

when is 29 coming

Now if you build via source :)

is it stable?

By definition, no.

When it's ready?

Stable enough. I've run master for like a year on both macOS and Linux without any significant issue

90% of the time it's fine, but annoyingly, breaking bugs are introduced occasionally. As long as it's easy to switch to a known working version, it's normally stable enough for everyday use.

If you pin it, yes. If you don't pin it, you'll have a few minor issues per month and major per year.

of course but stability is more of a continuous distribution than a discrete measure

what does it mean to "pin"

depends on the day, but if you take 5 minutes testing your build (make check, and a few manual stuff for your extensions) you won't have any issues I've used semi-nightly builds for a year and had less than 5 bad days. my setup is not huge but has around 30 use-package clauses

The definition of stable in a software release terminology is that is is not changing. Emacs 28 will not change anymore, only smaller bug fix focused releases are planned to happen if necessary which means that it is stable. New features and some times even backwards incompatible changes goes into into Emacs 29 and/or master which means that they are unstable.

The first commit there caught my eye: `Don't say "Emacsen"`. Are we now discouraged from using "Emacsen" as a word?

yeah, reliability is probably a better word to use for the other meaning people think of

There's plenty of other uses of "emacsen" in the repository emacs on  emacs-28 ❯ grep -R emacsen * | wc -l 56

To use a consistent version, instead of whatever is most recently released.

I mean this as friendly advice and not nastiness: if you didn’t already know what “pin” means in this context, you should not use the bleeding edge version. You probably won’t notice the cool new changes, but you’ll almost certainly notice the bad ones. It’ll be a bad user experience for you, and you won’t know why: is it because Emacs sucks, or because you hit a random alpha version bug?

thank you for your advice, I've been using Emacs for a couple of years now but I never cared for bleeding edge versions unless it was something I really wanted like native-comp or pixel scrolling. 29 has pixel scrolling and that's the only reason I wanted to try it. On pinning, well its a drowsy day mate.

Almost all of those are old changelog entries.

Right on. We’ve all been there!

For a real win in performance you can compile emacs from source with "./configure --with-native-compilation". That makes emacs compile elisp to machine code via LLVM. REMEMBER to compile all our elisp libraries as well :) A bit of hit and miss for me but got it work ina couple of tries.

Where have you notice gains in performance? I tried it the other day and it increased start up time (but no by much, 0.2 secs, I understand this a price JITs need to pay)

Before exclusively settling on pinning master I frequently bounced between stable/unstable. Many people's needs are better served by just using stable and waiting probably, but I found myself hitting walls and wanting newer features.

The reason I'm asking is not for the sake of making a snarky remark, there are certain words that RMS and FSF advocates dislike. For example, the word "ecosystem" he says is amoral, when I asked him to suggest an alternative, he said: > The term "ecosystem" -- and the amoral approach associated with it -- are widespread in the computing field. Using that term encourages that amoral approach. > In the free software movement that we have a different approach: free software is just and nonfree software is unjust. So we don't want to find another word to use instead for the same meaning. The meaning is what we want to shun If 'Emacsen' for some reason is now "being canceled", I'd like to know it. So I don't use the word in emacs-dev mailing list. Whatever religious stupid games they play - not my business. I just don't like being scolded and "reminded" that "we don't use certain words here", like some four-year-old kid.

LSP. If you're using lsp-mode or eglot, things should get a bit faster.

It's GCC-Jit and not LLVM that is used.

I haven't had any crash with 29 since 28 was released :D.

Old text (see `(info "(idlwave)Troubleshooting")`): > The problem is that your Emacs is not finding the version of IDLWAVE you installed. Many Emacsen come with an older bundled copy of IDLWAVE (e.g., v4.7 for Emacs 21.x), which is likely what’s being used instead. New text: > The problem is that your Emacs is not finding the version of IDLWAVE you installed. Emacs might come with an older bundled copy of IDLWAVE which is likely what's being used instead. A use of "Emacsen", as a plural of "Emacs", was removed. The changelog entry describes a change, not a directive to the reader.

Ah, it's a bad commit message. Seeing the change makes it clear what is it about. Thank you for showing that.

[NEWS](https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.28) > * **Installation Changes in Emacs 28.2** > > * To install the Emacs binary in a non-standard directory, use '--bindir='. > > If you install Emacs in a way that places the Emacs executable file in a directory other than "${prefix}/bin", you will now need to specify that at configure time, if you build Emacs with native-compilation support. To this end, add the '--bindir=DIRECTORY' switch to the command line of the 'configure' script, where DIRECTORY is the directory in which you will install the executable file "emacs". This is required even if you place a symlink under "${prefix}/bin" that points to the real executable file in some other DIRECTORY. > > It is no longer enough to specify 'bindir=DIRECTORY' on the command line of the "make install" command. > > The reason for this new requirement is that Emacs needs to locate at startup the directory with its "*.eln" natively-compiled files for the preloaded Lisp packages, and the relative name of that directory needs therefore to be recorded in the executable as part of the build. > > * **Changes in Emacs 28.2** > > This is a bug-fix release with no new features. > > * **Changes in Specialized Modes and Packages in Emacs 28.2** > > * The command 'kdb-macro-redisplay' was renamed to 'kmacro-redisplay'. > > This is to fix an embarrassing typo in the original name. > > * 'desktop-save-mode' now saves the desktop in 'save-buffers-kill-emacs'. > > Previously, the desktop was saved in 'kill-emacs' via 'kill-emacs-hook'. However, that violated the convention that functions in 'kill-emacs-hook' cannot interact with the user, and in particular didn't play well with ending daemon sessions of Emacs. So we moved the saving of the desktop to 'save-buffers-kill-emacs', via 'kill-emacs-query-functions'. To make sure the desktop is saved, terminate Emacs with 'save-buffers-kill-emacs', not with 'kill-emacs'. > > (This change was done in Emacs 28.1, but we didn't announce it in NEWS back then.)

Why would I change my language if RMS dislikes a word? For me,ecosystem doesn't have a bad connotation or semantics. There is an IT ecosystem, a software ecosystem, a commercial/proprietary ecosystem and - gasp - a FOSS ecosystem. Denying this is bonkers, and it will only muddle precise thinking. We can perhaps dislike the meaning of a word, e.g. "murder". But cancelling the word because of this is weird. Like an absolute monarch shooting the messenger. This won't change the bad act reported by the messenger, the murdering, or the perhaps bad aspects of a certain ecosystem. It would be bad in itself. No, RMS is not my censor.

[deleted]

For me? Yes.

> Why would I change my language if RMS dislikes a word? I'm not asking you to change your language :) and I'm not telling you not to use [any] words. Whatever eccentric behaviors make some people dislike or even hate RMS, it's between them. From my side, I have nothing but respect for the man, yes, there are rumors of mistreatment and even abuse, but I personally don't know anyone who can claim to be that kind of victim. Courtesy commands to be respectful. If any person tells me that something irritates them, be that specific smells, colors, or words - I'd try to change my behavior, so they can focus on helping me, instead of arguing. So what if RMS doesn't like certain words? He wants to be quirky, maybe let him be?

IIRC (and I might not), I did see a dev email about this which indicated the reason was that the term was present in the docs primarily on account of XEmacs, but as that project is now officially discontinued there was little reason to continue using the phrase.

What? I don't get it. So, those who used XEmacs are Emacsen, but others are... Gnumacsen? LOL.

Since Xemacs is no longer developed, the GNU Emacs developers see less reason to mention it. Instead of talking about multiple "Emacsen", they now talk about one "Emacs", which, in the case of this documentation, refers to GNU Emacs.

"Emacsen" is a colloquial umbrella term for all implementations of Emacs. There have been many of those, but in recent times "GNU Emacs" and "XEmacs" were the only two of great significance (with many libraries being written to explicitly support both). Now the latter has ceased to be a maintained project, so there's less of a reason for the GNU Emacs docs to make reference to other implementations. [insert Highlander quote here]

I’ve noticed it a lot everywhere, but mostly on large files. For some reason my emacs is typically quite sluggish with all the nodes, native compilation fixes that. Easily 2x perf gain.

> not showing up in my Ubuntu jammy Jammy is still stuck on 27.1 (released in 2020). Debian unstable has 28.1, so I would expect a newer version to trickle down to some future version of Ubuntu. > Maybe I should try building myself It's easy enough. The trickiest part is finding & installing the pre-requisites.

There's a school of thought in git commits about the imperitive voice. "Make your commits sound like you're telling the code what to do" vs "tell the user what you did". I use the latter. The former is just silly, IMO. Reasonable people disagree, and that's fine.

> installing the pre-requisites. I ended saving a script in my dot files for this. Yes, it's a pain.

I'd like to start doing this on MacOs. You don't have anything scripted up to get all the prerequisite libs and compile, do you? Would love to ~~see~~ steal it.

I use https://github.com/jimeh/build-emacs-for-macos which makes the custom build really easy.

> "Emacsen" is a colloquial umbrella term for all implementations of Emacs. Hmm, I always thought 'Emacsen' is a collective noun for a group or community of Emacs users.

After switching from 28.1 to 28.2 (local builds, same configs) Emacs now systematically refresh the package archives (ELPA, etc.) on every start :( Does anyone see this too? Any idea what could cause this change? Thanks

thanks will take a look.

Windows Binaries for Emacs 28.2 are published. (Note: they make take some time to flow down to your favorite mirror.) https://ftp.gnu.org/gnu/emacs/windows/emacs-28/?C=M;O=D

I use emacs-plus from homebrew

I saw that on my first start, but not subsequently.

As the guy who wrote this bit of troubleshooting text for the info doc some 20 years ago... XEmacs was specifically supported at that time. So this is a perfectly reasonable change IMO. BTW, IDLWAVE currently has no active maintainer; if anyone is interested, [get in touch](https://github.com/jdtsmith/idlwave)! To this day it has a few features that blow away all the modern LSP/DAP/etc. constellation, like electric debug, deep help doc integration, robust shell communication, etc... all custom-crafted (for a niche language). I miss it often.

I'm unaware of any collective noun for Emacs users, but that seems like a fun notion. A consing? A buffer? A recursion?

Terms such as “Emacsen” and “(X)Emacs” are not wrong, but they are not very clear, so it is better to write “Emacs and XEmacs.” [https://www.gnu.org/software/emacs/manual/html\_mono/efaq.html#What-was-XEmacs\_003f](https://www.gnu.org/software/emacs/manual/html_mono/efaq.html#What-was-XEmacs_003f)

Thanks for the feedback. It seems it was a local issue: a weird behavior with use-package (but I'm using an old Debian version) and an Org configuration. So on my side, and I have a work-around.

>The trickiest part is finding & installing the pre-requisites. Not hard at all if you're on Debian: apt build-dep emacs.

That "depends" on which version of emacs `apt build-dep emacs` is using. emacs 28 introduced the notion of native compilation. Using the dependencies of emacs 27 wouldn't help in this situation. Remember that it is only in the last couple of months that any version of emacs > 27.1 has made it into Debian. Additionally, for unknown reasons, Ubuntu earlier than 22.04 did not include the emacs source package in their repositories.

Ah yes, of course! I forgot about native compilation since I don't use it. I didnt have to install any new libraries from I went from 26 to 27, also forgot about the webp library I installed when I went to Emacs 29.

From emacs-devel mailing list today: [Re: master 55f46cc77c: Decrease use of the word "Emacsen" in docs](https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00014.html) Looks like your crystal ball was working wonders :)