Re: [textadept] Modifications to language modules

From: mitchell <c....at.caladbolg.net>
Date: Wed, 8 Jun 2011 16:24:32 -0400 (Eastern Daylight Time)

Robert,

On Wed, 1 Jun 2011, Robert wrote:

> On Wed, Jun 1, 2011 at 3:19 PM, mitchell <c....at.caladbolg.net> wrote:
>>> [...]
>>>
>>> That's of course possible, but an advantage of loading
>>> ~/.textadept/modules/hypertext/user/init.lua instead of
>>> hypertext/post_init.lua
>>> is, that for modules which are installed in ~/.textadept/modules all
>>> modifications are within
>>> the 'user' sub-directory.
>>
>> After reading this again and looking at the diffs you sent in a later email,
>> your suggestion seems like another "level" of loading user changes. I would
>> claim "an advantage of loading _USERHOME instead of _HOME is that for
>> modules which are installed in ~/.textadept/modules all modifications are
>> within the _USERHOME sub-directory." -- identical to your previous statement
>> but replacing your user/ dir. I certainly see where you are coming from,
>> juggling two modules in _USERHOME space, but if someone wanted to juggle 3,
>> then another suggestion would be for loading a user/user/init.lua or
>> user2/init.lua or usern/init.lua for n > 0. At this point comes the question
>> of how best to proceed. I stand by my original suggestion of loading
>> additional user modules via post_init.lua. This makes the most sense to me:
>>
>> 1. I have my own hypertext module in _USERHOME which is different from the
>> � one in _HOME. I have modified all _HOME paths to _USERHOME in my
>> � ~/.textadept/modules/hypertext/init.lua.
>> 2. Now I want to include some fancy things from Robert's hypertext module.
>> � Rather than merging his stuff with mine (since presumably both of our
>> � versions are hg-controlled), I clone his repo into
>> � ~/.textadept/modules/hypertext/robert/ and modify his _HOME or
>> � _USERHOME paths to _USERHOME..'/modules/hypertext/robert/'. Then I
>> � create my post_init.lua file to load his module ("require
>> � 'hypertext/robert'").
>> 3. Some time later Robert fixes a bug in his module and I want to update
>> � my version. I simply go to robert/ and 'hg pull' his changes, which
>> � merge with the _HOME or _USERHOME path changes I made earlier, and I
>> � don't have to modify the same paths again.
>>
>> There may of course be a fatal flaw in my thinking. Please do point it out
>> if so.
>>
>> mitchell
>>
>
> Your description of actually having somebody's complete hypertext
> module loaded as part of your hypertext module is interesting and I
> hadn't thought of that before. One could as well load parts of another
> modules, for example snippets and get future updates as you
> describe.
>
> It could be seen that having user/init.lua would introduce another
> level of user settings, but
> isn't that the same as post_init.lua? It's just a directory instead of a file.
> Calling it 'user' might be a bad choice, as it is admittedly weird
> having a 'user' dir below
> '_USERHOME'.

Yes, but either solution is somewhat hackish and I choose post_init.lua.
It might not be the most understandable choice, but it makes sense to me.

> There is another problem with changing _HOME to _USERHOME as described
> in the docs if I prefer to install the modules in ~/.textadept: the
> names of user api and tags files need to be changed as well. How about
> 'usertags' instead of 'tags'?
> This might be a solution for having all modules installed in
> ~/.textadept until you decide to have them part of the main
> distribution.
>
> For example:
> -- Load user tags and apidoc.
> if lfs.attributes(_USERHOME..'/modules/hypertext/tags') then
> sense:load_ctags(_USERHOME..'/modules/hypertext/tags')
> end

I forgot to mention in step 1. that I also removed the above code for
loading tags and api.

> So wrapping it up:
> Having modules by default in _HOME can be problematic for
> Mac users (as it is an app bundle), they don't have (easy) access,

I will add a separate instruction for installing official modules in
_HOME since textadept.app being a folder may not be obvious to everyone.

> and
> Linux users that get TA from a package manager, admittedly (yet) not that many.
> Also, the modules need to be re-installed with each update.

Package managers will likely include official modules in _HOME so there is
no problem here.

> Changing _HOME to _USERHOME leads to not being able to do a simple 'hg
> pull' to update and the name of user api/tags files needs to be
> changed as well. (I actually use these additonal tag files).

Really? I cloned a module, replaced all instances of _HOME with _USERHOME,
removed the original "if lfs.attributes(_USERHOME...) then" for tags and
api, made a change in the original module and committed it, and then
pulled that module's changes into my modified module. Everything merged
just fine.

In my experience, hg is pretty good at merging changes with 'hg pull'.
Resolving these conflicts manually should be pretty easy though since
you're just keeping local path changes.

> Some modules (like mine) are installed in _USERHOME, the official ones
> and Brian's Javascript in _HOME. That confused me at least once :-),
> probably others as well.

There is no 'one size fits all' solution. Comfortable ta hackers can use
_HOME and handle themselves just fine when updating to a new release so
there is no need for them to write _USERHOME modules. The nature of ta is
customization so it's not surprising that some might be necessary when
adopting others' modules.

I am not big on imposing module "standards", but I am big on
documentation. Non-official modules should definately include some
comments on how and where their module should be installed. For those
writing _HOME modules, having _USERHOME paths commented out would probably
be a good idea for other users who don't want to install in _HOME.

mitchell
Received on Wed 08 Jun 2011 - 16:24:32 EDT

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