Using Emacs as a TUI | Hacker News Reader

Using Emacs as a TUI

blog.natfu.be

63 pointsNeutralForest26 comments

In the related news, master branch of Emacs now supports child frames in the terminal https://yhetil.org/emacs-devel/m2h694lp7s.fsf@gmail.com, hopefully available in the next stable release.

That means we can have floating autocomplete menus, notification boxes, dialog-like interactions - all interesting possibilities that we've had in the GUI for a long time.

I didn't know about kkp package. Need to try it out - especially on MacOS there are still performance issues (that I work on) so having workable terminal with all the keybinds available would be helpful.

By the way, recently Kitty introduced variable sized text, which probably could be integrated in Emacs, too, to have my favorite feature - font resize per frame :)

I can highly recommend KKP. It works very well in Kitty, and it even lets you map super keybindings, swap modifier keys, etc. I also used it on MacOS to get a low-latency frame on big hiDPI screens where the Cocoa GUI becomes quite unusable.

It also works fine in many other terminals like iTerm2 and Ghostty. Last I tried, they don’t report Super though.

You might not want to have vendor lock-in on a terminal with opt-out telemetry.

https://github.com/kovidgoyal/kitty/issues/3802

What exactly do you mean by 'telemetry'? A simple check for updates? Which can be opted out of? Reading the comments of the author there, this seems to be a big nothingburger.

Kitty phones home, providing information to the server. His insistence to keep this opt-out instead of opt-in, and abrasiveness towards whoever points this antifeature of Kitty out makes it all the more suspicious for me.

https://github.com/kovidgoyal/kitty/pull/3544

There are other terminal emulators, implementing the kitty graphics protocol. So your vendor lock in concern is moot, since there is more than a single vendor.

This is off topic flame bait.

Yes, that is a concern, but this is a post about Emacs as a TUI, and sidetracking it to discuss a hot topic about another piece of software is concern trolling.

Split the screen: c-x 2, 2nd window in shell-mode with M-x shell, everything is fine. Am i missing something here?

This article is mostly about using emacs -nw which will depend on a bunch of things like how terminal input is handled! With regular Emacs, as a GUI, I typically split as well but I prefer vterm over M-x shell.

I usually use `emacsclient -nw` inside a terminal (sometimes over mosh). I've found eat[1] to be much a better than vterm at being a terminal emulator inside Emacs (inside a terminal). It flickers less, and seems to handle key forwarding a lot better. The only downside is it's slightly slower than vterm at handling a large chunk of data (e.g. cat an access log).

[1]: https://codeberg.org/akib/emacs-eat

Sorry for the tangent: I was very eager to try vterm until I read that people have had issues with evil-mode [1]. Any idea whether eat and evil can get along?

[1] https://github.com/akermu/emacs-libvterm/issues/313

It works somewhat more reliable (I've found vterm to break in some interesting ways depending on your cursor position even with evil-collection), but it's pretty awkward to use with evil, at least without any configuration.

For example, pressing 0 to go to beginning of line goes to before the $PS1, rather than the input beginning, going from NORMAL → INSERT inserts text at the end instead of at the cursor, Emacs motion keys doesn't work, etc. I think if I take some time to remap the key it might work, but usually I just switch to Emacs mode or just restrict myself to use only cursor key to navigate.

I usually use emacs-nox when running inside of a terminal. Not sure on how it's related exactly to emacs -nw. I do know it's a separate binary, so infer from that what you will.

Emacs defaults to a GUI if available. The -nw toggle switches it off even when available, while -nox compiles without GUI support so it’s never available.

There are some minor differences. For example, I believe -nw can still use the X support to access the GUI clipboard, while -nox requires enabling e.g. OSC-52 support to do the same.

It genuinely never ocurred to me that you use emacs somewhere outside the terminal.

There are dozens of us running it outside of a terminal. Dozens!

I have used it between 1995 and somewhere around 2006, always as graphical application, and for a while mostly XEmacs, which had much better graphical features.

Using it on the terminal only over telnet when a remote X session wasn't possible.

Using it in GUI mode, you’ll end up using the terminal inside Emacs!

And there's EXWM if you want to keep going. I guess people have also tried to set emacs as their init process.

Yup: https://github.com/a-schaefers/systemE

Well there's the GUI version. vim also have it.

My main interaction is from the GUI where I just leave it open for days at a time. So this article stems from some of the frustrations I had using it in the terminal and not finding the same behavior I was used to.

It's quite nice for the following reasons:

- Image previews (for file management with dired/dirvish)

- PDF viewing

- In-buffer images (e.g. profile pictures in git log with Magit)

- Browsing simple HTML pages (e.g. API docs)

There's probably more I've yet to discover.

M-X calc and/or imaxima with embedded Gnuplot generated plots.

I genuinely never understood running Emacs in terminal, instead running terminal in GUI Emacs. That, until a day I joined a team where most development happens on remote EC2s, where people create joined tmux sessions.

Besides, it turns out, setting up emacslient for quick editing, or even for bringing up Dired to use as a directory lookup and switcher is also very nice.

Reply on news.ycombinator.com