<\body> API> When programming extensions of , it may be useful to be conscious of the internal architecture of the modules inside (see figure ). ||>|gr-mode||gr-fill-color|black|gr-line-width|1ln||||>>||||>>||||||>>||||||>>| routines from glue|>>| language|>>|>>|>>|||>>|||>>|||>>|||>>|||>>||>>||>>||>>||>>||>>||||>>||||>>||||>>||||>>||||>>||||>>||||>>||||>>||||>>|>>|>>||>>||>>||>>|||>>|||>>|||>>|>>>>|Schematic organization of the API.> commands> On the very basic level, one has the standard language, with some enhancements by the implementation (these extensions are used as least as possible, for future portability). The standard language is enriched by some routines implemented in the C++ part of and exported to via the glue. If you unpacked the source code of in >, then you can find a full list of the routines exported by the glue in the files /src/Guile/Glue/build-glue-base.scm \ \ \ /src/Guile/Glue/build-glue-editor.scm \ \ \ /src/Guile/Glue/build-glue-server.scm> and further utilities> Above the standard language and the extra routines from the glue, comes with a second level of language extensions, utilities and libraries. The corresponding files can be found in the directories \ \ \ $TEXMACS_PATH/progs/utils> Roughly speaking, the functionality provided by this second level is the following: <\itemize> A certain number of frequently used , like for . General language extensions for , , -specific language extensions for the definition of , , Additional routines for content manipulation|overview-content.en.tm> and pattern matching. Further utilities and libraries for common types like strings and lists. Whereas the modules in are automatically loaded, all modules in have to be explicitly included. The remaining extensions of are regrouped into which usually correspond to a particular type of content. For instance, the directories \ \ \ $TEXMACS_PATH/progs/math \ \ \ $TEXMACS_PATH/progs/table> respectively contain routines for editing source code, mathematics and tables. Exceptions are the internal modules and , which rather correspond to a particular type of functionality. Each internal module corresponds to a group of files, each of which corresponds to an individual module>. The internal modules are designed to be as independent as possible. From the point of view, the structure of a plug-in is very similar to that of an internal module. Each plug-in defines a collection of programs in its subdirectory. Although distinct plug-ins may in principle depend on each other, they are usually designed in a way which makes them as independent as possible.