=- Alain Bench wrote on Mon 14.May'07 at 21:51:29 +0200 -=
> [we're too long: Let's snip drastically]
I hope this means just redundancy, not unique topics. ;)
> [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.
Binding to any specific key will be a problem for all those already
using that key, 'comma' is the same as 'ESC m' or whatever other
unused key you want to assign: somebody on earth probably has it
bound (*goes to bind it in its muttrc just to prove the point* ;).
Comma is not by itself special, _you make it_ (or want it to be)
special. Nobody uses _all_ default keys and others besides me have
rebound their preferred functions over default bindings and unused
keys alike. What about those users, don't they deserve to preserve
their muttrc while having instant default access to the new
function, too, like those who have bound their personal stuff to
comma and don't want to miss a new default?
Why are those non-comma but something else users less worth than
comma-users?
> [<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".
Nothing wrong with that, but "much" ... it's relative, and need not
be "too late", especially when desc. recommends usage of macros with
examples.
> There are users having never crafted a macro, and not really
> planning to.
Like probably every mutter who was happy until he reached his
limits (incl. myself). I repeat: mutt can't suit _every_ case.
mutt requires some tweaking to adjust it to personal needs, and
it's even its strength that you can (must? ;) do it.
> We won't design a <function>/binding combo for everything. Only
> for important things.
Happy to hear this, but what is "important"?
That was the point of the long msg before: you listed a lot of
functions which one or the other feels more important to himself
than others and therefore deserve a separate function. So ... whose
opinion about "importance" is true or to be used for all?
Why not instead keep a functional minimum and let everybody decide
and expand via macros to personal needs?
And for typical usage offer some Muttrc defaults or ready to use/
source samples?
> > 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.
There is: when a new behaviour is (going to be) used by the majority.
(which I don't see for this case, but generally speaking, I was just
expressing that I wouldn't mind changes in favour of advancement,
especially for the newcomers)
What's the point of having a default that most mutters will change?
Isn't the purpose of defaults to avoid this?
> And there are strong reasons not to, especially for such a central
> prompt where people can count on a stable behaviour.
If there _were_ such reason above (generally advancement for the
majority), then a change might disturb many oldies, but
a) not for long,
b) not too many or even at all when informed in time,
c) people will soon get used to the new standard,
d) they can deal with it, it won't happen every other week anyway.
Wrong?
See how pgp handling has been changed from traditional to now. That
was a major change, certainly with lots of moaning and groaning, yet
the "right way" was chosen and eventually was accepted as new default.
Was that a bad thing to do despite the big tempporary pain it caused?
You have to decide the principal question for yourself: do you want
to ...
- _lead_ the (_new_) masses on the right way for long-term general
advancement,
- or _follow_ the convenience/ shortsightedness/ lazyness of the
(_old_) masses to be stuck with a bad way?
It's not hard to tell where I belong to, or is it? ;)
> > 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.
Agreed. But at the same time, people not aware of this desc. can't
use the functionality anyway or even don't need it at all.
For them it's more useful to have a "cleaner" function list whenever
they hit '?' to look for something.
Therefore I suggest removing default bindings for all those
functions that need some background info + muttrc tweaking before
being able to use it. 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.
- pgp: mail-keys, extract-keys, check-traditional,
forget-passphrase, decrypt-*
- pop/imap: fetch-mail, imap-fetch-mail
- misc: query, (next-mailbox, if it remains a function)
For convenience those could be offered in samples ready to source or
copy into own muttrc, with some sane defaults for the vars +
bindings for the keys/ macros.
> >> -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?
Thanks for finding arguments for the "other" side, too. ;)
Have both what? Var + function? Oh no, please not, change-folder +
-readonly was already wrong.
> > 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.
But why those and not the others? Can't you imagine other people
valuing those which you excluded higher than the others to justify
separate functions for them and not your selection?
> >> -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?
Well, a macro without the var couldn't emulate -readonly variant. ;)
We talk here only of redundancy between 2 run-time functions,
not cmd-line options.
Redundancy between run-time functions and cmd-line options is
another matter again, but not so much of a conflict, since options
are optional and therefore don't stand in the way by default.
> >> Slrn has <skip_to_next_group> and <skip_to_previous_group>
> >
> > More equivalent were if it had {...}
>
> Come on, guy: They'd need some help of The Great Renamer! ;-)
If I used it, maybe, and then only 1 after the other: let's finish
this first before starting another.
> 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.
That sucks. Hooray for tin, but I guess even slrn can be changed to
be useful, ... err, suck less. ;)
--
© 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.
