4 ms·

> I think the interactivity you describe might be a different thing from what your parent is talking about. Actually no, they're not different things; both ref

> I think the interactivity you describe might be a different thing from what your parent is talking about. Actually no, they're not different things; both refer to the same activity of a user analyzing the information on the screen and issuing commands that refine the available information iteratively, in order to solve a problem. (I would have bought your argument had you made a distinction between "solving the problem" and "finding the right tools to solve the problem"). The thing is that the Unix shell is terribly coarse-gained in terms of what interactivity is allowed, so that the smaller refinement actions (what you call "input") must be described in terms of a formal programming language, instead of having interactive tools for those smaller trial-error steps. There are some very limited forms of interactivity (command line history, keyboard accelerators, "man" and "-h" help), but the kind of direct manipulation that would allow the user to select commands and data iteratively, are mostly absent from the Unix shell. Emacs is way better in that sense, except for the terrible discoverability of options (based on recall over recognition).

SomethingOrNot 8y ago
One of the dead ends of Unix UX are all the terse DSLs. I feel that terse languages like Vi’s command language [1] get confused with interactivity. It sure can be terse, but having dozens of tiny languages with little coherence is not interactive; it’s just confusing and error-prone. One of these languages is the history expansion in Bash. At first I was taken by all the `!!^1` weirdness. But (of course) it’s better—and actually interactive—to use keybindings like `up` (previous command). Thankfully Fish had the good sense to not implement history expansion. [1] I use Emacs+Evil so I like Vi(m) myself.
pdkl95 8y ago
> select commands and data iteratively ... Emacs is way better in that sense Bind up/down to history-search-backward/history-search-forward. In ~/.inputrc # your terminal might send something else for the # for the up/down keys; check with ^v<key> # UP "\e[A": history-search-backward # DOWN "\e[B": history-search-forward (note that this affects anything that uses readline, not just bash) The default (previous-history/next-history) only step through history one item at a time. The history-search- commands step through only the history entries that match the prefix you have already typed. (i.e. typing "cp<UP>" gets the last "cp ..." command; continuing to press <UP> steps through all of the "cp ..." commands in ${HISTFILE}). As your history file grows, this ends up kind of like smex[1] (ido-mode for M-x that prefers recently and most frequently used commands). For maximum effect, you might want to also significantly increase the size of the saved history: # no file size limit HISTFILESIZE="-1" # runtime limit of commands in history. default is 500! HISTSIZE="1000000" # ignoredups to make the searching more efficient HISTCONTROL="ignorespace:ignoredups" # (and make sure HISTFILE is set to something sane) [1] https://github.com/nonsequitur/smex/ https://github.com/nonsequitur/smex/
- SomethingOrNot 8y ago
  Both terminals, shells and Emacs suffer from the problem that you have to configure them out of their ancient defaults.
- gknoy 8y ago
  I also like setting my history so that it appends to the history file after each command, so that they don't get clobbered when you have two shells open: shopt -s histappend export PROMPT_COMAND="history -a"

SomethingOrNot 8y ago

One of the dead ends of Unix UX are all the terse DSLs. I feel that terse languages like Vi’s command language [1] get confused with interactivity. It sure can be terse, but having dozens of tiny languages with little coherence is not interactive; it’s just confusing and error-prone. One of these languages is the history expansion in Bash. At first I was taken by all the `!!^1` weirdness. But (of course) it’s better—and actually interactive—to use keybindings like `up` (previous command). Thankfully Fish had the good sense to not implement history expansion. [1] I use Emacs+Evil so I like Vi(m) myself.

pdkl95 8y ago

> select commands and data iteratively ... Emacs is way better in that sense Bind up/down to history-search-backward/history-search-forward. In ~/.inputrc # your terminal might send something else for the # for the up/down keys; check with ^v<key> # UP "\e[A": history-search-backward # DOWN "\e[B": history-search-forward (note that this affects anything that uses readline, not just bash) The default (previous-history/next-history) only step through history one item at a time. The history-search- commands step through only the history entries that match the prefix you have already typed. (i.e. typing "cp<UP>" gets the last "cp ..." command; continuing to press <UP> steps through all of the "cp ..." commands in ${HISTFILE}). As your history file grows, this ends up kind of like smex[1] (ido-mode for M-x that prefers recently and most frequently used commands). For maximum effect, you might want to also significantly increase the size of the saved history: # no file size limit HISTFILESIZE="-1" # runtime limit of commands in history. default is 500! HISTSIZE="1000000" # ignoredups to make the searching more efficient HISTCONTROL="ignorespace:ignoredups" # (and make sure HISTFILE is set to something sane) [1] https://github.com/nonsequitur/smex/ https://github.com/nonsequitur/smex/

SomethingOrNot 8y ago
Both terminals, shells and Emacs suffer from the problem that you have to configure them out of their ancient defaults.
gknoy 8y ago
I also like setting my history so that it appends to the history file after each command, so that they don't get clobbered when you have two shells open: shopt -s histappend export PROMPT_COMAND="history -a"