Binding Space to select-entry gives Key is not bound.
Kevin J. McCarthy
kevin at 8t8.us
Tue Sep 21 03:31:07 UTC 2021
On Tue, Sep 21, 2021 at 11:24:56AM +1000, raf wrote:
>On Sat, Sep 18, 2021 at 07:28:14PM -0700, "Kevin J. McCarthy" <kevin at 8t8.us> wrote:
>> Do any old timers have an opinion on this?
>
>I guess the difference is whether you
>think that a "selection" can only contain a single item
>and so the purpose of the selection should be performed
>immediately (so display-message makes sense), or
>whether a selection can contain multiple items and so
>the purpose of the selection might need to be delayed
>until the selection process is complete (so tag-entry
>makes sense).
Thanks raf, I certainly can't say your opinion is due to a lack of
experience with Mutt! However, just to be clear to everyone, my
opposition to the "tag" interpretation is because of Mutt's current
usage of <select-entry>.
Menus that allow both single and multiple selection (e.g. alias list,
file browser, query menu) use tagging for multiple selection and
<select-entry> for single selection. Menus that allow single selection
(e.g. background-edit list, key selection, postponed list) respond to
<select-entry> by immediately using/processing the entry (and usually,
though not always, exiting the menu afterwards).
I understand that in general the term "selection" can be interpreted
either way. But consistent usage within Mutt is important to me, and I
think is a good design principle.
The default bindings for <select-entry> are overshadowed by the default
bindings for <display-message> in the index. But for those who re-bind
it, I don't think there's a good reason to drastically change its
behavior in the index, compared to everywhere else in Mutt. As you
noted, the way to operate on or select multiple entries in Mutt is
already well established: via tagging.
Now, there *is* one case where the index is used as a selection menu:
attaching messages. Currently that interface forces selection (either
one or multiple message) via tagging. One could make an argument
<select-entry> could be used in that case for single selection and
immediately returning. But it would entail some technical changes to an
already complicated menu, as well as requiring a *new* keybinding in the
index. Since that operation isn't all that common I don't know that it
would be worth it, but I'd be open for that discussion (on mutt-dev).
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20210920/db29d78c/attachment.asc>
More information about the Mutt-users
mailing list