Re: change_folder_next patch
Hi Nick, Vincent, and Rado,
On Thursday, May 3, 2007 at 14:29:04 +0100, N.J. Mann wrote:
> I have no problem with it being unbound by default
This function is very handy, and have good chances to quickly become
the primary way of changing folders for some non-negligable amount of
Mutt users. It *wants* a default binding, IMHO.
History shows that unbound functions stay confidential. See
<decrypt-save> for example: Half a dozen users, no more. All the
potential target uses <decode-save> instead, and crys. ;-)
> For me having it bound to a single key-sequence is a must have
You mean, for you as a user? The user is of course free to bind the
function to a single key. I would probably do that. As default binding,
that's another story: What would mandate a single key?
> On Thursday, 3 May, 2007 at 12:16:39 +0200, Alain Bench wrote:
>> <next-folder> is a "risky" function (deleted mails may get purged)
> But you get the purge prompt just like you do with <change-folder>. If
> you have set 'delete' to 'yes' then all bets are off.
I strongly disagree: We don't want to assume too much about user's
habits and setup. With data integrity, we want to be very conservative.
>> a key combination less prone to false moves. Humm... <Esc>m perhaps
>> (can be typed <Alt>m on some terminals), with "m" as mailbox.
The more I think to it, the more <Esc>m seems a good choice.
>> this function doesn't jump to the next _folder_, but to the next
>> _mailbox_ (a folder declared in "mailboxes" list)
> But, <change-folder> is called change-FOLDER
Rightly so, as <change-folder> changes to any folder, be it in
mailboxes list or not.
On Thursday, May 3, 2007 at 15:52:33 +0200, Vincent Lefèvre wrote:
> "mailbox" means the *current* folder in the function names
> (sort-mailbox, sync-mailbox).
You're right, "mailbox" also seems to be used for the current
folder. I don't know if it's really intended like so... But isn't the
current folder monitored for incoming mails, just like if it was on the
mailboxes list? ;-)
> to be more accurate, why not [...] next-unread-mailbox?
Good one. For messages, "unread" means "old" or "new". The function
jumps to mailboxes with new mail. So <next-new-mailbox> could seem yet
more accurate. However "new mailbox" could be misinterpreted. And in the
mbox case, "mailbox with new mail" and "new mailbox" can be different
beasts. OK: I approve <next-unread-mailbox>.
On Thursday, May 3, 2007 at 16:11:36 +0200, Rado Smiljanic wrote:
[binding comma]
> But the same users won't know about the new function or simply haven't
> used it before and therefore won't miss it (or expect it to be on
> ","). Those aware of it can rebind to whatever they want, if they
> already have "," bound. I see no loss there.
Of course any non-beginner knows how to fix such not-a-problem. But
the beginner doesn't, and this is a problem. We can easely avoid it from
the beginning, at no cost. So we should just avoid it.
The loss: In case user has comma alone bound to anything in muttrc,
the <next-unread-mailbox> function will be cleanly pushed out to unbound
state. <help> says <next-unread-mailbox> is unbound, but manual says
comma. Not a major prob, but already annoying.
In case user has comma as prefix of a multi-keys binding: <help>
says <next-unread-mailbox> is bound to comma, manual too. But the comma
key gives nothing. Nothing, until user presses the next key. This is
much more annoying.
Bye! Alain.
--
How to Report Bugs Effectively
<URL:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>