Hi Rado and Gary,
On Wednesday, May 9, 2007 at 20:23:24 +0200, Rado Smiljanic wrote:
> why do we need the extra function? [...] Is it just so that this
> action can be executed with a single key?
> macro index <change-folder><enter>
> If there's no new, nothing happens.
This touches the /new <function>/ vs /modifier $var/ debate.
Modifier var seems to be more in Mutt's historical spirit. But I'm not
sure to plainly adhere, and Brendan apparently neither: He pushed for a
new <function>. A macro is easy to craft, but is a muttrc thing: Doesn't
work in -nF /dave/null case (well, the whole "mailboxes" concept neither
works then). We could populate our tarball's /etc/Muttrc, but this is
not always installed or used, depending on packagers, admins, policy,
and users. Important functions should be functions, and have a default
binding.
Just imagine an absurd situation: No <next-page> nor
<previous-page>, but a single <jump-page> function with a
$jump_page_direction=up/down modifier var. Two macros emulating both
origin functions are easy to craft, but are to be done by the user, and
can't work as default binding. This (extreme) example doesn't make any
sense, right?
There are surely situations where modifier $vars make sense, for
minor preferences. Main features, and features that may be used in
2 flavours on 2 different keys by the same user, probably want
2 <functions>. Subject to close analysis of each case, of course.
In our present case, my humble is that we want a <function>. But
more on this below.
[binding comma]
> But why is it broken for the beginner, since either he doesn't miss it
> or he already has something in his muttrc overwriting ',' and
> therefore is not so much a beginner anymore.
He long ago blindly copied from wiki a macro set, and forgot about
the inner comma gory details. He then reads in Changelog, <F1>, and
<help> about a new killer function bound to comma. It doesn't work.
> What kind of people or setup are you talking about?
Where possible, we try to target everyone. The beginner, the
long-time user that rarely touches at muttrc (and has single/double
quotes wrong each time anyway), the advanced user having never visited
any Mutt support place, the cmm lurker, the hardcore #mutt supporter...
Everyone.
We do hard choices only when it's impossible to suit everyone, when
security is in question, when data integrity, when RFC conformance, when
coders are lazy, and well... when there is a good reason.
There is no good reason to bind comma by default, given the
perturbations this can generate.
> Or you're suggesting to establish a new default mutt usage/ user
> behaviour because of the new functionality (per 1st quoted paragraph)?
You mean, as in bind <next-unread-mailbox> to [c], and drop
<change-folder>? No, not at all. ;-)
On Wednesday, May 9, 2007 at 12:22:31 -0700, Gary Johnson wrote:
> As for the benefit to new users, I think new users would benefit from
> not having yet another means to change folders/mailboxes.
I strongly disagree. We today have a comfortable palette:
-a) <change-folder> prompt (with available <Tab> completion).
-b) <change-folder-readonly> variant.
-c) <change-folder><Enter> to first priority new mailbox.
-d) <next-unread-mailbox> to next new mailbox after current.
-e) <change-folder><buffy-cycle>... to cycle thru new mailboxes.
-f) <change-folder>=given-folder<Enter> macros to specific folders.
-g) <change-folder>? straight to folder browser.
-h) <change-folder>?<toggle-mailboxes> straight to mailboxes browser.
-i) <change-folder>=begin<complete><complete> to a "partial" browser.
-j) <change-folder>?<enter-mask>\.mbx$<Enter> to another form of partial
browser.
-k) <quit> and "mutt -f =other-folder" (I'm not sure it's a smart one ;).
-l) <most-interesting-folder> bound to <F42>.
And probably more methods, variants, and combinations I have
forgotten. Each one makes sense to some users. And each one is hated by
some users. Some users use one method only, others use several methods
depending on their current goal. Finally some users are discovering in
this list a method they didn't notice so far, and will begin using it...
There is more than one (dozen) way(s) to do it, and that's very well.
However, some of these methods are more "main" than others. They
would merit their own <function> and default binding. Which ones? That's
another debate. I think methods (c), (d), and (h) could be such main
ones. Today, only (d) has an unbound function, and (h) has a [y] macro
declared in /etc/Muttrc.
I really think <next-unread-mailbox> can become a main method for a
subset of users (not for all). Slrn has <skip_to_next_group> and
<skip_to_previous_group> bound by default to [N] and [P] in article mode
(equivalent to Mutt's both index and pager menus).
On Wednesday, May 9, 2007 at 22:06:49 +0200, Rado Smiljanic wrote:
> it boils down to the question: what's more user-friendly, less vars or
> less functions.
Given Mutt has 169852 <functions> and 42.7e+8326 $variables, it's a
little bit too late to pose such questions! Let's add some Y-pages to
the manual.txt (Yotta = 10^24) ;-)
> sorry Alain, I don't expect this to be the "new way" for changing
> mailboxes, priorized mailboxes are too useful ;)
Priorized mailboxes indeed are very usefull, to you and many others.
However some people don't value priorized mailboxes so much, or not at
all. I said "some amount of", not "all" users. I never intended
<next-unread-mailbox> to replace <first-unread-mailbox>, but to be aside.
Bye! Alain.
--
Manuals?
See the archives for more discussion on why this should,
like hydrogen for dirigibles, be relegated to the past.
PCC DTG on MU. © August 2004.
