What's New in Emacs 30.1? | Hacker News Reader

What's New in Emacs 30.1?

masteringemacs.org

158 pointstrocado36 comments

Fun to see someone decide to just write a faster JSON parser because they believed it was possible. They mentioned last year that libjansson had some intermediate layer with Emacs, which led to too many memory allocations: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...

Also, the developer who wrote the parser (Géza Herman) was able to pass all of the tests with strange edge cases from https://seriot.ch/projects/parsing_json.html very quickly: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...

Thanks for linking to that thread. Was fun to peruse it reading the feedback and seeing how things went there. Huge kudos to Géza Herman for getting this in. Similar kudos to the the team on the review! Genuinely pleasant to read how that whole process went.

With Emacs 30 I've stopped compiling from the master branch, preferring the tagged releases.

    GNU Emacs 30.0.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2024-12-03

It seems that most of the features I was eager to try from the master branch at various times (starting from native comp, then tree-sitter, use-package (although I've started using elpaca instead), modus themes, transient, etc.) have been merged. A lot of great features have been added to Emacs in recent years. Kudos to the maintainers!

Using your thread to ask: What recommendations do people have for a build that's best for heavy org-mode use? Of all emacsen which is the best drive for Org?

I don't have any specific build-time recommendations for org-mode, but I can wholeheartedly recommend the built-in 'leuven' theme for org-mode work. I normally don't go in for light themes, but this one has so many nice little touches to spruce up org-mode elements I find myself switching to it from my usual dark doom or modus themes when working on org-mode projects.

thanks spulyo

As a longtime Vim user, I’ve got to say, the "completion-preview-mode" caught my eye. It’s pretty cool how Emacs is tossing in this slick, built-in predictive typing thing—kinda like Company or Corfu, but using its own minibuffer magic. Honestly, it’s a chill move that keeps things smooth without overcomplicating the vibe. Emacs just keeps doing its thing, polishing the edges while staying true to its hardcore, customizable soul—gotta respect that, even if I’m still Team Vim.

Look mate, as far as I'm concerned the old editor wars fizzled out a long time ago. Now it's us in the emacs and vim camps vs. the IntelliJs and VS Codes of the world.

I can't disagree with that too much, although I have a very special place in my heart for the Intellij's of the world.

A note on one of the changes: "New package EditorConfig. This package provides support for the EditorConfig standard..."

Honestly the only reason to use this, and don't get me wrong, it's a huge reason, is to ensure windows users don't add CRLFs in their commits, and mess up diffs. Set `end_of_line = lf` and you're done.

`charset = utf-8` and `trim_trailing_whitespace = true` are also nice, but not as disruptive as `end_of_line`.

The other (indentation related) functionality should honestly be handled by language specific linters instead, as they can be syntax aware and allow for better control. I always disable those in practice.

This is the CLI tool to use during CI: https://github.com/editorconfig-checker/editorconfig-checker

Merely as an observation, if you care about crlf in _commits_, then you almost certainly want https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura... and not that cited EditorConfig setting. The reason is that while on a system that _uses_ crlf if you were to open those lf-only files in any text editor, it'll run the lines together into a jumble

> The reason is that while on a system that _uses_ crlf if you were to open those lf-only files in any text editor, it'll run the lines together into a jumble

This isn’t true. Windows is the only major contemporary platform to use CRLF, and nowadays all major Windows text editors, especially those likely to be used by developers, can read files with LF-only line endings without jumbling all the lines together. 20 years ago, it was a different story, but that was then and this is now.

> Which-key is now built in, which is good news for people who prefer that method of help (as opposed to typing C-h in a key chord).

Insane improvement. It's been years since I left Emacs, but which-key-style interfaces are the single feature I try to add everywhere. We need more of them, they are an easy UX-profit.

Here's a demo of how completion preview mode works

https://youtu.be/V1mnDK_tuAs?t=1097

So the Android work has been merged? Does this mean anything for Hu Jianwei's builds (of Emacs and Termux) at [1]? Having them in an obscure SourceForge repo seems less than optimal; getting Obtainium to understand the repo structure was not super fun...

[1] https://sourceforge.net/projects/android-ports-for-gnu-emacs...

I believe that he (which is who ported Emacs to Android) will keep uploading nightly builds in there. The stable Emacs 30.1 release will shortly be available in both the GNU FTP server and F-Droid

Emacs just keeps getting better and better. Never really understood the motivation to fork or rewrite it. It's one of the best free projects out there.

Back in the XEmacs days, when I cared about it, graphical widgets, better extension points, and not so religious against usability features as Emacs understand the stewardship from the mighty Stallman.

Nowadays no idea, I even lost track if Emacs finally does everything that was special about XEmacs, 30 years ago.

XEmacs has been out of maintenance for frickin' years, because GNU Emacs caught up back in the 2000s or so. If GNU Emacs is still missing in some ways, XEmacs is "not better enough" to justify a switch for the vast majority of users of Emacsen.

Missed the remark about 30 years ago? Of course it is out of maintenance for frickin' years.

The question was more did GNU Emacs caught up, or did the folks that cared about XEmacs moved into better pastures?

(X)Emacs was relevant to me, because there was still no IDE culture in UNIX land back then, like on PC and Amiga, and between vi and (X)Emacs (vim was yet to be a thing) definitly (X)Emacs, when UNIX IDEs finally became mature enough, I moved on.

If it is installed, I will use it, but won't go out of my way to use it daily as back then.

Not quite following. You’re saying there used to be a motive to use forks, because Emacs proper wasn’t healthy? At this point, standard GNU Emacs is about as good as it gets in my book, plus the package library is of very high quality compared to the other editor stacks out there. People just don’t get into writing emacs packages if they’re not in the 1% of the 1% of developers in the first place. Almost zero slop.

Yes, lets say Guile never really makes as an Elisp replacement, that would be another case, although apparently Guile-Emacs effort was relaunched, lets see.

30 years ago it was another matter, Emacs culture back then was pretty much against the cool features from XEmacs, a bit like GCC versus what made clang exist in first place, in terms of how Stalman would vouch against such features.

In any case, the 1% remark is quite relevant given how many still reach out to Emacs in modern times.

What made Clang exist, and become successful, was having a massive corporate backer and a nonfree license.

> The Org URI protocol should now register automatically, meaning you can send data from a browser bookmarklet straight into org capture in your running Emacs instance.

Is there any risk of a website including a link using the Org URI scheme to load malware into your Emacs this way?

See: https://news.ycombinator.com/item?id=40768225

That one is fixed, though.

>Native compilation is now enabled by default.

And it shows. Now emacs is much nicer to use on Windows. Big thanks to the developers!

You probably still want to exclude Emacs directories from Windows Defender. That speed boost is massive.

On NetBSD and OpenBSD, using emacs 29.4 I need to use gtk2 version. gtk3 will freeze X for a period of time, rarely forever when I try and use the menus.

Hoping that was fixed with this version :) But my guess the issue lies with gtk3, the NetBSD people had said in some cases gtk3 acts odd.

OpenBSD has the gtk2 compiled package, but on NetBSD I need to compile emacs/gtk2 myself via pkgsrc.

Outside of that all works great and waiting for 30.x to show up in packages. Congratulations.

The gtk maintainers ran out of fucks to give for anyone except Linux/Wayland users years ago. Honestly, emacs-lucid is the smoothest most stable experience if you're still on X11.

Forget smoothness, it's the only one that doesn't have broken input with odd key chords

Sadly emacs-lucid does not exist in OpenBSD or nor NetBSD. But I expect compiling it myself would not be that difficult.

I hate having to build stuff myself, but I must say that Emacs is pretty easy to compile

30.1 on Ubuntu feels much better for C++ development on a remote server via lsp-mode's clangd-tramp compared to 29.3. I suppose that's thanks to the faster JSON parser?

Very cool but sticking with 29.2 sans native compilation, treesitter, org - I don't understand preview autocompletion even after watching the video - is that really useful?

I wish that websites would stop using "justified" text layouts. It reads particularly awful on mobile,and is hard to read in general.

Since this is basically just publicity for his book, see also https://www.emacswiki.org/emacs/EmacsThirtyHighlights, especially if want to skip over low-quality non-comments like "Info mode is Emacs’s implementation of the TexInfo hypertext viewer" or "Programming mode for Ruby".

Reply on news.ycombinator.com