Your terminal manipulation/navigation setups

12 points by nocoffei

Dear Lobste.rs, over a year after my previous post on mouse free setups, your advice was instrumental to building the tech stack I use today as a disabled person, composed of the Svalboard, Talon Voice, and a fair few extensions for Talon (including ones I've written myself.)

One aspect of my work and personal life that has remained stubbornly able-bodied has been, surprisingly, my terminal use. Reading, manipulating, and editing the terminal has required keyboard and mouse use at every step:

When reading the terminal, scrolling is a must, which demands the use of a physical scrolling device, one of my most consistently difficult actions.
When writing a terminal command, things can range from easy to brutal. Talon has a lot of built in terminal commands available, but composing complex commands still requires a great deal of typing. The most irritating aspect to me is editing a previous command, which consists of either holding (Ctrl+) an arrow key and waiting until I hit the right character, often overshooting, and then having to go back the opposite direction with the arrow keys again, OR moving with my mouse and clicking on the correct position.
When manipulating the terminal, this usually winds up boiling down to copy and pasting text from the output. This is universally a fine grained mouse movement to highlight and copy the correct text, often to paste it into the same terminal.
Too often I find myself combining the second and third actions, which means a lot of arrow key or mouse movement to get to the position in my command, mouse movement to copy and paste text, and then rinsing and repeating a handful of times.

I am fairly convinced there is no true voice first terminal experience-- this is something I am hoping to change. In order to accomplish this and maybe make my life easier, I want to know the landscape of how various people interact with their terminals in 2026. I feel like my approach is deeply inefficient and must be missing something obvious...? We've had terminals since before mice existed, surely there are better ways.

emallson

When writing a terminal command, things can range from easy to brutal. Talon has a lot of built in terminal commands available, but composing complex commands still requires a great deal of typing. The most irritating aspect to me is editing a previous command, which consists of either holding (Ctrl+) an arrow key and waiting until I hit the right character, often overshooting, and then having to go back the opposite direction with the arrow keys again, OR moving with my mouse and clicking on the correct position.

is the problem the shell/terminal itself lacking editor a11y features? or the syntax/structure of the shell commands? if it is an editor problem, does your shell support "open command in editor"? i know fish and bash (via C-x C-e by default) do, which might let you take greater advantage of your other tools.

geocar

The most irritating aspect to me is editing a previous command,

Friend, let me tell you about the fc command. fc -l lists the last few commands. fc and a number edits that command in your favorite $EDITOR and then when you save/exit it runs it!

dtgriscom

What does fc stand for? Or, how do I remember to use fc when it would be useful?
- novedevo
  
  From man fc (emphasis mine):
  
  In the KornShell, the alias r (``re-do'') is preset to fc -e - (equivalent to the POSIX fc -s). This is probably an easier command name to remember than fc (``fix command''), but it does not meet the Utility Syntax Guidelines. Renaming fc to hist or redo was considered, but since this description closely matches historical KornShell practice already, such a renaming was seen as gratuitous. Users are free to create aliases whenever odd historical names such as fc, awk, cat, grep, or yacc are standardized by POSIX.
ashwinsundar

This is a good one!

pbsds

I scroll the view using keybinds that are default in many terminal emulators, namely ctrl+shift+up, ctrl+shift+down, shift+pgup, and shift+pgdown. It seems also that ghostty has the ability to configure keybinds to adjust the selection, which may be of interest to you

epilys

I am fairly convinced there is no true voice first terminal experience-- this is something I am hoping to change

I've written a terminal e-mail client. If I want to make my terminal app usable by voice, what assistive software stack should I use for development? I am aware of things like AccessKit but that's geared to graphical user interfaces.

Since my client is a library with a terminal front end, I do not even need to retrofit this kind of accessibility, I can just write a new front end.

Irene

I think it would be a worst-case for screen readers due to excessive redraws, but as far as copy-paste goes I use tmux, which has its own internal clipboard that is accessed through its key bindings. those bindings are also changeable.

k749gtnc9l3w

If we are talking tmux, there is also tmux capture-pane -J -p -S -999 (basically output the last 999 lines of scrollback, ignoring linewrapping; then this goes into an editor)

As the question is about input accessibility more than output accessibility, I think tmux might be in fact useful.