Re: change_folder_next patch
=- Alain Bench wrote on Thu 24.May'07 at 13:59:13 +0200 -=
> > ',' 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.
a) should comma eventually stay unbound (I hope so, but for other
reason: not having an own function+key at all ;), then please let's
make it "official reservation", advising in docs not to use it for
manual usage but only for internal macro dispatcher as common
practice.
(Although I'd prefer another less frequently/ easily hit key to
reserve instead, like '§', comma is too close to other used keys)
> >>> 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:
b) If policies would change, then removing default bindings for the
unusable (unuseful) functions would produce more free single-keys,
we wouldn't need to argue over comma and settle with a).
c) Both belong together policywise: if a decision is reached for
one, it should likewise apply for the other (begone pgp, imap, pop,
query functions, to be treated as with the user Two solution below).
But I can spin-off if that makes matters easier.
> [<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.
By this logic you want to have 2 main functions:
- pure "change-folder" (unrelated to mailboxes, no default),
- "change-mailbox" (varied by defaulting to 1st or next in
'mailboxes' or even directly entering browser for mailboxes)
This makes _more_ sense to me, even though I still don't see the
necessity for a separate function at all. ;)
> [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.
There is no "insufficient" improvement, only "too tight" folks.
If we'd listen to them, then the world would still be flat. ;)
Besides, once a change has been applied, over time it will become
stable, too. It's not like it's changing weekly, but to correct what
has been forgotten in the past or changed due to new conditions not
known back then.
> >> 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.
... all of that could be handily presented where Two has to learn
about "mailboxes" at all: copy&paste is no overkill, no debug
necessary, since the template would mimic currently assigned, then
still free keys.
Only when he _wants_ to understand what this all means, he can go
on to learn what it actually does -> makes people curious to learn
more -> good.
And it reduces chances for people mistakingly hitting the key and
possibly be scared/ confused by error msg for not properly/
completely setup functionality.
> >> 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.
Both, but what I failed to emphasize is "learn is good" argument
repeated above.
> 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.
Uh, I wasn't aware of this background. I asked Brendan for DGC's
version, response: "I'm for unbind". :)
> 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 ! -+-
And now the translation, please. :)
--
© 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.