Re: [textadept] Re: Design suggestions

From: Robert <ro....at.web.de>
Date: Sat, 2 Jul 2011 19:25:52 +0200

Hi Anton,
On Sat, Jul 2, 2011 at 5:28 PM, anton <averbit....at.yandex.ru> wrote:
> ok.
> I still think that enclose_in_tag should belong to all html related
> modules.
> I think, one should always prefer cleaner design over ad hoc
> optimization.

I think TA fares quite well in this regard, I'm always amazed by Mitchell's
reorganizing and improving of the code base, even in areas where there have been
few users like internationalization (just one example from a while ago).

> Anyway, you're the Linus here.
>
> I think a good place for show_style is lexer.lua.
lexer.lua is for the separate lexer's lua state, so this might not work.

> A also think that show_recent_file_list should be in menu.lua
> in the form of Recent Files menu entry, with Recent files in submenu..
>
I agree that it would be nice to have this in the menu as well, but putting
it in menu.lua would be bad for people who don't load menu.lua at all.
There was a patch a while ago that put open buffers in the context menu, you
might start from there.

> Once again, only my opinion.

From my experience with proposing changes like this is that it's best to send
a working patch. Makes it easier for Mitchell to check out and if he doesn't
include it you can possibly turn in into a module or a wiki entry.
(If it's a bigger change it's of course a good idea to ask first.)

> anton
>
> P.S.: I haven't said anything about any_char_mt not because I agree
> that
> it should be in keys.lua but because I don't have the slightest idea
> what this
> function does ;)
>

It's a keychain to enclose something with any char:
For example alt-c c ! would enclose the word before the cursor in "!".
something --> !something!

Robert

> On 24 Jun., 18:03, mitchell <c....at.caladbolg.net> wrote:
>> Hi Anton,
>>
>> On Thu, 23 Jun 2011, anton wrote:
>> > Hallo MItchell,
>>
>> > I have some suggestions about design of run and keys modules.
>> > I suggest to divide the functionality of run into compiling and
>> > output, and to
>> > shift the output part to the corresponding language modules (i.e. cpp/
>> > init.lua , lua/init.lua and so on) In many cases the user simply wants
>> > a statusbar notification about successful compilation and a detailed
>> > error message only in case of error.
>>
>> This is a good suggestion, but I will instead have the run module emit
>> events when there is compile or run output. Language specific modules can
>> connect themselves to those events to display output in the statusbar,
>> etc.
>>
>> > The second suggestion is about keys.lua. IMHO one needs to shift
>> > functions
>> > enclose_in_tag
>> > any_char_mt
>> > toggle_setting
>> > show_recent_file_list
>> > show_style
>> > to other places like html/init.lua for enclose_in_tags,
>>
>> Tags are not just hypertext specific like Robert said. I think it's fine
>> to keep in keys.lua
>>
>> > show_recent_file_list to gui.lua.
>>
>> This is not core functionality. I admit it is strange to have in keys.lua,
>> but I'm not sure where else to put it.
>>
>> The other functions you mention are fine to stay in keys.lua I think, but
>> I'm open to more concrete suggestions.
>>
>> mitchell
>>
>> > I think this will make a clearer design.
>>
>> > My opinion is highly subjective.
>>
>> > anton
>>
>> > --
>> > 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 athttp://groups.google.com/group/textadept?hl=en.
>>
>> mitchell
>
> --
> 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.
>
>
Received on Sat 02 Jul 2011 - 13:25:52 EDT

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