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