Re: change_folder_next patch
=- Alain Bench wrote on Fri 11.May'07 at 16:03:56 +0200 -=
> This touches the /new <function>/ vs /modifier $var/ debate.
I'm sorry, I must have missed the last one (or I'm running out of
RAM and it was overwritten ;), what was it about, when did it
happen, where can I read about this?
> 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>.
Yes, but without background what made him decide this way.
> 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).
Well noticed, so that's not an issue in this case.
> We could populate our tarball's /etc/Muttrc, but this is not
> always installed or used, depending on packagers, admins, policy,
> and users.
Populating Muttrc is unnecessary.
If people RTFM, they find out about it (ideal, but rare).
If they don't RTFM, they also rarely check '?'.
Even if they (few) do, without background info (minimum knowledge is
requirement to define "mailboxes") the entry 'next-unread-mailbox'
won't help much either, so either people completely ignore/ miss it,
or they don't understand its meaning even when they see/use it.
> Important functions should be functions, and have a default
> binding.
Nothing against this, the functions would be still in there.
The important function is to change-folders.
And I wouldn't even mind the new one being the default for
<change-folder>, since everybody not liking it can set it to his
liking per the var. As you noted, this function only makes sense
when you edit muttrc, and this only makes sense when you RTFM, and
then you learn what you need either way (or both ;).
> 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?
Why can't this work as default?
Anyway, not right, it makes sense, from a functional point of view.
But then we also have usability, so we're back to my original
question. Movement _is_ of general use, in both directions, so your
fictional implementation wouldn't satisfy the need, because in that
case indeed the user would be screwed: movement is so elementary you
shouldn't be required to RTFM about it, there is nothing mutt
specific you must learn about it.
For mailboxes and different behaviours related to them you _must_.
> {...} 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.
Yes, but this isn't the only case. As questioned in #mutt, why would
this be different from others?
E.g. composing, (group/list)replying, forwarding with/out Subject:,
To:, Cc:, Bcc:, Reply-To:, ... this would mean _a lot_ of functions
to have handy for each possible case, and many of those combinations
maybe be used in many flavours on many different keys by the same
user. ;)
Brendan mentioned the "slippery slope" argument, but didn't go into
details about why he goes the slippery way. ;)
> [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.
Seriously, that's a personal problem, we can't support every
individual case. With other changes this has and will affect old
users with old/ complex configs one way or the other, too. There is
nothing special about this case (or any other).
Even though mutt has some cool new features, and it would be nice if
_everyone_ would use it effeciently right from the start, that's not
really necessary.
Those who've been missing it all the time will quickly notice if
they care to update at all and with that read UPDATING.
The others have been happy enough already without it, and will learn
later about it when word spreads.
> He then reads in Changelog, <F1>, and <help> about a new killer
> function bound to comma. It doesn't work.
If he really is so aware, he then as well will/can hit '/' to search
for it and notice that either it doesn't exist in his actually used
version (because he hasn't updated yet ;), or -- if it's supported --
that it's listed at the end as unbound function and requires action
on his part, which he's capable of performing given his "help
yourself" skills. Or do you talk about those having all your listed
skills but lack just RTFM skills? ;)
> > 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.
Agreed, but still the "we can't save each individual" (without
putting much too much into the code) applies.
People will always bump into something.
Instead of offering a new function to people not knowing how to use
it, let's rather make people more knowledgable (easier to use docs).
> 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.
Heh, the paragraph suits me well: making this feature a function is
a _hard_ choice.
Being a var it still would suit everyone, no security breached or
data integrity in danger, no RFC broken, ... well, coder lazyness
isn't an issue here, since both ways are simple (if I've seen+
understood correctly).
Good reason? Hmm, merely 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.
There is no function yet that needs so much info about it that it
wouldn't fit in the single line help (well, except maybe the
decrypt- and decode- functions ;).
I think a var + its docs will add more to its awareness than a
simple function entry.
> There is no good reason to bind comma by default, given the
> perturbations this can generate.
If it's no separate function, comma isn't needed! :)
But even for the next new function_s_, at some point you will run
out of suitable keys. ;)
> > 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. ;-)
Not drop, just propagate to promote a new de-facto standard.
But that's besides the point anyway, I like to have both, even the
new one taking the lead as default, as long as its not a function. :)
> 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.
I admit I've learned about this just a few days ago when reading the
desc. of <change-folder> for this debate. Even though this would
have been nice to me in the past when I needed it, those exceptional
cases of _varied_ usage are too rare to justify a dedicated function
where a simple macro does it alright.
> -c) <change-folder><Enter> to first priority new mailbox.
> -d) <next-unread-mailbox> to next new mailbox after current.
Just a variation of the same base functionality.
> -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>.
None of these have a separate functions yet.
Do you want to have one for each of those?
Even though they already work fine as they are (or with macros)?
> 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.
Right, but all of which can be served easily already (or with macros
+ variations per variables), few of them _require_ a new interface/
access point.
> 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.
Many ways == good: agree.
Notice new function and use it: don't agree, or too rare to be worth.
Especially for a feature too complex to describe in 1 '?' line.
Even though they are many, still too few RTFM, too few hit '?' to
see what they can do without RTFM.
> 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.
No, that's exactly what we're doing right now.
> 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.
See, if we have the var for (d), all of that is/can be nicely
covered with macros where it makes sense (d if new function not
making sense to bind by default, while having default macro will
make people curious to inspect if they care).
> 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).
Your slrn example (if comparable at all ;) is equivalent to normal
<change-folder> unrelated to "mailboxes". 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 ;)
> 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) ;-)
*sigh* . . . o O ("late").
Principal questions are never too late to discuss, and if necessary
to correct. Yes, of course there are billions of mutters who'd bump
into or even stumble over such change, but in the long run things
will be cleaner and easier to get into for all the _tri_llions more
mutters to come.
Just because mutt has already stepped on and slided down the
slippery slope this doesn't mean it can't get back on track with
some effort and help from above.
If we don't give a damn (hi Dave ;) things just get worse while we
could do something about it. Mutters won't jump off mutt, they're
flexible and (can) adapt when informed ahead of time.
> > 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.
I haven't understood it that way, but see them both on par.
I was just opposing the idea that because "it will be so hype" it
_deserves_ a separate function.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.