On Mon, Sep 20, 2021 at 08:31:07PM -0700, "Kevin J. McCarthy" <ke...@8t8.us> wrote:
> 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). That convinces me that <display-message> makes much more sense. There's still so much I don't know about mutt. :-) Great programs are like that. > 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. Definitely agree. > 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). I think it's usually a bad idea to implement something that solves a problem that isn't actually affecting anyone yet. This sounds like a case of that. There will definitely be better ways to spend your finite remaining keystrokes. :-) > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA cheers, raf
