<\body> As explaned above, each file inside or one of its plug-ins corresponds to a module>. The individual modules are usually grouped together into an internal or external module, which corresponds to a directory on your hard disk. Any module should start with an instruction of the form <\scheme-fragment> (texmacs-module \ \ (:use ... )) The > of the module is a list which corresponds to the location of the corresponding file. More precisely, searches for its modules in the path , which defaults to the standard load path, combined with and all subdirectories in the plug-ins. For instance, the module corresponds to the file The user should explicitly specify all submodules on which the module depends, except those modules which are loaded by default, all language extensions and utilities in the directories \ \ \ $TEXMACS_PATH/progs/utils/library> All symbols which are defined inside the module using or are only visible within the module itself. In order to make the symbol publicly visible you should use or . Currently, because of implementation details for the , 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 might becomenecessary. Because the number of 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 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 inside the module . Then your initialization file would typically contain a line <\scheme-fragment> (lazy-define (foo-edit) foo-action) Similarly, lazy keyboard shortcuts and menus for might be defined using <\scheme-fragment> (lazy-keyboard (foo-kbd) in-foo-mode?) (lazy-menu (foo-menu) foo-menu) For more concrete examples, we recommend the user to take a look at the standard initialization file |$TEXMACS_PATH/progs/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, also provides the instruction to force a particular module to be loaded. Similarly, the commands , , may be used to force all lazy keyboard definitions 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 gives you an even more fine-grained control. For instance, assume that the keyboard shortcut has been defined twice, both in general and in math mode. After calling 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 <\scheme-fragment> (kbd-map \ \ (:mode prevail?) \ \ ("x x x" )) This redefinition will prevail both in general and in math mode.