Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rahuljuliato.com

Post reply on HN
Print view View original

211–220 of 294 posts

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

#211

Post by ralphc »

rdtsc wrote: post #195
mesrik wrote: post #75

"Is anyone still using emacs?" Yes, 34 years and no plans to switch. Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CL…

> Yes, 34 years and no plans to switch. It's 26 years for me. Emacs is I believe the oldest software I still use. I started on an SGI Irix in 2000. I used it also on HP-UX, Solaris, Windows, MacOS, and of course all varieties of Linux > Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. And many keystrokes work on MacOS, too. That…

One advantage of vi is that even though emacs is available on all those systems, vi is actually installed on all of those, setting aside windows. If you know rudimentary vi you can walk up to any of those machines and edit a configuration file well enough to work.

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

#212

Post by scoops_ »

mediumsmart wrote: post #95

30.2 is as far as I am willing to go. Happy travels.

I’m curious as to why - is it a matter of stability/feature completeness in 30.2 that you don’t need or want to bother with new releases? Or that you don’t like the direction of the project past that point?

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

#213

Post by bananamogul »

wafflemaker wrote: post #178
francoisdevlin wrote: post #126

Earlier quoted context omitted.

I use vi because I'm not a savage

If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!

"If emacs is not installed on a system, I use sed."

Bill Joy (creator of vi) once said that if he sits down on a foreign system, he reaches for ed [1].

To be fair, both emacs and vi have "magic exit incantations", though if you have emacs perhaps you have a menu in GUI mode. If not, C-x C-c is really not any more memorable than :wq! The vi one at least has an obvious mnemonic ("write quit") but either way, you need to know an arbitrary sequence of keystrokes.

[1] http://xahlee.info/comp/interview_with_bill_joy.html

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

#214

Post by kstrauser »

DonHopkins wrote: post #204
kstrauser wrote: post #134

Earlier quoted context omitted.

I came into that after sendmail.m4 got popular. I'm not sure if that's better or worse.

m4 is what makes Gnu Autotools so delightful!

Look, gang! A brand new sentence!

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

#215

Post by setopt »

hollerith wrote: post #174
mesrik wrote: post #75

"Is anyone still using emacs?" Yes, 34 years and no plans to switch. Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CL…

Emacs keystrokes don't work in the textarea I'm using to write this comment in Google Chrome. Specifically none of these do anything like what they do in Emacs: C-a, C-e, C-n, C-p, C-f and C-b. This is on Linux, but ISTR finding the same state of affairs on MacOS many years ago during some previous iteration of this conversation. They also don't work in VSCode.

Those keybindings work on MacOS for me, but not on Linux (by default).

There is a way to enable Emacs keybindings in all GTK apps on Linux, but it’s quite buggy in practice (many apps define keybindings that override or conflict with these), and I believe the feature is officially deprecated.

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

#216

Post by hollerith »

setopt wrote: post #215
hollerith wrote: post #174

Earlier quoted context omitted.

Emacs keystrokes don't work in the textarea I'm using to write this comment in Google Chrome. Specifically none of these do anything like what they do in Emacs: C-a, C-e, C-n, C-p, C-f and C-b. This is on Linux, but ISTR finding the same state of affairs on MacOS many years ago during some previous iteration of this conversation. They also don't work in VSCode.

Those keybindings work on MacOS for me, but not on Linux (by default). There is a way to enable Emacs keybindings in all GTK apps on Linux, but it’s quite buggy in practice (many apps define keybindings that override or conflict with these), and I believe the feature is officially deprecated.

"On MacOS" is not specific enough. Do they work in a textarea in Google Chrome on MacOS?

In vscode on MacOS?

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

#217

Post by dakra »

baokaola wrote: post #64
kccqzy wrote: post #55

Earlier quoted context omitted.

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…

Just to expand a bit on "bunch of other things". You can see a vterm vs eat feature comparison here: https://dakra.github.io/ghostel/#ghostel-vs-vterm

Besides the performance and what baokaola already mentioned some things that make Ghostel better than vterm especially when working with those cli agents are:

- proper handling of resizing windows

- progress reports (you get a spinner in the modeline when claude thinks)

- notifications (get an alert when your agent is done)

- drag and drop works

- hyperlinks. urls and files are clickable

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

#218

Post by dakra »

aeonik wrote: post #202
DonHopkins wrote: post #65

Earlier quoted context omitted.

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 conservativ…

Lol this looks like a wonderful coincidence. I thought it was named Ghostel because of Ghostty and EL (emacs lisp).

> I thought it was named Ghostel because of Ghostty and EL (emacs lisp).

It was. But I like the Postels law relation as well :)

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

#219

Post by themafia »

> If you've ever built a three-window layout and then wished the editor pane were on the other side, these do the job and keep every buffer in place while they're at it.

I built a tmux like buffer manager. So I can just pick a window, press Alt-F#, and switch that pane over to whatever buffer I want. It's super easy to even display the same buffer twice but in different panes.

If you're using one without the other you're going to have a bad time.

If I want to change layouts I just close panes down to one and then open it up in the configuration I like. Then I just switch to each pane and Alt-F# the correct content into it.

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

#220

Post by TacticalCoder »

mftb wrote: post #148
mesrik wrote: post #127

Earlier quoted context omitted.

Yes, emacs keystrokes became kind of cli lingua franca, which apparently many do not know. I don't remember my self ever read about those supported explicitly anywhere, but accidentally I found out long time ago and then whenever I try new systems, programs and whatever I try which keystrokes do work. Quite often at least some work.

It's GNU Readline[0] or similar. It's all over the place, on Linux at least. Being GNU it defaults to emacs, but the vi support is also excellent. The first thing I type in any foreign bash is 'set -o vi'. [0] - https://en.wikipedia.org/wiki/GNU_Readline

Yes it's GNU readline, but note that the very Wikipedia link you gave explains that it's GNU readline that re-used those shortcuts from Emacs, not the other way round.

So it's not wrong to call these "Emacs" shortcuts.

Post reply on HN