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...
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.
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.
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.
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.
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...
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.
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.
Readit News
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...
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
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.
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.
https://youtu.be/V1mnDK_tuAs?t=1097
[1] https://sourceforge.net/projects/android-ports-for-gnu-emacs...
Nowadays no idea, I even lost track if Emacs finally does everything that was special about XEmacs, 30 years ago.