Thank you for the discussion.
2024年2月4日(日) 12:59 Martin D Kealey <mar...@kurahaupo.gen.nz>:
> I am generally concerned about breaking changes that affect existing
> scripts, but I see changes to readline as less problematic,
I also assume shell scripts, but shell scripts for interactive
settings. Interactive settings can also be a large-scale shell
script. There are many frameworks---such as fzf, atuin, autojump,
zoxide, sbp, liquidprompt, etc.
> since an interactive user gets the chance to check the replacement
> before hitting enter.
I don't think we can ensure that the users *always* have a chance to
check it. It is possible to set up the readline macro so that it
immediately runs the expanded command (as I implied in my previous
reply by including \r at the end of an example macro string). If it
is possible, then there are always some users utilizing the behavior
in the world no matter how one person considers "this is almost never
useful" or "an interactive user gets the chance".
In fact, I think there is a motivation to do so: To force
re-evaluation of PS1 to update the prompt (e.g. after changing the
current directory), a command needs to be executed through the
readline bindable function `accept-line'. For example, one can
generate « cd '...' » by "\M-\C-e" and execute it by C-m in a single
macro string.
> Yes users have to learn new behaviours, which isn't ideal, but if my
> suggested "unquote" ("dequote"? "strip-quoting"?) bindable function
> was also added, the impact on users would be minimal: press M-C-e
> and then a second keypress to remove quotes, bringing the input
> buffer to the same state as would occur under the current
> arrangement. (By choosing a default binding for "unquote" that
> currently does nothing, people could then use the same keyboard
> arpeggio on both old and new bash.)
That's right, but I'm not talking about the cases where the user
directly inputs "\M-\C-e" on the keyboard. I'm talking about macros
set up using « bind '"...": "..."' » by shell frameworks. To me, the
above paragraph seems to be irrelevant to the present discussion.
> > If the requoting behavior would be desired, I strongly suggest
> > keeping the existing behavior of shell-expand-line but adding a
> > separate new bindable function (like
> > shell-expand-and-requote-line) to perform the expansion and
> > requoting.
>
> On reflection, this would be a fair compromise, at least in the
> short term.
Does it need to be short-term? Do we need to remove the feature?
> Might we offer guidance that distros include a new binding for C-M-e
> in their supplied /etc/skel which would only affect new users, not
> existing users?
I have a native question. Why do people on this thread discuss
changing the behavior of "\M-\C-e" even though there is still a large
space of key combinations? "\M-\C-e" is already used in existing
shell frameworks for interactive uses, e.g. an old version of fzf
keybindings used "\M-\C-e" in macros for every Bash version (yet
currently only for bash <= 3.2). There would be still customized
versions of fzf that are not updated, or other personal configurations
inspired by the fzf keybindings. I don't see a reason to introduce
unnecessary conflicts when we can just pick another key combination
(e.g. "\M-\C-x") for `shell-expand-and-requote-line'.
--
Koichi
