Re: [textadept] Re: Design suggestions

From: mitchell <c....at.caladbolg.net>
Date: Mon, 4 Jul 2011 14:53:22 -0400 (EDT)

Hi,

On Sun, 3 Jul 2011, anton wrote:

> ok, thanks.
> as always the first thoughts is usually not the best ones.
>
>
> one more thing, quotes (') are doubled by default.
> What does one use to type short forms (e.g. I'm, don't) in English?

Either turn off _m.textadept.editing.AUTOPAIR or press ' followed by
'delete' :)

mitchell

>
>> 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).
> Agree completely and absolutely. That's basically the reason why I
> started this thread.
> The design of TA is remarkably clear and orthogonal so those function
> in keys.lua annoy
> my perfectionist nature. Anyway.
>
> anton
>
> On 2 Jul., 19:25, Robert <ro....at.web.de> wrote:
>> 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 athttp://groups.google.com/group/textadept?hl=en.
>
> --
> 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 Mon 04 Jul 2011 - 14:53:22 EDT

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