Re: [broken-patch] unbind command
On Mon, Dec 15, 2003 at 12:01:52AM -0500, David Yitzchak Cohen wrote:
> On Sat, Dec 13, 2003 at 01:06:40AM -0500, Allister MacLeod wrote:
> > On Fri, Dec 12, 2003 at 09:18:08AM -0800, Michael Elkins wrote:
> > > On 2003-12-12, Allister MacLeod wrote:
> > So.. in the intervening time, Dave Champion told me of
> > http://home.uchicago.edu/~dgc/mutt/#unbind
> > Just goes to show that it pays not to be too hasty. A little research
> > in the vicinity of the PatchList of wiki.mutt.org would have saved me
> > a bundle of work. I can only hope that the few new things that I
> > learned about mutt's code may help me later on.
> According to the patch's docs, unbind index z is identical to bind index
> z noop. Is that incorrect (i.e., does it actually unbind the key)?
>From patch-1.5.1.dgc.unbind.1, in function mutt_parse_unbind():
+ else
+ {
+ /* Just the one. */
+ km_bindkey (key, menu, OP_NULL);
+ }
(the other cases before the 'else' are for when there's a '*' in the
unbind arguments)
So, indeed, the documentation of the patch accurately reflects its
behavior. Which, unfortunately, is the same possibly-undesirable
behavior as vanilla mutt gives you.
However, looking at the code and thinking about it, it occurs to me
that I was perhaps barking up the wrong tree with my attempted
reimplementation of DGC's patch. Perhaps a simpler patch would be to
alter the key-handling code to fall back to the generic map when it
finds an OP_NULL in the current menu. That way, you'd only get a "key
unbound" error if the key was truly never bound, or if it was bound to
'noop' in both the current menu and the generic map.
Still, it rankles with my "ivory tower code-purity nerd" side to have
the operation to "unbind" a key actually be the addition of a
null-shaped blob, rather than truly the removal of the binding. If
the baseline were a keymap full of OP_NULL's, it would not bother me
at all. However, the baseline is a map that is empty save for "real"
bindings.
Since the fall-through patch that I described above should be much
easier to create, I will probably have it to post very soon today.
Cheers,
Allister
--
Allister MacLeod <amacleod@xxxxxxxx> | http://amacleod.is-a-geek.org/
Elen síla lúmenn'omentielvo.