The module system and lazy definitions

As explaned above, each Scheme file inside TeXmacs or one of its plug-ins corresponds to a TeXmacs module. The individual TeXmacs modules are usually grouped together into an internal or external module, which corresponds to a directory on your hard disk.

Any TeXmacs module should start with an instruction of the form

The name of the module is a list which corresponds to the location of the corresponding file. More precisely, TeXmacs searches for its modules in the path $GUILE_LOAD_PATH, which defaults to the standard Guile load path, combined with $TEXMACS_PATH/progs and all progs subdirectories in the plug-ins. For instance, the module (math math-edit) corresponds to the file

    $TEXMACS_PATH/progs/edit/math-edit.scm

The user should explicitly specify all submodules on which the module depends, except those modules which are loaded by default, i.e. all language extensions and utilities in the directories

    $TEXMACS_PATH/progs/kernel

    $TEXMACS_PATH/progs/utils/library

All symbols which are defined inside the module using define or define-macro are only visible within the module itself. In order to make the symbol publicly visible you should use tm-define or tm-define-macro. Currently, because of implementation details for the contextual overloading system, as soon as a symbol is declared to be public, it becomes visible inside all other modules. However, you should not rely on this: in the future, it explicit importation with :use might become necessary.

Because the number of TeXmacs modules and plug-ins keeps on growing, it is unefficient to load all modules when booting. Instead, initialization files are assumed to declare the provided functionality in a lazy way, so that the corresponding modules will only be loaded when the functionality is explictly needed. Some modules may also be loaded during spare time, when the computer is waiting for user input.

For instance, assume that you defined a large new editing function foo-action inside the module (foo-edit). Then your initialization file init-foo.scm would typically contain a line

Similarly, lazy keyboard shortcuts and menus for foo might be defined using

For more concrete examples, we recommend the user to take a look at the standard initialization file init-texmacs.scm.

On the negative side, the mechanism for lazy loading has the important consequence that you can no longer make assumptions on when a particular module is loaded. For instance, when you attempt to redefine a keyboard shortcut in your personal initialization file, it may happen that the standard definition is loaded after your “redefinition”. In that case, your redefinition remains without consequence.

For this reason, TeXmacs also provides the instruction import-from to force a particular module to be loaded. Similarly, the commands lazy-keyboard-force, lazy-plugin-force, etc. may be used to force all lazy keyboard definitions resp. plug-ins to be loaded. In other words, the use of lazyness forces to make implicit dependencies between modules more explicit.

In the case when you want to redefine keyboard shortcuts, the contextual overloading system gives you an even more fine-grained control. For instance, assume that the keyboard shortcut x x x has been defined twice, both in general and in math mode. After calling lazy-keyboard-force and overriding the general definition of the shortcut, the special definition will still take precedence in math mode. Alternatively, you may redefine the keyboard shortcut using

This redefinition will prevail both in general and in math mode.