Re: mutt/1880: wish: rebind to generic
On Friday, September 23, 2005 at 14:15:02 +0200, Tamotsu Takahashi wrote:
> * Fri Sep 23 2005 Alain Bench <veronatif@xxxxxxx>
>> We probably want "unbind *" functionality, if not syntax.
> You can make a file with a lot of unbinds and source it.
Well yes. But that's less practical, can miss new bindings on
upgrade, and it less suits the target of beginners wanting to build
their bindings from scratch with only the functions they know so far.
But that's doable. Let's imagine an unbind-all-keys.rc kept in sync with
default keys and funcs.
> I am not sure my patch is bug-free.
Since 6 monthes you published patch-1.5.8.tamo.unbind.1, some people
may have reviewed it. I heard no feedback so far?
> use /etc/Muttrc to define initial mappings. That could decrease
> hundreds of lines from the code.
Hum... Would break "mutt -n". And would create sync problems on
upgrade. I mean "make install" does not overwrite an existing
/etc/Muttrc.
>> reintroducing ambiguity by adding an "unbind" command is not good.
> "bind <map> <key> generic" may be the best solution. It's easy and
> clean.
I believe that's the best idea. Consistant and logic: "bind <map>
<key> noop" for feature (1), "bind <map> <key> generic" for feature (2).
Nearly perfect, if it was no unbind corner cases:
- "bind index <Tab> generic" (no generic fallback for <Tab> key)
- "bind pager,editor <key> generic" (no generic fallback for pager nor
editor maps)
- "bind generic <key> generic"
They would all three really do function (1), disabling the key,
wouldn't they?
As I have no better all-cases idea than "generic" keyword, what
about a second choice idea: Have 2 synonym keywords, "generic" and
"remove". They would do the same thing exactly, removing a binding. And
the user would be free to use the most appropriate for each situation,
"bind index j generic" or "bind index <Tab> remove". Humm... "remove"
keyword is unlikely to collide a future real function, right? Does it
make sense at all?
Bye! Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The Folding@home project at <URL:http://folding.stanford.edu/>.