I’ve used every 29.1 pretest and rc across Windows, Mac, and Linux (Ubuntu, Debian, Manjaro, and Pop!_OS) and I’ve encountered no majors issues in the last few months. I’ve run these commands more than I’ve ever done before so maybe I will remember them this time lol
Really happy to see this release. Can’t wait to see all the new modes adopting tree-sitter. Haven’t been this excited about an Emacs release in a while! Looking forward to the day when this is the default Emacs on most Linux Distros but that will take a couple years
Emacs has made incredible progress since the late 2000s. At the time, you had to manage package libraries and versions manually. Plus, there was a lot of glue code you had to copy-paste into ~/.emacs to get it all working. For example, setting up Emacs for Ruby on Rails was quite hard. The outcome was fragile and often broke with updates.
With ELPA and use-package, everything has become much more streamlined, and as a consequence a very rich package ecosystem has emerged. My only complaint right now is that many packages still require a bit of ~/.emacs code to get up and running. Plus, documentation about how to mix and match packages to get IDE-like features is not great. The best source for that is, paradoxically, Doom Emacs. IMHO, this scares beginners away compared to VS Code, which is a shame.
I still remember the day when I read Your Text Editor Is Malware, I removed all the Emacs packages and manually git cloned or copy-pasted them to get some illusion of safety.
I guess the primary benefit by not using a package manager is getting a better understanding of their dependencies.
It’s cool to see eglot included, but it has been easy to use it in older versions of Emacs for as long as it’s existed, since it’s a single file with no dependencies. A lot of people seem excited about tree-sitter and wayland, but those don’t really seem relevant to any of my own personal use cases. The thing I am looking forward to using is seeing what kind of wild hacks people end up doing with the native sqlite support.
A lot of people seem excited about tree-sitter and wayland, but those don’t really seem relevant to any of my own personal use cases.
Same. I don’t care about Wayland at all (I don’t use Emacs in graphical environments) and I’ll try tree-sitter but I have this nagging feeling it’s over-hyped.
I am also happy about the inclusion of eglot, although it won’t change much for me. I might start using use-package now that it’s not a dependency.
Better long line support seems long overdue. It’s a bit of an embarassement, to be honest.
and I’ll try tree-sitter but I have this nagging feeling it’s over-hyped.
If you are not using exclusively lisps, then syntax-aware selection (explained, e.g., here https://zed.dev/blog/syntax-aware-editing) is huuuuge. It’s one tiny feature, but for me like 60% of non-trivial edits are funneled through it.
TreeSitter gives you pretty great tools to be able to implement syntax-aware selection, but, if I understand correctly the actual feature isn’t in the core Emacs. The closest thing to what it should be is probably https://github.com/magnars/expand-region.el/pull/279, but that’s an unmerged PR to a third party package. (there are also things like combobulate, but I think they go a bit too far, syntax-aware selection is 80% solution at 10% UX complexity).
Right; that’s the impression I get from tree-sitter mostly; the rest of the world is finally catching up to what we’ve been doing with paredit since *checks comment header of paredit.el* 2005, apparently? =D
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.
I’ve been waiting a long time for this!
The new pipelining in Eshell looks exciting too, since that has been my main shell for years now.
To an outsider like me, it looks like Emacs development sped up in recent years. LSP and Tree-sitter integrations are especially noteworthy. It’s very impressive.
Piggybacking on this thread: what’s the current state of Emacs when it comes to remote development?
I’m aware of TRAMP but what I’m looking for is more complex.
I’d like a remote machine do most of the work (e.g. compilation, debugging, running a binary, code search). At the same time I’d like the text editing experience to not suffer the network latency so I’d like the client to run locally.
What are my options? Do you have any tried workflows?
It depends a lot on the language you are aiming to work with. Some modes have excellent TRAMP support, and if editing remote files they will fire a remote LSP, compiler / interpreter, etc. Others do not provide TRAMP support at all.
If your favorite major mode does not support TRAMP, one possibility is perhaps to use mosh instead of SSH and run the whole emacs remotely. This can reduce the impact of network latency.
It depends a lot on the language you are aiming to work with. Some modes have excellent TRAMP support, and if editing remote files they will fire a remote LSP, compiler / interpreter, etc.
That’s neat, I didn’t know that. I will check it out, thank you!
In my case it’s mostly Rust, Python, Go and sometimes C++.
The python-mode that ships with Emacs works really well with TRAMP, i.e. it fires a remote terminal, etc. I think all popular Python packages, such as anaconda-mode, build on top of it. So you are covered in that front.
I have never tried remote development using the other languages you mentioned.
I don’t think there’s one true easy option for that. Tramp is great but it’s possible individual libraries/modes will have buggy support. Editing over ssh is great if you don’t mind that. Honestly with something like the kitty terminal using emacs over ssh looks great and works for everything except actual inline images (although kitty can display those on it’s own, but emacs doesn’t know how to tell kitty to draw images… yet).
The venerable option of X11 forwarding can work, if latency is low.
Another option that I’ve seen recommended is to basically run emacs gtk with an HTML5 renderer and access via web browser. I haven’t tried it but allegedly there’s a PGTK (pure gtk) branch that has been merged somewhere and since GTK has a method to render to HTML5 you can take advantage of that: https://www.reddit.com/r/emacs/comments/rj8k32/the_pgtk_pure_gtk_branch_was_merged/
Personally I’d just go with either kitty ssh or emacs with remote desktop such as chrome remote desktop or nomachine (as I understand it nomachine is basically a proprietary version of X11 forwarding that’s actually usable for non-trivial applications). I use it every day.
I do this every day for work inside tmux+mosh; mosh does a pretty good job of papering over network latency issues to the point where they’re basically undetectable in my experience. But I’m always connecting to a host in the same city as I’m located so if you want to like … cross an ocean or a continent this may not be viable.
I’d like a remote machine do most of the work (e.g. compilation, debugging, running a binary, code search). At the same time I’d like the text editing experience to not suffer the network latency so I’d like the client to run locally.
Whereas others responding would run Emacs in SSH, I guess I would run SSH either in Emacs (in ansi-term-mode) or in a separate terminal emulator alongside Emacs and run the compilation (etc.) commands in the SSH session. If you run those commands with key bindings, I imagine the bindings could be changed to send the commands to the SSH session buffer (if running SSH in Emacs), although I personally have not tried to write programmatically into a term-mode buffer.
I really hate GTK font rendering, to the point where, on Linux, I’ve reverted to using the lucid branch after the switch to GTK3, but I tried the pgtk engine and it’s really impressive. I don’t really care about Wayland compatibility for now, but on X11 it’s smooth and barely has any latency, which is amazing. The old GTK rendering engine felt pretty clunky, in addition to, you know, giving me awful goose foot wrinkles. There are many other factors contributing to the much smoother feel and to faster operation but, having briefly ventured into Emacs’ rendering innards some time ago, I suspect pgtk’s less contrieved way of doing things played a role.
Since I’m gonna have to do Linux development locally for a while, I think I’m going to take the plunge one of these days and try to see if I can get the pgtk engine to show text without giving me headaches. That would be really cool because lucid widgets is not something anyone should be using in 2023.
I’m pretty sure GTK doesn’t do font rendering itself, but uses FreeType and harfbuzz like everything else. My guess is that you have those configured the way you want them through XResources, which GTK is ignoring. If that’s the case, and you’re not using gnome-settings-daemon (or similar?), you need to edit ~/.config/gtk-3.0/settings.ini, and change the settings for gtk-xft-antialias, gtk-xft-hinting, gtk-xft-hintstyle, and gtk-xft-rgba to the values you like.
It’s a lot messier than that. I do actually have the gtk-3.0/settings.ini magic set but IIRC some of that also gets ignored under some circumstances (e.g. on Wayland) and is obtained via gsettings. I obviously have the gsettings magic configured, too, not that it helps everywhere – for instance WebKitGtk uses another text rendering path. GTK also seems to ignore my configuration for stem darkening, or I’m not chanting it in the right place, and some applications further override some of the font configuration (e.g. VS Code). This is why my secret Linux productivity hack is to ssh into linux boxes from macOS, this is completely ridiculous.
We recommend that you
use this configuration only if you are running a window system other
than X that’s supported by GDK. Running this configuration on X is
known to have problems, such as undesirable frame positioning and
various issues with keyboard input of sequences such as ‘C-;’ and
‘C-S-u’.
(I just use lucid, not sure what I’m missing out on, but can’t say I’ve noticed anything weird with fonts.)
In case somebody else wonders about it like I did, the default homebrew packages for emacs don’t have the option of turning on native-compilation. https://github.com/d12frosted/homebrew-emacs-plus does, but it’s not yet updated to 29.1.
I’ve used every 29.1 pretest and rc across Windows, Mac, and Linux (Ubuntu, Debian, Manjaro, and Pop!_OS) and I’ve encountered no majors issues in the last few months. I’ve run these commands more than I’ve ever done before so maybe I will remember them this time lol
sudo apt install build-essential autoconf automake texinfo libgtk-3-dev libxpm-dev libjpeg-dev libgif-dev libtiff-dev libgnutls28-dev libncurses-dev libjansson-dev libgccjit-10-dev ./configure –with-tree-sitter
make -j16
sudo make install
Really happy to see this release. Can’t wait to see all the new modes adopting tree-sitter. Haven’t been this excited about an Emacs release in a while! Looking forward to the day when this is the default Emacs on most Linux Distros but that will take a couple years
Emacs has made incredible progress since the late 2000s. At the time, you had to manage package libraries and versions manually. Plus, there was a lot of glue code you had to copy-paste into ~/.emacs to get it all working. For example, setting up Emacs for Ruby on Rails was quite hard. The outcome was fragile and often broke with updates.
With ELPA and use-package, everything has become much more streamlined, and as a consequence a very rich package ecosystem has emerged. My only complaint right now is that many packages still require a bit of ~/.emacs code to get up and running. Plus, documentation about how to mix and match packages to get IDE-like features is not great. The best source for that is, paradoxically, Doom Emacs. IMHO, this scares beginners away compared to VS Code, which is a shame.
I still remember the day when I read Your Text Editor Is Malware, I removed all the Emacs packages and manually git cloned or copy-pasted them to get some illusion of safety.
I guess the primary benefit by not using a package manager is getting a better understanding of their dependencies.
I tried the build instructions here and they didn’t work on Debian 12. Just FYI, you need to use
libgccjit-12-devinstead oflibgccjit-10-dev.The point being that you probably shouldn’t blindly copy this in the hopes it will work.
Also, this:
https://emacsredux.com/blog/2023/07/30/emacs-29-1-released/
And also, this: https://www.masteringemacs.org/article/whats-new-in-emacs-29-1
It’s cool to see eglot included, but it has been easy to use it in older versions of Emacs for as long as it’s existed, since it’s a single file with no dependencies. A lot of people seem excited about tree-sitter and wayland, but those don’t really seem relevant to any of my own personal use cases. The thing I am looking forward to using is seeing what kind of wild hacks people end up doing with the native sqlite support.
Same. I don’t care about Wayland at all (I don’t use Emacs in graphical environments) and I’ll try tree-sitter but I have this nagging feeling it’s over-hyped.
I am also happy about the inclusion of eglot, although it won’t change much for me. I might start using use-package now that it’s not a dependency.
Better long line support seems long overdue. It’s a bit of an embarassement, to be honest.
If you are not using exclusively lisps, then syntax-aware selection (explained, e.g., here https://zed.dev/blog/syntax-aware-editing) is huuuuge. It’s one tiny feature, but for me like 60% of non-trivial edits are funneled through it.
TreeSitter gives you pretty great tools to be able to implement syntax-aware selection, but, if I understand correctly the actual feature isn’t in the core Emacs. The closest thing to what it should be is probably https://github.com/magnars/expand-region.el/pull/279, but that’s an unmerged PR to a third party package. (there are also things like combobulate, but I think they go a bit too far, syntax-aware selection is 80% solution at 10% UX complexity).
Right; that’s the impression I get from tree-sitter mostly; the rest of the world is finally catching up to what we’ve been doing with paredit since *checks comment header of paredit.el* 2005, apparently? =D
I’ve been waiting a long time for this!
The new pipelining in Eshell looks exciting too, since that has been my main shell for years now.
To an outsider like me, it looks like Emacs development sped up in recent years. LSP and Tree-sitter integrations are especially noteworthy. It’s very impressive.
Piggybacking on this thread: what’s the current state of Emacs when it comes to remote development?
I’m aware of TRAMP but what I’m looking for is more complex.
I’d like a remote machine do most of the work (e.g. compilation, debugging, running a binary, code search). At the same time I’d like the text editing experience to not suffer the network latency so I’d like the client to run locally.
What are my options? Do you have any tried workflows?
It depends a lot on the language you are aiming to work with. Some modes have excellent TRAMP support, and if editing remote files they will fire a remote LSP, compiler / interpreter, etc. Others do not provide TRAMP support at all.
If your favorite major mode does not support TRAMP, one possibility is perhaps to use mosh instead of SSH and run the whole emacs remotely. This can reduce the impact of network latency.
That’s neat, I didn’t know that. I will check it out, thank you!
In my case it’s mostly Rust, Python, Go and sometimes C++.
The python-mode that ships with Emacs works really well with TRAMP, i.e. it fires a remote terminal, etc. I think all popular Python packages, such as anaconda-mode, build on top of it. So you are covered in that front.
I have never tried remote development using the other languages you mentioned.
I don’t think there’s one true easy option for that. Tramp is great but it’s possible individual libraries/modes will have buggy support. Editing over ssh is great if you don’t mind that. Honestly with something like the
kittyterminal using emacs over ssh looks great and works for everything except actual inline images (although kitty can display those on it’s own, but emacs doesn’t know how to tell kitty to draw images… yet).The venerable option of X11 forwarding can work, if latency is low.
Another option that I’ve seen recommended is to basically run emacs gtk with an HTML5 renderer and access via web browser. I haven’t tried it but allegedly there’s a PGTK (pure gtk) branch that has been merged somewhere and since GTK has a method to render to HTML5 you can take advantage of that: https://www.reddit.com/r/emacs/comments/rj8k32/the_pgtk_pure_gtk_branch_was_merged/
Personally I’d just go with either kitty ssh or emacs with remote desktop such as chrome remote desktop or nomachine (as I understand it nomachine is basically a proprietary version of X11 forwarding that’s actually usable for non-trivial applications). I use it every day.
I do this every day for work inside tmux+mosh; mosh does a pretty good job of papering over network latency issues to the point where they’re basically undetectable in my experience. But I’m always connecting to a host in the same city as I’m located so if you want to like … cross an ocean or a continent this may not be viable.
Whereas others responding would run Emacs in SSH, I guess I would run SSH either in Emacs (in
ansi-term-mode) or in a separate terminal emulator alongside Emacs and run the compilation (etc.) commands in the SSH session. If you run those commands with key bindings, I imagine the bindings could be changed to send the commands to the SSH session buffer (if running SSH in Emacs), although I personally have not tried to write programmatically into aterm-modebuffer.I really hate GTK font rendering, to the point where, on Linux, I’ve reverted to using the
lucidbranch after the switch to GTK3, but I tried the pgtk engine and it’s really impressive. I don’t really care about Wayland compatibility for now, but on X11 it’s smooth and barely has any latency, which is amazing. The old GTK rendering engine felt pretty clunky, in addition to, you know, giving me awful goose foot wrinkles. There are many other factors contributing to the much smoother feel and to faster operation but, having briefly ventured into Emacs’ rendering innards some time ago, I suspect pgtk’s less contrieved way of doing things played a role.Since I’m gonna have to do Linux development locally for a while, I think I’m going to take the plunge one of these days and try to see if I can get the pgtk engine to show text without giving me headaches. That would be really cool because
lucidwidgets is not something anyone should be using in 2023.I’m pretty sure GTK doesn’t do font rendering itself, but uses FreeType and harfbuzz like everything else. My guess is that you have those configured the way you want them through XResources, which GTK is ignoring. If that’s the case, and you’re not using gnome-settings-daemon (or similar?), you need to edit ~/.config/gtk-3.0/settings.ini, and change the settings for gtk-xft-antialias, gtk-xft-hinting, gtk-xft-hintstyle, and gtk-xft-rgba to the values you like.
It’s a lot messier than that. I do actually have the gtk-3.0/settings.ini magic set but IIRC some of that also gets ignored under some circumstances (e.g. on Wayland) and is obtained via gsettings. I obviously have the gsettings magic configured, too, not that it helps everywhere – for instance WebKitGtk uses another text rendering path. GTK also seems to ignore my configuration for stem darkening, or I’m not chanting it in the right place, and some applications further override some of the font configuration (e.g. VS Code). This is why my secret Linux productivity hack is to ssh into linux boxes from macOS, this is completely ridiculous.
They say about pgtk that
(I just use lucid, not sure what I’m missing out on, but can’t say I’ve noticed anything weird with fonts.)
In case somebody else wonders about it like I did, the default homebrew packages for emacs don’t have the option of turning on native-compilation. https://github.com/d12frosted/homebrew-emacs-plus does, but it’s not yet updated to 29.1.