Re: [textadept] Key commands in menu

From: mitchell <>
Date: Fri, 29 Jul 2011 10:56:15 -0400 (Eastern Daylight Time)


I'm rubbing my eyes at what I see because it looks too good to be true! I
was skeptical just looking at the patch, but when I applied it, there was
magic. I'm still thinking that I've done something wrong in applying the
patch, but if not this looks quite promising. Are the 'stylistic' issues
you mention just where to put the extra functions?


On Thu, 28 Jul 2011, Robert wrote:

> Hi Mitchell,
> On Wed, Jul 27, 2011 at 8:05 PM, mitchell <> wrote:
>> Hi Robert,
>>> Having two different ways of defining key commands is just something
>>> that I would find weird when explaining/recommending TA to others
>>> (which I do often) - that's why I keep
>>> asking about it :-)
>> Believe me, I would love to have menu.lua read from _G.keys if possible.
>> Sure the little problems could be hammered out, but I have a few big
>> problems with adding shortcuts to the menu text:
>> �* There would be a lot of code necessary to decipher the shortcut into
>> � �the 'Ctrl', 'Shift', 'Alt', etc. modifiers to create the standard
>> � �'Ctrl+N' shortcut we are all familiar with (instead of 'cn').
>> �* Should the shortcuts be localized? (I'd rather have GTK do all that
>> � �behind the scenes).
>> �* It's ugly to have the shortcut right next to the text. We're used to
>> � �having the shortcuts on the right, much easier to separate from menu
>> � �text. Using tabs as separators will still result on mis-aligned
>> � �shortcuts because of variable shortcut string length and localized
>> � �menu item string length.
>> �* I don't even know if Mac OSX glyphs can appear in menu item text.
>> � �Those users are used to the glyphs instead of reading
>> � �'Cmd+Shift+Alt+A'.
>> I realize that current ta users are probably used to the shortcuts and/or
>> keychains defined throughout 3.x and back into 2.x. Therefore they may want
>> to redefine keys to match the keychains they're used to and find it strange
>> that there are two places to do so.
>> I don't know what else to say. There are tradeoffs that come with
>> implementing something static with ta's dynamicity.
>> mitchell
> thanks for you detailed reply. I might have found a way to display
> keyboard short cuts in the menu, using the separate field and not
> requiring any conf files.
> This is, again, a proof-of-concept (I hope at least). There are lots
> of minor (stylistic) issues that would need to be cleaned up, but
> before working more or on it, I'd like to hear what you think about
> it. Probably all the little helper functions in keys.lua should be
> defined in editing.lua or other files. Another idea I had was to call
> the "menuitem" function only in "read_menu_table",
> and have only tables in the menubar table. That way the creation of
> the shortcut lookup
> table could be done when calling "read_menu_table", now it needs
> to be done before the calls to "menuitem".
> I had to include additional buffer functions assignments (in gui.lua),
> similar to what is done with and other Lua functions.
> Otherwise it was not possible to create identical string
> representations for these buffer functions. An alternative would be
> the older string based approach. I also moved "Select command" to
> gui.lua, this could of course be done in a much cleaner way, but for
> now it works.
> Robert
> --
> You received this message because you are subscribed to the Google Groups "textadept" group.
> To post to this group, send email to
> To unsubscribe from this group, send email to
> For more options, visit this group at

Received on Fri 29 Jul 2011 - 10:56:15 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 12:04:12 EST