Re: [code] [textadept] Required Modules

From: Mitchell <>
Date: Thu, 15 Aug 2019 08:52:24 -0400 (EDT)

Hi Qwerky,

On Wed, 14 Aug 2019, Qwerky wrote:

> Hi Mitchell,
> On 2019-08-14 15:06, Mitchell wrote:
>> Hi Qwerky,
>> On Wed, 14 Aug 2019, Qwerky wrote:
>>> Hi Mitchell,
>>> On 2019-08-14 14:24, Mitchell wrote:
>>>> Hi Qwerky,
>>>> On Wed, 14 Aug 2019, Qwerky wrote:
>>>>> Hi.  If the user init.lua requires a module [foo = require('foo')] which
>>>>> has
>>>>> a function 'bar', is that module and its function then available to all
>>>>> other
>>>>> modules?
>>>>> So, in keys.lua, can one write 'keys.ab ='?  Or, does 'foo' need
>>>>> to
>>>>> be required in keys.lua, as well as every other module which uses
>>>>> ''?
>>>> It depends.
>>>>> From your *~/.textadept/init.lua*, the statement:
>>>>   foo = require('foo')
>>>> defines a global variable `foo` that, from this point forward in
>>>> Textadept's init process, is available to all code that comes after
>>>> (including required modules). However, any modules loaded prior to that
>>>> statement (such as *~/.textadept/modules/textadept/keys.lua*) can access
>>>> global `foo` from within functions (not at top-level file scope).
>>>> In your case for *keys.lua*, you'd probably need `keys.ab =
>>>> require('foo').bar` since it's at top-level file scope and Textadept
>>>> loads
>>>> that before your *~/.textadept/init.lua*.
>>>> I hope this makes sense.
>>>> Cheers,
>>>> Mitchell
>>> Yes, it does make sense; thanks for a good explanation.  That fits my
>>> experience, where keys.lua gave an error on that key binding /unless/
>>> 'foo'
>>> was required, even though it was required in init.lua.
>>> What I am trying to accomplish, is key bindings within keys.lua, that do
>>> not
>>> fail with an error when the module containing the function is not loaded;
>>> they simply do not have any effect.
>>> So, I tried a global variable within 'foo' (foo_loaded), and then in
>>> keys.lua:  'keys[foo_loaded and 'ab'] =', so that if 'foo_loaded'
>>> does not exist, the key binding should do nothing. But this also gave an
>>> error, even when 'foo' was required in keys.lua.
>>> And, having to require 'foo' within keys.lua also gives an error when
>>> 'foo'
>>> does not exist; whereas when it is required in init.lua via the
>>> /modules/common/ directory and code, there is no error when the module
>>> isn't
>>> there.
>>> So, a way to fail silently when a module doesn't exist, is what I'm
>>> looking
>>> for.
>>> If the binding 'keys[foo_loaded and 'ab'] =' is within a function
>>> within keys.lua, then it should work?  So then the question is, how does
>>> one
>>> get a function within a module, to execute when the module is loaded?
>> You can query `package.loaded['foo']`. It will return a truthy value if the
>> module has been loaded, and `nil` if the module hasn't been loaded.
>> You can also do `if not pcall(require, 'foo') then ... end` which would
>> catch a require error without propagating it.
>> Cheers,
>> Mitchell
> Using Control-E followed by ui.print(package.loaded['foo']) gives 'true' for
> 'keys', but 'nil' for 'menu', 'init', and every other module I tried (with
> variations, such as 'menu.lua', etc.).

You need the full module name, as if you were requiring it yourself:


> Placing this code in keys.lua:
> if pcall(require, 'common/foo') then
>   keys['ab'] = bar
> else
> end
> causes the binding to work when 'foo' is there, and to fail silently when it
> is not.  That's great; part way there.  The problem is that it requires the
> path, so it won't work if the user placed 'foo.lua' as 'modules/foo/init.lua'
> rather than 'modules/common/foo.lua'.
> Still not sure how to cause a function within a module, to be executed when
> the module is loaded?

You need to do this manually, after loading the module. There isn't a 'module loaded' event.

Sorry if I'm not following your use case. It seems rather complex.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Thu 15 Aug 2019 - 08:52:24 EDT

This archive was generated by hypermail 2.2.0 : Fri 16 Aug 2019 - 06:29:12 EDT