Re: [textadept] Key commands in menu

From: mitchell <c....at.caladbolg.net>
Date: Fri, 29 Jul 2011 11:10:04 -0400 (Eastern Daylight Time)

Robert,

After poking more into your code, this is pure genius. Creating unique
string representations of functions and tables is a phenominally good
idea. Please pursue this idea; I want it in the beta. I can also try to
work with it on my own.

mitchell

On Thu, 28 Jul 2011, Robert wrote:

> Hi Mitchell,
>
> On Wed, Jul 27, 2011 at 8:05 PM, mitchell <c....at.caladbolg.net> 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 buffer.save 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 textadept.at.googlegroups.com.
> To unsubscribe from this group, send email to textadept+unsubscribe.at.googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/textadept?hl=en.
>
>

mitchell
Received on Fri 29 Jul 2011 - 11:10:04 EDT

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