Re: [textadept] Modifications to language modules

From: Robert <ro....at.web.de>
Date: Wed, 1 Jun 2011 22:29:33 +0200

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'.

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/usertags')
end

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, 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.

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).

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.

Renaming the _USERHOME tags and api files is probably a simple
solution? See the attached diff.
Maybe this requires more experimenting and thinking about, so probably
in the next version? Sorry for choosing a bad time for a discussion
like this :-)

Robert

Received on Wed 01 Jun 2011 - 16:29:33 EDT

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