Comment by gumby | Hacker News Reader

Comment by gumby | Hacker News Reader

Parent Full thread

I don't know why the author doesn't simply open a shell buffer in emacs, but that's their business.

Piece of fun trivia: EMACS used to have a mode for use on a printing terminal. It worked, as long as you had an idea of what your file looked like, same as any other non-visual editor (like ed before a display mode was grafted onto it to form vi). Of course this was as crazy as using vi on a printing terminal, since EMACS started out as an easier way to use TECO after a visual mode had been added to that. I guess the printing mode was worth it for EMACS users who never learned TECO.

More usefully it had a "slow terminal" mode. Printing terminals were slow, but many people connected to computers at 300 baud or even slower! So in slow terminal mode you could use the full display power of EMACS but it was very selective about how it updated your display. Back then most terminals had very limited cursor control, and you couldn't always change an arbitrary character. Still, avoiding a full screen repaint at 110 baud was a win.

I doubt either of these modes survived the relatively recent (1980s) ports of emacs (as it is now known) to C/Lisp. But a special line for single-line editing through an emacsclient could be a win in this case.

From the Emacs manual:

Searching incrementally on slow terminals, such as displays connected to remote machines over slow connection, could be annoying due to the need to redraw large portions of the display as the search proceeds. Emacs provides a special display mode for slow terminals, whereby search pops up a separate small window and displays the text surrounding the match in that window.

— <https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...>

Nice! That a bit more advanced: old school EMACS used the line below the mode line because some old terminals supported update only there and not always elsewhere.

personally I don't use shell buffer because it doesn't do command line recall like I expect.

In a normal terminal control-r <characters> recalls the last command with those keys, and control-p/n will go back/forward in the history.

with the shell buffer I move upwards in the buffer to recall a command.

(is there a way to configure this differently?)

EDIT: ok it seems like meta-r and meta-p/n do the same thing - kind of.

hmmm, but meta-r doesn't seem to recall from the shell history? It is either a different history or truncated.

You can use m-p/n as you mention, same as, say, in regular bash, or search. Or c-c c-p, c-c c-o etc.

But TBH I mostly just use the ordinary ! syntax (e.g. `!!` or `!bla:*` or !200 etc) because it’s even faster and works fine even when no editing is available at all.

So if I used find to search for an executable it’s just so effortless to type ./`!!|head -1` rather than searching up, selecting and copying a region, going back to the end, editing it, blah blah. Or even worse, reaching for the mouse.

I wonder what percentage of even frequent shell users are even aware of !! or ^subst^ - an informal polling of 5 workmates here (engineers, command line git users, people I would have thought would know) shows no takers.

To be fair, I'm old and was thrilled to go from 300 to 1200 baud at one point.

I recall that at University a lecturer showed this briefly in the early nineties. Most of us students stared in a mixture of awe and disbelief. I didn't learn those incantation from that brief introduction and never felt the need, even though I used a 2400 baud modem (already outdated, hence cheap) then.

Wow, I assumed it was universal. Retyping things, or copying and editing is so tedious.

I use control-r a LOT. It lets you look at and edit what you'll re-type. I use it for complicated commands I ran yesterday and the day before.

Unfortunately my hands are wired for control-r (caps lock = ctrl) and not meta-r.

Hard to figure out the ROI of re-learning.

(still emacs recall history doesn't seem to reflect bash history, which I routinely set to 10k commands)

FYI, I use vterm with a few custom keys so that it operates exactly as if it were just a standard terminal emulator.

Why bother? Real question — seems like no advantage over a terminal window, except you can c-x b to it. Perhaps that's enough?

Ummm. It probably depends on the kind of work you do in the terminal but for me it was a game changer. Being able to pull in any of the text from a terminal into a buffer, easily, without copy paste or mouse is a massive game changer for the type of work I do. I can operate on any of the text in the terminal the same way I would emacs, and pull it into a code buffer. Selectively pulling in random long directory paths, etc etc. I can also drop anything from notes or code into a terminal without needing to dance around.

It also turns emacs (server-mode) into a really great replacement for tmux/screen. tmux behaves very strangely in how it instantiates the very first window, calling the process after that window and killing that window can kill all your tmux sessions. I run emacs as a daemon on my HPC clusters and have it monitor jobs and more via vterm.

Yeah, I guess my use case is completely different; shell mode is great and vterm goes the wrong way. But I never run even curses programs in the terminal, just text all the way.

The great thing about emacs is you can use what works for you!

Reply on news.ycombinator.com