<<< Date Index >>>     <<< Thread Index >>>

Re: change_folder_next patch



 On Tuesday, May 15, 2007 at 20:33:34 +0200, Rado Smiljanic wrote:

    [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.


    [<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.


> Why not instead keep a functional minimum and let everybody decide
> and expand via macros to personal needs?

    My humble is that such a mailer would be less easely usable than
Mutt is. I'd prefer a more equilibrated balance: Bound <functions> for
important/main features, modifier $vars and macros for the rest.


    [<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?

    Number of users counts, but is not the only argument when discussing
a change of default. 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.


> 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,
breaks existing setups, gives more work to users. For what benefit?
None. This doesn't even reduce the lenght of <help>, only pushes those
unbound functions to the end of list. No, never.


> 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.


Bye!    Alain.
-- 
Common sense?
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.