Date: Thu, 18 Aug 2022 14:10:05 +0000 From: "Nia Alarie" <n...@netbsd.org> Message-ID: <20220818141005.5005af...@cvs.netbsd.org>
| sh(1): Allow an explicit set -o vi or set -o emacs to override ~/.editrc I'm not sure that change is a good idea - but it depends how you view the .editrc file. The effect of "set -o editor" (for whichever editor it uses), that is when the shell does: el_set(el, EL_EDITOR, editor); is to essentially set up all the key bindings so they match what that editor expects them to be. Doing that after having processed .editrc seems backwards to me, as whatever that file did (at least for key bindings) is going to be lost. I'd have expected that normally the idea would be to set the key bindings for the editor of choice, and then use .editrc to override any that the user wants to alter. (editline (libedit) (and readline for that matter) don't actually implement emacs or vi (duh!) what they do is provide a whole set of functions that perform editing micro-actions on a line buffer, and allow key bindings to invoke those functions. The functions provided implement the ability to edit text, using operations that perform similarly to vi or emacs commands. Setting vi or emacs mode simply sets all the key bindings so that the keys act like they would when editing using the corresponding editor. But the user is free to mix and match to create an environment that is even better (for this task, where many editing operations that a full editor needs to provide make no sense), so a vi mode user can bind ^A to "go to beginning of line" in insert mode if they want, just like happens with emacs editing, rather than "insert a control-A" which would be normal in vi, while otherwise having the command line editor act like vi. That won't work if what .editrc is overridden by the el_set(EL_EDITOR) operation. The commands that can go in .editrc which don't affect the key bindings (like setting the history size) should be unaffected by the order these two steps are performed. kre