Re: change_folder_next patch
=- Alain Bench wrote on Sat 19.May'07 at 16:50:46 +0200 -=
> [binding comma]
> > Comma is not by itself special, _you make it_ (or want it to be)
> > special.
>
> I indeed use myself and advice this usage of the comma, but
> haven't invented it: It was already a traditional usage when I
> began using Mutt, around the 1.3.27 times. IIRC David DTG was then
> promoting it.
>
> Any free key we bind will conflict with one or more existing
> setups. That's unfortunate, but we have to do it. However there is
> no point to maximize this annoyance.
Even though you _might_ be right, there is no numeric foundation for
your assumption this would be the "maximum annoyance". ;)
I've only seen it mentioned by you and init0, but we have no idea
how many people use any other potential key.
Examples are nice, still they get adopted to personal preference.
',' is not everybody's favourite position to use on the keyboard, so
examples are adapted.
> [<function>/$var]
> > what is "important"? [...] whose opinion about "importance" is
> > true or to be used for all?
>
> As usual: Discussion, consensus, common sense, all this fed by
> usage scenarios, with a privileged voice for the implementer, and
> last word for the maintainer. This works rather well.
I think we can drop "consensus" from this list (and some related ;).
> > Why not instead keep a functional minimum and let everybody
> > decide and expand via macros to personal needs?
>
> My humble {opinion} is that such a mailer would be less eas{i}ly
> usable than Mutt is. I'd prefer a more equilibrated balance: Bound
> <functions> for important/main features, modifier $vars and macros
> for the rest.
Maybe (probably) we're treating "functional minimum" differently, or
we're just again back to judging importance of functions.
The main function is to change folders, which is already given.
The rest are just variations by flavour.
> [<change-folder> first/next]
> > What's the point of having a default that most mutters will
> > change? Isn't the purpose of defaults to avoid this?
>
> {...} Stability is also important, to not break existing setups
> nor astonish users. Changing defaults is done only when there is a
> great benefit in doing so. A moderate benefit is not enough.
>
> Evaluation of the benefit follows the same process as the
> evaluation of the importance of a feature, above: Consensus,
> common sense, and tutti-quanti.
Heh... but when you have "stability" in your calculation, it will
always be stuck in the way of improvement.
That's a fundamental question: keep status quo or improve?
Not annoy oldies or make newbies happy? (when you can't have both)
> > I suggest removing default bindings for all those functions that
> > need some background info + muttrc tweaking before being able to
> > use it.
>
> I'm strongly against such dangerous revolution.
> Reduces usability,
Uhm ... how, when they are useless without extra muttrc work?
They are not (can't be!) supported by default, since pop, imap, pgp,
query (and a wannabe next-mailbox) require personalized data.
> gives more work to users.
You mean adding an extra "bind ..." line for the function they are
about to use, next to whatever they have to setup to get the
functionality working at all?
Yes, it is _more_ ... but too much to be aware of what you do?
> For what benefit? None. This doesn't even reduce the lenght of
> <help>, only pushes those unbound functions to the end of list.
Heh... this _is_ the benefit, since people read top-down, so they
have less to scroll down.
> > Then, when mutters are ready to use it, they can assign keys to
> > their _own_ liking while they must set up the core functionality
> > anyway.
>
> This scenario could be helped by an "unbind *" feature.
Wasn't there already a patch for it? This sounds familiar.
--
© 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.