The native Haiku GUI support is especially cool because, for once, it was not developed by one of the “usual suspects” among the Haiku community and then later upstreamed (if at all – many projects are reluctant or even hostile to accepting Haiku support, and so it’s unfortunately often our habit to not even try), as basically all other ports of major applications have been so far, including Qt, LibreOffice, gVim, etc., but was written by an Emacs developer and was upstream from the start.
if at all – many projects are reluctant or even hostile to accepting Haiku support, and so it’s unfortunately often our habit to not even try
We took Haiku patches in snmalloc. The Haiku VM subsystem is sufficiently different from everything else that we support that we’ve caught at least one bug because someone on Haiku could reproduce it reliably but for everyone else it was a rare and intermittent crash.
I doubt I’ll ever use Haiku (in spite of my fondness for BeOS 5), but I see Haiku support as evidence of code quality in a project. It means that you have clean enough platform abstractions that the cost of supporting a niche platform is small (our Haiku-specific code is tiny), which tends to be a good proxy for whether you have well-thought-out abstractions in your code. The number of projects that I’ve seen recently that have Mac and Linux support, but struggle with something like FreeBSD (which is basically like Linux or like macOS in every category that userspace software would care about), let alone something a bit more different like Haiku, is depressing. When I started working on F/OSS things, running on multiple platforms was a source of pride for projects, the more obscure the better. That made it very easy to adapt code to new and interesting scenarios (want to run in the browser with asm.js? On a cloud service with WASI? On a microcontroller? On a mainframe? It’s just another platform and you already have the right abstractions), now we’re increasingly locked in to a Linux monoculture.
I just got beta4 up and running on my “weird OS” machine (a gently-upgraded Thinkpad T440p) and…it’s actually really good. WiFi, the Nvidia graphics chip, sound, all of it just worked out of the box. (Now, getting a bootable root disk took a fair bit of back-and-forth with the installer, partition tool, etc.; the install app doesn’t really seem to be able to tell what configurations of disk layout, boot loader, etc. are actually going to be bootable, so unless you get it right off the bat for your particular hardware there’s some potential fiddling involved.)
For me that’s shaping up to be the most important Emacs release in the past 10 years. LSP, tree-sitter, Wayland (the pgtk port) - it’s amazing how much progress the community’s making these days!
It’s been fun to be an emacs user for the last few years! I’m quite excited for what the ecosystem looks like in a year, with tree-sitter and eglot in core and dependable.
Super exited with the changes! The community is pretty aggressive in bringing new things before final cut. This is rarely seen in projects with such long history. It’s still young and super active!
emacs 29 was the version on the master branch, but is now on a separate branch, being tested and prepared for release.
emacs 30 is the continuation of the master branch with the new version number.
No new features to emac 29, only bug fixes, although it’s rumoured there may be some leeway due to tree sitter.
So emacs 30 will have new features and become the - relatively - less stable, cutting edge version, while 29 is tested and fixed as needed before release.
29 on master was surprisingly stable, and I suspect 30 will probably be reasonably stable too.
Hmm, I wonder what the tree-sitter integration looks like. The post says it only supports 7 languages, which is strange - by nature tree-sitter grammars all have the same API, so adding support for another language should be as easy as including the query files. Tree-sitter grammars can also be quite large (a few megabytes each when compiled, 10s of megabytes from source) so I wonder what packaging approach they will take here.
That’s just the modules that there’s a script to generate in the tree. I was playing around with it yesterday; looks like one just needs to wrap the generated grammar in an emacs module and add it to a path that the tree-sitter package will look in.
EDIT: plus the emacs mode to wrap the module would be needed - currently there’s no generic “treesitter mode” for any language, so all the listed modes still have to have some emacs lisp glue to define the mode and load the corresponding grammar module.
The native Haiku GUI support is especially cool because, for once, it was not developed by one of the “usual suspects” among the Haiku community and then later upstreamed (if at all – many projects are reluctant or even hostile to accepting Haiku support, and so it’s unfortunately often our habit to not even try), as basically all other ports of major applications have been so far, including Qt, LibreOffice, gVim, etc., but was written by an Emacs developer and was upstream from the start.
We took Haiku patches in snmalloc. The Haiku VM subsystem is sufficiently different from everything else that we support that we’ve caught at least one bug because someone on Haiku could reproduce it reliably but for everyone else it was a rare and intermittent crash.
I doubt I’ll ever use Haiku (in spite of my fondness for BeOS 5), but I see Haiku support as evidence of code quality in a project. It means that you have clean enough platform abstractions that the cost of supporting a niche platform is small (our Haiku-specific code is tiny), which tends to be a good proxy for whether you have well-thought-out abstractions in your code. The number of projects that I’ve seen recently that have Mac and Linux support, but struggle with something like FreeBSD (which is basically like Linux or like macOS in every category that userspace software would care about), let alone something a bit more different like Haiku, is depressing. When I started working on F/OSS things, running on multiple platforms was a source of pride for projects, the more obscure the better. That made it very easy to adapt code to new and interesting scenarios (want to run in the browser with asm.js? On a cloud service with WASI? On a microcontroller? On a mainframe? It’s just another platform and you already have the right abstractions), now we’re increasingly locked in to a Linux monoculture.
if any piece of software would have upstream support for an obscure system would be Emacs, which in the year 2022 has an upstream-maintained port for DOS: https://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dDOS.html
This is making it VERY HARD for me not to grab an old computer and put Haiku on it, dammit.
I just got beta4 up and running on my “weird OS” machine (a gently-upgraded Thinkpad T440p) and…it’s actually really good. WiFi, the Nvidia graphics chip, sound, all of it just worked out of the box. (Now, getting a bootable root disk took a fair bit of back-and-forth with the installer, partition tool, etc.; the install app doesn’t really seem to be able to tell what configurations of disk layout, boot loader, etc. are actually going to be bootable, so unless you get it right off the bat for your particular hardware there’s some potential fiddling involved.)
If you have a previous beta up on a spare PC/VM/whatever, it’s pretty easy to upgrade in-place: https://www.haiku-os.org/guides/daily-tasks/updating-system
Just swap out the release name from
r1beta3tor1beta4, sync, and let ’er rip.I wonder which version will end up in HaikuDepot, the one with native GUI support or the terminal one.
Both, and it’s already been there for some months now.
For me that’s shaping up to be the most important Emacs release in the past 10 years. LSP, tree-sitter, Wayland (the pgtk port) - it’s amazing how much progress the community’s making these days!
It’s been fun to be an emacs user for the last few years! I’m quite excited for what the ecosystem looks like in a year, with tree-sitter and eglot in core and dependable.
Super exited with the changes! The community is pretty aggressive in bringing new things before final cut. This is rarely seen in projects with such long history. It’s still young and super active!
I’ve been using this for a while. I emacs 30 usable?
emacs 29 was the version on the master branch, but is now on a separate branch, being tested and prepared for release.
emacs 30 is the continuation of the master branch with the new version number.
No new features to emac 29, only bug fixes, although it’s rumoured there may be some leeway due to tree sitter.
So emacs 30 will have new features and become the - relatively - less stable, cutting edge version, while 29 is tested and fixed as needed before release.
29 on master was surprisingly stable, and I suspect 30 will probably be reasonably stable too.
Hmm, I wonder what the tree-sitter integration looks like. The post says it only supports 7 languages, which is strange - by nature tree-sitter grammars all have the same API, so adding support for another language should be as easy as including the query files. Tree-sitter grammars can also be quite large (a few megabytes each when compiled, 10s of megabytes from source) so I wonder what packaging approach they will take here.
That’s just the modules that there’s a script to generate in the tree. I was playing around with it yesterday; looks like one just needs to wrap the generated grammar in an emacs module and add it to a path that the tree-sitter package will look in.
EDIT: plus the emacs mode to wrap the module would be needed - currently there’s no generic “treesitter mode” for any language, so all the listed modes still have to have some emacs lisp glue to define the mode and load the corresponding grammar module.