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?
Emacs 31 is around the corner: The changes I'm daily driving
61–70 of 294 posts
Re: Emacs 31 is around the corner: The changes I'm daily driving
#62Earlier 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…
Re: Emacs 31 is around the corner: The changes I'm daily driving
#63I'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…
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
#64Earlier 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 :)
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
#65Earlier 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?
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
#66I 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.
Re: Emacs 31 is around the corner: The changes I'm daily driving
#67I 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
Re: Emacs 31 is around the corner: The changes I'm daily driving
#68Earlier 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
Re: Emacs 31 is around the corner: The changes I'm daily driving
#69I 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.
Re: Emacs 31 is around the corner: The changes I'm daily driving
#70This 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/
2. Remove MELPA packages that are now part of Emacs
3. Go to step 1 when new version comes out