Re: change_folder_next patch
On Saturday, May 12, 2007 at 16:10:13 +0200, Rado Smiljanic wrote:
[we're too long: Let's snip drastically]
[binding comma]
We can, and should, avoid creating useless problems for no benefit.
Binding comma is not necessary, and would create problems to some users.
Let's just not do it? You seem to confuse "a problem easely solved" and
"there is no problem", while impacted users would still be required to
do something about it.
[<function>/$var]
Today, AFAICS, macros can't be bound by default. Only <functions>
have a mechanism to do that (in functions.h). A typical new Mutter
beginning his muttrc may quickly learn the usage of "mailboxes", and
only much later learn about "macro". First borrowing some macros in
example muttrcs, an only later eventually building his own ones. There
are users having never crafted a macro, and not really planning to.
We won't design a <function>/binding combo for everything. Only for
important things.
> And I wouldn't even mind the new one being the default for
> <change-folder>
No: There is no good reason to change default <change-folder>
behaviour. And there are strong reasons not to, especially for such a
central prompt where people can count on a stable behaviour.
> adding another function with the short 1-line help in '?' is IMO not
> sufficient to explain its usage, while having a var provides space to
> give background and crossreferences to related and _required_
> elements.
That's a strong argument, right. However a very complex <function>
can be (should be!) explained more extensively in manual.xml.head, in a
paragraph dedicated to its theme, or failing that in the "Miscellaneous
Functions" chapter.
>> -e) <change-folder><buffy-cycle>... to cycle thru new mailboxes.
Thinking to it, the usability of <buffy-cycle> would be enhanced by
$change_folder_next, and not by <next-unread-mailbox>. That's a good
argument for the modifier $var. Perhaps the ideal would be to have both?
> None of these have a separate functions yet. Do you want to have one
> for each of those?
No. I said (c), (d), and (h): <first-unread-mailbox>,
<next-unread-mailbox>, and <browse-mailboxes>. Not the others.
>> -b) <change-folder-readonly> variant.
> those exceptional cases of _varied_ usage are too rare to justify a
> dedicated function where a simple macro does it alright.
I agree 100% on this, especially as the $read_only boolean exists.
Perhaps this <function> is there to suit the mutt -R option?
>> Slrn has <skip_to_next_group> and <skip_to_previous_group>
> More equivalent were if it had
> <goto_next/previous_group_with_new_messages>, that's more what
> next-unread-mailbox is about. (in case it does that already in slrn,
> then the names are not well enough ;)
Come on, guy: They'd need some help of The Great Renamer! ;-)
In fact Slrn design has the "with_new_messages" notion implicit
nearly everywhere, by default. The group list doesn't even show
newsgroups without new posts. So of course <skip_to_next_group> goes
where there are unread articles.
Bye! Alain.
--
Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as
- subscribe ^list@ddress$ if you are subscribed and don't want courtesy copy.
- lists ^list@ddress$ if you are not subscribed or want a courtesy copy.