Re: [code] [textadept] Removing language-specific context menus

From: Mitchell <m.att.foicica.com>
Date: Fri, 23 Jan 2015 14:29:44 -0500 (EST)

Hi Ryan,

On Thu, 22 Jan 2015, Ryan Pusztai wrote:

> Hi Mitchell,
>
> On Jan 22, 2015 8:53 PM, "Mitchell" <m.att.foicica.com> wrote:
>>
>> Hi Ryan,
>>
>> On Thu, 22 Jan 2015, Ryan Pusztai wrote:
>>
>>> Hi Mitchell,
>>>
>>> On Jan 22, 2015 8:08 PM, "Mitchell" <m.att.foicica.com> wrote:
>>>>
>>>>
>>>> Hi Ryan,
>>>>
>>>>
>>>> On Thu, 22 Jan 2015, Ryan Pusztai wrote:
>>>>
>>>>> Hi Mitchell,
>>>>>
>>>>> On Thu, Jan 22, 2015 at 4:23 PM, Mitchell <m.att.foicica.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Background: Textadept allows language-specific modules to define a
>>>>>> language-specific context menu:
>>>>>>
>>>>>> _M[lang] = {
>>>>>> ... menu ...
>>>>>> }
>>>>>>
>>>>>> Whenever that language is loaded, that right-click context menu is
> used
>>>>>> instead of Textadept's default one. This was put in place long ago
>>>
>>> because
>>>>>>
>>>>>> there was no easy way to edit a menu without completely redefining it.
>>>
>>> For
>>>>>>
>>>>>> a while now Textadept has allowed users to edit
>>>>>> `textadept.menu.context_menu`, etc. directly as Lua tables. In my
>>>
>>> opinion,
>>>>>>
>>>>>> this effectively eliminates the need for the above feature. (If a
>>>>>> language-module wants to add language-specific features to the context
>>>>>> menu, it can do so without destroying any edits another
>>>
>>> language-specific
>>>>>>
>>>>>> module has made.)
>>>>>>
>>>>>> Unless anyone has any particularly strong objections, this change will
>>>
>>> be
>>>>>>
>>>>>> committed soon.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I am currently a user of this and I edit 2 or more languages during a
>>>>> session with TA.
>>>>> Are you proposing to just add things to the menu for each language and
>>>
>>> grow
>>>>>
>>>>> the menu for each file with a different language?
>>>>>
>>>>> Here is an example of a Lua, Python, C++, Perl file all loaded at the
>>>
>>> same
>>>>>
>>>>> time:
>>>>>
>>>>> Undo
>>>>> Redo
>>>>> -----------
>>>>> cut
>>>>> copy
>>>>> paste
>>>>> -----------
>>>>> Select All
>>>>> -----------
>>>>> <lua custom item1>
>>>>> <lua custom item2>
>>>>> -----------
>>>>> <c custom item1>
>>>>> <c custom item2>
>>>>> -----------
>>>>> <python custom item1>
>>>>> <python custom item2>
>>>>> -----------
>>>>> <perl custom item1>
>>>>> <perl custom item2>
>>>>>
>>>>> Would it be like this?
>>>>>
>>>>> I am not familiar with the `textadept.menu.context_menu` property, does
>>>
>>> it
>>>>>
>>>>> know TA default menu? This way when switching buffers you can get rid
> of
>>>>> the other languages items and only add the language specific items.
>>>>>
>>>>> I hope this makes sense. (I was having problems describing my
> questions)
>>>>
>>>>
>>>>
>>>> Thanks for your feedback. Something like this is what I had in mind:
>>>>
>>>> textadept.menu.context_menu[#textadept.menu.context_menu + 1] = {
>>>> title = 'Lua',
>>>> {'Autocomplete "end"', M.try_to_autocomplete_end}
>>>> }
>>>>
>>>> This would display a menu like:
>>>>
>>>> Undo
>>>> Redo
>>>> ----
>>>> ...
>>>> ----
>>>> Lua -> Autocomplete "end"
>>>>
>>>> Language modules would put something similar in their init.lua files.
>>>>
>>>> As you point out, the context menu would "grow" with each addition, so
>>>
>>> the example I gave would help "separate" functionality for each language.
>>> If you or anyone else think this is a terrible idea, please let me know.
> I
>>> honestly do not use this so I don't have a strong opinion. I'm flexible.
>>>
>>> Well I have seen this type of thing in other editors and it feels like a
>>> design detail that forces this feature and it doesn't seem like the
>>> "perfect solution" that the user would prefer.
>>>
>>> I was impressed with how the menus were just what the language offered.
>>> Plus with the sub menu idea it is further for me to click. I put things
>>> like 'make' and 'generate build files' in my menu and it is so fast and
>>> simple.
>>>
>>> I personally would like a mix. Basically like I described in my previous
>>> email. Just a reset to the default TA menu function and then I can reset
>>> and add just the stuff for the language.
>>>
>>> It is not a huge deal I just would prefer to have the menu just show
>>> language specific items.
>>
>>
>> We might be talking past each other. Essentially, I'd like to remove any
> sort of "automatic" context menu handling. Textadept will start with the
> standard "undo, redo, cut, copy, paste, select all" menu and then leave it
> alone forever.
>>
>> [Language] modules will then have the opportunity to do whatever they
> want with the context menu. They can add directly to it at the top-level
> (like you currently have), they can add submenus (like I suggested), or
> they can completely wipe it and provide a brand new one. The whole premise
> is that any context menu changes made by modules will persist. If you have
> C and Python modules that have added context menu items, those items will
> both show up for any and all open buffers.
>>
>> I hope this makes more sense. Basically, Textadept will stop managing the
> context menu and you as the developer are free to do whatever you want with
> it and your changes will persist over all buffers.
>
> I understand but is there anyway to add a reset function that returns the
> default menu? This way I can use that to basically do what it does now.
>
> I will plug into the buffer change event and 1. reset the menu 2. add my
> language specific items to the default menu. Thoughts?

When you plug into a buffer change event, simply call

   textadept.menu.context_menu = {
     {'Undo', ...},
     {'Redo', ...},
     ... etc ...
     {'custom1', ... }
   }

It sounds like you can pretty much just replace "M.context_menu" with
"textadept.menu.context_menu". Try it now and see if it works for you.

Cheers,
Mitchell

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Fri 23 Jan 2015 - 14:29:44 EST

This archive was generated by hypermail 2.2.0 : Sat 24 Jan 2015 - 06:42:28 EST