Live data from Hacker News

Emacs 31 is around the corner: The changes I'm daily driving

rahuljuliato.com

61–70 of 294 posts

Re: Emacs 31 is around the corner: The changes I'm daily driving

#61

Earlier quoted context omitted.

> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel ( https://github.com/dakra/ghostel ) if you aren't already. And if you are, you should report bugs so we can fix them :)

Is it conservative in what it sends, and liberal in what it accepts?

Can you elaborate a bit on what you are asking about?

Re: Emacs 31 is around the corner: The changes I'm daily driving

#62
post #8

Earlier quoted context omitted.

I've only ever used emacs in vim mode (evil-mode). Its vim emulation is the best I've seen anywhere.

It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's. UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip ba…

I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#63
post #7

I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesi…

> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point

First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).

VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.

The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#64
post #55

Earlier quoted context omitted.

> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel ( https://github.com/dakra/ghostel ) if you aren't already. And if you are, you should report bugs so we can fix them :)

I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)

Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.

Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.

Plus a bunch of other things!

Re: Emacs 31 is around the corner: The changes I'm daily driving

#65

Earlier quoted context omitted.

Is it conservative in what it sends, and liberal in what it accepts?

Can you elaborate a bit on what you are asking about?

The name Ghostel sounds like a tribute to the Ghost of John Postel, whose law is a good thing for a terminal emulator to respect:

https://lawsofux.com/postels-law/

https://en.wikipedia.org/wiki/Robustness_principle

>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]

>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#66
post #57

I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.

Emacs is more than a dev environment for coders. Some of us here use it for everything that can possibly be represented in text form: our TODO lists, our calendar, our RSS reader, our mail reader, etc. Me, I even maintain billing spreadsheets for a side business as Org-Mode tables. New features in the latest Emacs releases, and in successive releases of individual packages, have brought some nice improvements in those areas.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#67
post #12

I realize I've missed a lot. Someone should write an Emacs guide for people who haven't meaningfully touched their .emacs since the early 2000s

The bulk of the Mastering Emacs blog is a decade old at this point, but its philosophy and the information it provides is still very relevant for any graybeard wanting to get up to date.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#68
post #5

Earlier quoted context omitted.

The two complaints I hear is: 1.Memorizing how to use it has a big learning curve. 2.Wrist pain from pressing button combinations all the time. Otherwise plenty of people still use it and it's great. Just hard to pick up for new users.

being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example

Don't use your pinkie or any finger. Use the meat of your hand to hit the control key.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#69
post #57

I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.

In 2026 I'm using the editor less and using magit a lot more. IOW, emacs has become more indispensable, not less.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#70

This stuff all looks great, I can't wait to upgrade to 31 and then forget about all of it and just keep using Emacs the same way I have been for the past 20 years, /again/

1. Upgrade to Emacs version +1

2. Remove MELPA packages that are now part of Emacs

3. Go to step 1 when new version comes out

Post reply on HN