Emacs 29.1 released
| From: | Eli Zaretskii <eliz-AT-gnu.org> | |
| To: | emacs-devel-AT-gnu.org | |
| Subject: | Emacs 29.1 released | |
| Date: | Sun, 30 Jul 2023 10:00:16 +0300 | |
| Message-ID: | <83sf95lw8v.fsf__42388.2910794177$1690726445$gmane$org@gnu.org> |
Hi! Version 29.1 of Emacs, the extensible text editor, should now be available from your nearest GNU mirror: https://ftpmirror.gnu.org/emacs/emacs-29.1.tar.xz https://ftpmirror.gnu.org/emacs/emacs-29.1.tar.gz The tarballs are signed; you can get the corresponding PGP signature files at: https://ftpmirror.gnu.org/emacs/emacs-29.1.tar.xz.sig https://ftpmirror.gnu.org/emacs/emacs-29.1.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-29.1.tar.xz.sig (and similarly for emacs-29.1.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 keyserver.ubuntu.com --recv-keys \ 17E90D521672C04631B1183EE78DAE0F3115E06B Alternative keyservers to try are pgp.mit.edu and keys.openpgp.org. You can also run sha1sum or sha256sum and confirm that these checksums match: SHA1 emacs-29.1.tar.gz 3c340fd281571a72b87d17cd295a580fffecb1c0 SHA1 emacs-29.1.tar.xz 39a14d9ae5596336da76789c7b977ba66eb09a57 SHA256 emacs-29.1.tar.gz 5b80e0475b0e619d2ad395ef5bc481b7cb9f13894ed23c301210572040e4b5b1 SHA256 emacs-29.1.tar.xz d2f881a5cc231e2f5a03e86f4584b0438f83edd7598a09d24a21bd8d003e2e01 For a summary of changes in Emacs 29.1, see the etc/NEWS file in the tarball; you can view it from Emacs by typing 'C-h n', or by clicking Help->Emacs News from the menu bar. You can also browse NEWS on-line using this URL: https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS... 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. For more information about Emacs, see: https://www.gnu.org/software/emacs
Posted Jul 31, 2023 15:24 UTC (Mon)
by anarcat (subscriber, #66354)
[Link] (1 responses)
A shorter version is this:
https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.ht...
Notable additions to the above summary: use-package and eglot now shipped with Emacs, Faster editing of files with very long lines, Enhanced support for editing and displaying Emoji and more!
I'm really excited about eglot, tree-sitter and Wayland support myself, really too bad they missed the Debian bookworm release window...
Posted Jul 31, 2023 15:42 UTC (Mon)
by dskoll (subscriber, #1630)
[Link]
It is too bad they missed Bookworm, but maybe some kind developer will put it in backports.
Posted Jul 31, 2023 16:39 UTC (Mon)
by sahas (subscriber, #107731)
[Link] (30 responses)
Posted Jul 31, 2023 18:03 UTC (Mon)
by atai (subscriber, #10977)
[Link] (29 responses)
Posted Jul 31, 2023 18:16 UTC (Mon)
by jem (subscriber, #24231)
[Link] (4 responses)
Or Firefox, Chromium, Blender, Inkscape, Libreoffice, FreeCAD, the whole suite of KDE software. Just to name a few.
Posted Jul 31, 2023 21:49 UTC (Mon)
by jrtc27 (subscriber, #107748)
[Link] (2 responses)
Posted Aug 1, 2023 0:36 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Aug 1, 2023 6:22 UTC (Tue)
by jrtc27 (subscriber, #107748)
[Link]
Posted Aug 1, 2023 5:59 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link]
Posted Jul 31, 2023 18:16 UTC (Mon)
by corbet (editor, #1)
[Link] (23 responses)
Posted Jul 31, 2023 18:49 UTC (Mon)
by lunaryorn (subscriber, #111088)
[Link] (22 responses)
Electron applications still require some non-default flags to run on Wayland, proprietary Qt applications often still don't ship Qt's wayland library in their bundled copy of Qt, and Java still doesn't support Wayland at all. From my point of view we still have a long way to go for this transition.
Say what you want about Electron, but Jetbrains' IDEs arguably keep at lot more people stuck on xwayland than Emacs used to do ;)
Posted Jul 31, 2023 20:34 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (21 responses)
1. If you are the author or maintainer of some sort of terminal app...
The gnome-terminal bug is from 2018 and discussion consists almost entirely of security bikeshedding, despite the fact that multiple mature FOSS implementations exist in the form of other terminal emulators: https://gitlab.gnome.org/GNOME/vte/-/issues/2495
A list of bugs in other emulators can be found here (no idea if this is up-to-date, just found it on Google): https://github.com/ojroques/vim-oscyank#vim-oscyank
Posted Jul 31, 2023 22:57 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (10 responses)
Posted Aug 1, 2023 0:05 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
Proper support for this is necessary, because both Vim and (e.g.) Tmux can be used to split the screen into smaller windows or panes (respectively) and so if you try to copy raw characters with your mouse, you'll get a lot of nonsense whitespace that shouldn't be there (at least, for longer selections, anyway). In order to fix that, you either need Vim (or Tmux etc.) to have native clipboard support, or you need it to somehow tell the terminal emulator exactly which characters should be considered for mouse selection (which I don't believe is covered by any well-known standard, but I could be mistaken).
Posted Aug 1, 2023 8:44 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (7 responses)
(FWIW, I use vim as my only editor, but I never use "+ or "*. Obviously your workflow is different.)
Posted Aug 1, 2023 15:22 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
OSC-52 is a generic terminal/serial protocol that can be implemented by anybody on any kind of windowing system, but it just handles clipboard access (whereas X11 forwarding is a far more complex beast that lets you run a whole X client over SSH). The extremely simple version is, the program outputs some control characters, which describe either a copy or a paste, and the terminal emulator is responsible for doing the copy/paste operation as requested, so the program doesn't need to know anything about $DISPLAY etc. in order to access the system clipboard.
Most of the gnome-terminal bikeshedding is of the "but what if somebody has something sensitive in their clipboard?" variety. The standard solution to this problem appears to be write-only access, i.e. you implement copy but not paste (or have paste just output an empty string), so that at worst a remote host can clobber your clipboard, but it can't read secrets from your clipboard.
Posted Aug 1, 2023 15:56 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (4 responses)
Now, it sure would be nice to have some sort of network transparency for graphics even as we phase out X11. But that feels like a different issue to me.
Posted Aug 1, 2023 18:35 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
I agree. That's why I wrote a "rant" about gnome-terminal: This should be the terminal emulator's problem, not the windowing system's problem.
Posted Aug 2, 2023 16:44 UTC (Wed)
by Per_Bothner (subscriber, #7375)
[Link] (1 responses)
Right - but unfortunately there is no simple portable API for accessioning the clipboard. Even for JavaScript-based terminal emulators (such as DomTerm and xterm.js) there are security policies that limit access. The simplest is to invoke a helper application - but these aren't portable either. If curious you can look at the code for
Posted Aug 3, 2023 17:27 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
In this context, OSC 52 is that API - it's an API between an application and the terminal emulator, allowing the application running in the terminal to ask the terminal emulator to perform clipboard accesses for it.
The problem is that VTE, one of the common implementations of a terminal emulator (used by GNOME Terminal, among others), deliberately doesn't support this API. As a result, instead of terminal applications like vim using OSC 52, they use a remote X11 connection to access the clipboard using X11 APIs, while rendering using terminal APIs like OSC. This is a hack around the lack of OSC 52 support in common terminal emulators.
Posted Sep 18, 2023 6:55 UTC (Mon)
by daenzer (subscriber, #7050)
[Link]
FWIW, there's Waypipe, which works more or less like X11 over SSH from a user PoV: https://gitlab.freedesktop.org/mstoeckl/waypipe
> But that feels like a different issue to me.
Yeah, since this discussion is about a feature of the terminal emulator, which should normally run locally in the user session, I'm not sure how SSH tunnelling of the display protocol is relevant.
Posted Aug 1, 2023 16:01 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
This, yes.
The problem: users want terminal applications to interact with the system clipboard. By extension, users also want _remote_ terminal applications to interact with the _local_ system clipboard (think Vim over SSH).
The solution: an escape sequence protocol (OSC-52) was invented to do exactly that, and it trivially works over any nested configuration of remote shells (application emits an escape sequence -> remote shells relay that sequence -> user's terminal emulator parses the escape sequence and acts on it).
HOWEVER, VTE developers think that OSC 52 is a security threat and refuse to implement it. The closest possible workaround is for the terminal applications to "piggyback" on the X11 clipboard directly, because everyone who cares about this feature is ultimately sitting in an X11 environment. This workaround is "local" in nature, but it can be extended to remote sessions by way of SSH X11 forwarding.
The problem #2 is that Wayland has no equivalent of X11 forwarding.
Posted Aug 1, 2023 6:08 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link]
Posted Aug 1, 2023 1:12 UTC (Tue)
by flussence (guest, #85566)
[Link] (7 responses)
If it's not *supposed* to suck then that's news to me…
Posted Aug 1, 2023 1:20 UTC (Tue)
by willy (subscriber, #9762)
[Link] (2 responses)
Posted Aug 1, 2023 9:31 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (1 responses)
Posted Aug 2, 2023 1:15 UTC (Wed)
by salewski (subscriber, #121521)
[Link]
The upstream issue with a long discussion:
"Defaulting mouse=a in a terminal is incorrect (new as of 7.4.2111)"
> But I still have “set mouse=” in my .vimrc, indeed.
Same here.
Posted Aug 1, 2023 1:50 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
This is because of a rather unfortunate design decision on the part of X (basically, your clipboard is not a buffer, it is merely a reference to the X client that initiated the copy, so if that X client exits, then the clipboard is a dangling reference to nothing), which can cause problems even for local X clients (unless your DE takes responsibility for the clipboard data, which I know some DEs do). It would be fixed if vim used OSC-52, because then the X client responsible for the copy would be the terminal emulator, and not vim. It would also be fixed if we could somehow establish a protocol for vim to tell ssh to do the copy locally, but that would be rather silly since OSC-52 is a more general solution anyway.
Posted Aug 2, 2023 12:47 UTC (Wed)
by jch (guest, #51929)
[Link] (1 responses)
There's a good reason for that: the X11 selection mechanism allows negotiating the format of a selection transfer: for example, a word processor can offer the selection as RTF, HTML and plain text, and the requestor can choose the format that it prefers. This allows evolving the protocol without breaking compatibility with existing applications, for example when we implemented Unicode copy-paste back in the late 20th century:
https://www.irif.fr/~jch/software/UTF8_STRING/UTF8_STRING...
If the selection were stored in the server, the application would need to transfer it in all supported formats every time the user selects something, possibly over a slow network connection.
> so if that X client exits, then the clipboard is a dangling reference to nothing)
No, if the selection owner closes the connection to the X server, the selection owner is set to NULL.
Posted Aug 3, 2023 19:04 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
It's interesting to compare the (older) X11 mechanism to the Win32 clipboard mechanism in this regard.
In the X11 mechanism, the server provides the ability to own one or more selections; both cut and copy are "just" claiming ownership of a selection. Paste requires you to use the TARGETS atom to list possible formats, then choose one, then request a conversion to your preferred format; as an optimization, if you only support one possible format, you can ask for data in that format, and simply fail if the owner can't supply it. Once the data is converted to the right format by the owner, you can transfer it through the server.
Win32 is different in some significant ways:
It's worth noting that both mechanisms allow negotiating the format of a transfer; the primary difference is that the Win32 mechanism puts the data ownership in the server, and gives the owner no knowledge of when a paste happens (since it's implementation-defined when a delayed representation is requested by the server).
Posted Aug 8, 2023 1:45 UTC (Tue)
by repetitivestrain (guest, #165872)
[Link]
Revolving around selection ``ownership'' is not a bad design decision, it's a feature of the X inter-client communications convention. There are many different selections, most of which do not justify uploading the selection data to an X server or another form of specialized selection data storage.
For the selections that do warrant being saved after their owner windows are destroyed (CLIPBOARD is the only selection that comes to mind), users have the option of running a CLIPBOARD-managing client, which proactively monitors for changes in selection ownership, converts them to a number of specific targets and subsequently obtains ownership over them, or employing a clipboard manager, a client selection ownership and data will be transferred to when the original owner of the CLIPBOARD selection terminates.
The disadvantage of running a CLIPBOARD managing client is that you limit the flexibility of the protocol itself: for example, if your CLIPBOARD managing client only requests the STRING and COMPOUND_TEXT targets from your selection, then future attempts by other clients to insert the contents of CLIPBOARD won't be capable of receiving UTF-8 or file names from that selection; this is also compounded by how relegating the task of replying to selection requests to a separate client diminishes the ability of selection owners to provide feedback in response to selection requests (for example, there are several Emacs packages that provide visual feedback ranging from deactivating the region to beeping whenever another client attempts to insert the contents of the clipboard.)
Whereas with a clipboard manager, that flexibility is only lost once your client terminates. Lamentably, support for the clipboard manager protocol is rather lackluster, which is its sole disadvantage. I presume Vim doesn't support it; why not use Emacs instead?
Many lessons learnt during the long development of the X Window System appear to have been lost on the Wayland developers, but the selection transfer mechanism is not one of them. Wayland defines a single clipboard selection, but as with X, selection data is not uploaded to the display server. Instead, a token dubbed a data source is provided, and subsequent requests for selection data by other clients supply a FIFO which the creator of the data source is expected to write the requested data to.
In their inexorable quest to pastiche Microsoft Windows, GNOME's display server requests and saves the selection data itself every time a new data source is set, thereby serving as the Wayland analogy of a CLIPBOARD-managing client, making life difficult for the aforementioned Emacs packages. But I have to concede that the lack of a clipboard manager-esque protocol is a glaring omission in Wayland, and GNOME's manifesting the only means to provide users with behavior that they are already accustomed to.
Posted Aug 1, 2023 13:10 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (1 responses)
I suspect I might be missing some context here, but FWIW, SSH X11 forwarding works in a Wayland session via Xwayland, same as with any other X server.
Posted Aug 1, 2023 15:12 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
The context you are missing is that XWayland IS NOT THERE.
Cheers,
Posted Aug 2, 2023 7:09 UTC (Wed)
by coriordan (guest, #7544)
[Link] (13 responses)
After a web browser, this is the application I use the most every day.
Posted Aug 2, 2023 12:33 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (12 responses)
Fortunately for me I use it more often than a web browser (I really hate browsers).
That's also the reason I almost never upgrade it, because it regularly causes major
Posted Aug 3, 2023 12:31 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
Posted Aug 8, 2023 22:17 UTC (Tue)
by jacktucker (guest, #166423)
[Link] (10 responses)
What happens from time to time is that, after much discussion, the default value for a configuration variable is toggled. In that case resetting that configuration variable to its former default value restores the previous behavior. This is always documented in the NEWS file, but that file is too big, and understandably few users read it.
I would suggest that the next time you upgrade and you face such a problem you ask for help on help-gnu-emacs@gnu.org. You don't need to be subscribed, and usually most questions posted there are answered in a few hours.
Posted Aug 9, 2023 1:01 UTC (Wed)
by repetitivestrain (guest, #165872)
[Link] (4 responses)
Posted Aug 10, 2023 4:09 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
I must say I don't have the reflex to file bugs related to incompatible changes, I imagine they're expected, and frankly when I have to start working on my activities and spend 3-4 hours trying to get my editor back in a state where it's barely usable, the last thing I want to do is to set everything aside and switch to an editor debugging session. That's too central a piece of program for lots of developers.
What I'm really missing is the ability to roll back to an older version in fact. Usually it comes with plenty of packages and it seems everything is tightly coupled, so if you want to roll back you need to roll back everything, and often the older binaries are incompatible with the newer distro due to dependencies on older libs (which is not emacs' fault, just the total mess that lib dependencies on distros is due to some libs having no consideration for strict forward compatibility).
Sadly it's much easier and riskless to upgrade a kernel than an editor, because if it doesn't work, you just restart from the previous one and you're done. The kernel is only an isolated binary with zero dependency. An editor is in fact much more of a whole ecosystem and you rarely have that flexibility.
Posted Aug 10, 2023 13:04 UTC (Thu)
by jacktucker (guest, #166423)
[Link]
Yes, that's electric-indent-mode which was enabled by default in Emacs 24. I did not see that change, when I started using Emacs it was at version 25.
> I must say I don't have the reflex to file bugs related to incompatible changes
It's also something I did not do earlier, because I did not know it is so easy: all you need is to send an email to help-gnu-emacs@gnu.org. In my experience the community there is friendly.
Posted Aug 10, 2023 18:07 UTC (Thu)
by jem (subscriber, #24231)
[Link] (1 responses)
As someone who has used Emacs for about 40 years, but is only now trying to turn Emacs into a Java IDE, I want to say that Emacs's biggest weakness is not the instability of the core, but the packages. The packages change a lot, and their inter-compatibility is a challenge. I long for some kind of super-packages for more complex tasks like creating an IDE, which requires getting 15-20 packages from different sources to play nicely together. Or at least some official documentation; the situation today is that you have to search the web for third party instructions, which are typically outdated and abandoned.
Posted Aug 10, 2023 23:49 UTC (Thu)
by jacktucker (guest, #166423)
[Link]
What you describe explains the popularity of Emacs "starter kits", the two most popular ones are Doom Emacs and Spacemacs.
Posted Aug 9, 2023 8:47 UTC (Wed)
by mbunkus (subscriber, #87248)
[Link] (4 responses)
Yeah that's not how I see it really happening. They always deprecate some functions in favor of others (often only to better match certain naming schemes), and you will have to update your installed (M)ELPA packages fairly regularly with your Emacs updates. If you write a lot of elisp code or even maintain packages yourself, updating Emacs often means also updating a handful of things in your own code.
Also there are often user-visible changes to certain packages that might not strictly be Emacs itself, but are considered to be part of the base Emacs package. The most notably for me was the recent change in how TRAMP now requires a protocol (e.g. /ssh:root@… instead of just /root@…).
Are they major pain points? Hmmm not really, definitely not comparable to e.g. the amount of changes required for going from Python 2.x to 3.y. But they're there.
All that being said: my upgrade from 28.x to 29.1 last week went by pretty much without a hitch. Yes, I also updated all my installed (M)ELPA packages at the same time, but that was it. No further issues since. Like it very much!
Posted Aug 10, 2023 3:57 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (3 responses)
I agree, that matches my experience as well. After an upgrade, my old config spews errors that I have no idea how fix. I do not remember any *single* upgrade that did not report such errors.
The problem when the config is a programming language based on functions, is that you cannot get useful hints such as "this keyword is now deprecated in favor of XXX, please adjust your config". No, instead you get stuff like "unknown function" or "no such variable" and whatnot. For a user this is extremely frustrating because you just want to be able to do your work as you did before the upgrade and you end up having to waste 4 hours scanning the net looking for others facing similar errors, and blindly copy-pasting there random stuff you don't understand until you recover a barely tolerable behavior that allows you to try to restart your work where you left it without wasting more time.
And I'm really not using anything fancy. My emacs is just an editor, mostly for C (with tags), sometimes for plain text files and occasionally for bash scripts. It doesn't do any of the eye-candy stuff I'm seeing others configure such as auto-completion, make, git integration, mail reader, browser etc. And once in a while I open a remote file, when google manages to remind me the syntax for what looks like a URL but is not. It's just an editor that I find comfortable when it works because it supports multiple files, multiple windows, including with the same file in several windows and copy-paste between multiple processes. I'm sure emacs developers would be extremely disappointed by seeing my simple level of usage and that I probably totally ignore most of the features they work on on a daily basis, and whose presence justifies breaking my usage from time to time.
I got used to its key bindings but I could probably switch to a much lighter reimplementation that supports the same bindings, multi-window/ediff, and syntax highlighting. Before X was a regular thing on Linux, I used to use "joe" which was quite good and light by then. But xemacs then emacs made it more comfortable to work on multiple files.
Posted Aug 10, 2023 13:04 UTC (Thu)
by jacktucker (guest, #166423)
[Link] (1 responses)
I agree, that matches my experience as well! :) But as I said, when this happens, you can either read the NEWS file (which nobody does), or ask for help on help-gnu-emacs@gnu.org (which is much easier). Just list the errors you see, and you'll get help on how to fix them in a few hours. That's what I did, and it worked quite well.
Posted Aug 10, 2023 17:45 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
Posted Aug 11, 2023 1:06 UTC (Fri)
by repetitivestrain (guest, #165872)
[Link]
Not that I approve of renaming functions for mere cosmetic reasons. I usually make a point out of advocating against such rash behavior.
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
I run a fairly wide variety of applications on my machine, and none of them are using the X11 protocol at this point. From my point of view, at least, that transition has been done for a while.
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
2. ...that wants to copy or paste things to the system clipboard...
3. ...and have it work over SSH...
4. ...and not have to tell your users "sorry, it's broken in gnome-terminal"...
5. ...then the only way to do that is via X11 forwarding...
6. ...which (as far as I'm aware) is not supported by Wayland.
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
"This should be the terminal emulator's problem, not the windowing system's problem."
Emacs 29.1 released
get_clipboard_command in lws-term/utils.cc in the DomTerm sources.
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
https://github.com/vim/vim/issues/2841
Emacs 29.1 released
X selection
X selection
Emacs 29.1 released
Emacs 29.1 released
> 6. ...which (as far as I'm aware) is not supported by Wayland.
Emacs 29.1 released
Wol
Emacs 29.1 released
Emacs 29.1 released
breakage like completely changing the way auto-indent works or stuff like this, to
the point of not being fixable by just a few config changes, and requiring 6 months
of training to get used to the new way to use it. In 27.2 I had to disable it so that
it stops inserting random tabs and spaces on empty lines everywhere in my code... So
basically I discover a new emacs with each new laptop, and hate it for many months,
then progressively get used to it and try hard not to see it change again for 5-8
years.
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released
Emacs 29.1 released