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

Re: change_folder_next patch (learn ,-tradition; oldies use vs.



=- Alain Bench wrote on Tue  5.Jun'07 at 15:50:45 +0200 -=

>     [The Comma]
> > let's make it "official reservation"
> 
> Users are free to use this or any other binding scheme, at will: I
> don't think that making this one official or even only preferred
> in user docs makes much sense. Putting a note in dev docs (to not
> bind comma against tradition) is a good idea.

Before you said how much this "," (sub)macro-introducer is already
used and would be useful for others to keep it spare for exactly the
case of those traditionally ","-defined macros offered for ease of use.
 Why let newbies run into conflict with those by binding "," before
learning about this tradition?
 It's ok the newbie shoots itself in the foot, but it's not ok the
devs shoot the oldies in the foot? Who can handle it better? :)
 Stability, aye, but just for current oldies, not for now newbies
soon-to-be-oldies, too, who are only unlucky not to know about the
tradition in time before they bind "," and later learn about
","-using examples?
 How would you learn about it anyway? If it's good to know, why not
tell them right from the start?
 It's only a reservation after all, everybody is still free to
ignore well meant advice  to learn the hard way (like I ;).

> > I'd prefer another less frequently/ easily hit key to reserve
> > instead, like '§'
> 
> Respecting a long established tradition, or inventing a new one?

Well, ... since it wasn't "official" yet, it would be kind of
starting it. (I'm not representative, but I wasn't aware of this
"tradition", comma was long/ early gone for prev-entry, to make it
nicely work with "." next-entry)

> Note § is not always a single key: On My French keyboard it's shift-!

Sorry, I was considering only submacro- introducer, forgot regular
top-lvl introducer is used, too.
So be it, "," shall stay reserved for macros rather than "§".

> > - "change-mailbox" (varied by defaulting to 1st or next in
> > 'mailboxes' or even directly entering browser for mailboxes)
> 
> People would still have to build macros for their prefered
> functionality.

Uh, you mean _switching_ (!= preference) between _variations_.
You'd have your "main" function of changing mailboxes by
your preferred way _without_ needing to macro.
 Is there a reason why you want to avoid a variable to change
a default behaviour?
 Or is switching between two variations now a main feature?

> > This makes _more_ sense to me, even though I still don't see the
> > necessity for a separate function at all. ;)
> 
> This scheme is not so good a compromise:
> -1) {...} but is complex for users {...}
> -2) but makes longer <help>.
> -3) Two <functions> and some modifier $vars... That's not so
> logic: A sort of political compromise, not a good design.
> 
> > what I failed to emphasize is "learn is good"
> 
> You really want to make Mutt more complex than it already is?

I? :)
With every new feature mutt naturally becomes more complex of its
own. I'm just trying to keep a consistent/ simplistic scheme.
Realistically, it's hard to know every detail already now. So rather
than giving more "hardcoded" details, make it simple to find and
construct to your liking by giving more variation of what already
exists.
What you consider "main" doesn't feel too different from each other
or basic enough as much as "moving" is to use it every other case of
changing at all. ;)

If a newbie knew about change-folder, you think it would assume
there is another change-folder with some flavour bound by default?
After learning, that the potential flavour only is added to the
"main" function by means of muttrc cmds?
        (note, there is no change-mailboxes yet! Must tweak muttrc
        to "upgrade" change-folder default behaviour)
Why assume yet another variation would be differently implemented?
Wouldn't you look for yet another variation of the same nature
rather than an extra key for it again?
Especially when the new name remains as cryptic as it currently is?

I fear you're focusing too much on the few oldies aware of this special
case of often switching between the order of defaults offered and
having everything set up for it already, just waiting to go.
(people not having setup mailboxes can't use it by default
either yet: "next" relative to what list? Nothing happens/ differs
from "normal" change-folder)

> Reaching the consensus on Usenet:
> well-known moaner: What the f*ck is that stupid RFD?
> a positive guy:    Fine, I see there is consensus. Let's CFV.

Heh, if everything would be so simple. :)

> Je constate que à part ceux qui sont contre, ces 2 groupes
> rencontrent un consensus. On est à 100% d'accord, excellent !

Either my French or my logic fails. ;)

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