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!
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.
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.
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.
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
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.
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.
i've been hacking on my own terminal multiplexer: an infinite canvas terminal multiplexer that uses libghostty-vt for terminals, and iroh to connect to remote daemons.
geocar | 12 hours ago
Friend, let me tell you about the
fccommand.fc -llists the last few commands.fcand a number edits that command in your favorite$EDITORand then when you save/exit it runs it!dtgriscom | 8 hours ago
What does
fcstand for? Or, how do I remember to usefcwhen it would be useful?novedevo | 7 hours ago
From
man fc(emphasis mine):ashwinsundar | 10 hours ago
This is a good one!
emallson | 14 hours ago
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.
epilys | 12 hours ago
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.
pbsds | 13 hours ago
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
Irene | 10 hours ago
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 | 8 hours ago
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.
op | an hour ago
i've been hacking on my own terminal multiplexer: an infinite canvas terminal multiplexer that uses libghostty-vt for terminals, and iroh to connect to remote daemons.
i have been posting about it on bsky: https://bsky.app/profile/did:plc:qfpnj4og54vl56wngdriaxug/post/3mzgp5uew222e
work in progress codebase: https://tangled.org/oppi.li/tarp