Re: change_folder_next patch
On Monday, May 21, 2007 at 17:57:02 +0200, Rado Smiljanic wrote:
[binding comma]
> we have no idea how many people use any other potential key.
We may imagine. If we neglect the tradition about comma, we can
half-safely imagine that users bind any single free key more or less
equally. For key combinations (including shift-letter), or sequences of
2 keys, we can guess they are statistically less bound than single keys.
Sequences of 3 keys yet less, and so on.
> ',' is not everybody's favourite position to use on the keyboard, so
> examples are adapted.
Yes, sure. But when examples bind say ",@r13on", that's not intented
to be a key sequence typed by a human.
IIRC the full story about the comma tradition was for users to do
something as:
- Never bind single comma.
- Bind sequences of ",@" followed by max 6 chars for macros internal
machinery.
- Bind 2 or 3 keys short sequences beginning by ",[^@]" for human typed
macros. This ahum... "namespace" is entirely free.
[<function>/$var]
> The main function is to change folders, which is already given. The
> rest are just variations by flavour.
Yes. But I was talking from another POV, "main" as mainly used
functionality. When a user wants to open his first new mailbox, I count
1 point for the <first-unread-mailbox> functionality, not for the
<change-folder> really used function.
[changing defaults]
> Heh... but when you have "stability" in your calculation, it will
> always be stuck in the way of improvement.
Stability only blocks insuficient improvements.
>>> I suggest removing default bindings for all those functions that
>>> need some background info + muttrc tweaking before being able to
>>> use it.
I assume(d) this proposal was, like my <first-unread-mailbox> and
<browse-mailboxes> proposal, just an illustration, drawing the context
around our discussion. Otherwise, if it's a serious proposal, better
fork an own new thread. I'll still comment in focus:
>> gives more work to users.
> You mean adding an extra "bind ..." line for the function
Yes: User One has to catch the concept of incoming mailboxes, find
the "mailboxes" syntax, and populate his muttrc. Then he uses the <Esc>m
found in manual.
User Two has the same work, but also has to discover there is a
<next-unread-mailbox> function, figure that it is unbound and he must
bind it before use, study manual for bind syntax, understand the concept
of menus, figure which menus make sense for <next-unread-mailbox>, find
a free key, and write and debug his setup.
>> 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.
Either I don't understand what you mean, or don't value this benefit
as much as you.
[virgin territory]
>> This scenario could be helped by an "unbind *" feature.
> Wasn't there already a patch for it? This sounds familiar.
DGC's unbind patch has both the /unbind all/ and /rebind to generic/
new capabilities. My humble is that both features are dearly wanted, but
that the syntax should be better integrated with the only current
/unbind to unbound/ syntax (bind "noop" keyword). Tamo-san made a patch
doing that cleanly, but lacking the /unbind all/ feature. We'd need a
merge. Discussions are dispersed, but wish#1880 can be a good start.
Bye! Alain.
--
MB : Qu'est-ce que c'est que cet AAD à la con ?
MS : Parfait, je vois qu'il y a consensus. On peut passer au vote.
-+- in: Guide du Cabaliste Usenet - Atteindre le sensus, con ! -+-