Re: Limitations of menuselect

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 27,  6:27pm, Oliver Kiddle wrote:
} Subject: Re: Limitations of menuselect
}
} Olivier Teuliere wrote:
} > Someone told me on IRC that in menuselect a hard-coded table is used
} > to lookup the widget names.
} 
} More or less. It seems any keybinding picked up from the main keymap
} will work though menu selection is exited first. For anything from the
} menuselect keymap, it hard codes the actions with various widgets being
} overloaded from their original meanings. I'm not sure that I get the
} point of this.

At the time menuselect was added, the "local keymaps" implementation had
not yet been done.  So menuselect was implemented as a self-contained
widget (just like the incremental search widgets, etc.) that does all
its own key interpretation.

The reason for overloading widgets from the main keymap was because the
keystroke interpretation code always mapped everything directly to a
known widget object.  (I'm not sure user-defined widgets even existed
yet at that time.)  So the only way to have [say] ENTER mean one thing
in the main keymap and another in menuselect was to overload the widget
to which ENTER was mapped.

When the local keymaps were introduced, nobody ever undertook to refit
menuselect to use real widgets; it got its own keymap but the overload
implementation was never ripped out and rebuilt.

} > 3) When using the reverse-menu-complete widget to open menuselect, I
} > would like to select the last result, not the first one (otherwise I
} > can use menu-complete directly...). It doesn't sem to be possible at
} > the moment.
} 
} That seems like a bug to me.

I think it was punted as requiring too much implementation effort, given
that up-arrow from the first result in menu-selection will cycle to the
last result.
 
} It certainly makes sense and is quite thought provoking. I'm only sorry
} that my answers aren't especially helpful.

Ditto ...