Re: CVS commit: src/bin/sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 19 Aug 2022 15:37:59 +0000
    From:        nia <nia%NetBSD.org@localhost>
    Message-ID:  <Yv+uV1F/gOyjpw2B%homeworld.netbsd.org@localhost>

  | I wish editing mode and whether editing was enabled was more clearly
  | divorced.

That might be arranged, I will take a look and see what would be
involved (the major issue is making sure things get updated properly
when the user switches preferred editors - like if one is set as default
in some startup file, and the user then overrides that in another).
If things were to change such that most editing on/off decisions were
made by a separate option than emacs/vi mode, that issue would need
watching to make sure it is not forgotten/ignored.

And wrt:

  | it "feels right" that runtime commands take precedence over config files.

If it was the user manually typing "set -o vi" then yes, I'd agree that
generally that should probably take precedence.   But it almost never is,
those commands are almost always in a "config file" (like .profile or .shrc
or whatever the user wants to call the file in $ENV if they have one).

So what we really have, most of the time, is competing config files, and
and given the brutal nature of what set -o editor does, compared to the
more nuanced (at least, can be) EDITRC file, in this instance I think I'd
have EDITRC override the option's setup - apart from anything else, that's
how it has always been, and people are more likely to have a setup which
expects that, than the other way.

What might be possible however, is to have a change (or enabling, perhaps)
of editing mode, after the shell has issued its first prompt (ie: when it
is reading from the terminal - we know it is the terminal since none of this
stuff applies in any case other than an interactive shell reading from a tty)
have the shell only do the EL_SET "editor" command and not process EDITRC
again at all (if editing was enabled in a startup file, that will have
already been read, before the first prompt).   If the user after manually
choosing their editor of choice, wants their .editrc file processed again,
they can use the inputrc built in to read an editline config file of their
choice (like "inputrc $EDITRC" perhaps), or simply assign a new value to
EDITRC (like EDITRC=$EDITRC).   Either of those will cause the file to be
processed.   This ought to be relatively easy to implement, if it is 
conssidered a worthwhile enhancement (none of this affects me one way or
the other, I set vi mode before the prompt, and cetainly never change it
again, and I don't use a .editrc file (setting vi command maps, and everything
else the default works for me -- I don't use tabcomplete).

kre