uliska
commented
5 years ago Having contemplated this a bit I think the current behaviour/handling should be changed (sigh, but better now than later ...).
There must be one table Templates, the one stored in the gobal variable lua_templates. Any client (document or package) receives a new, “inherited” table with lua_templates as its metatable. Through this it can access all elements of Templates and its own additions.
The current __index function should be abolished. There is no need to access the fields of the Builtins table, instead everything that is intended to be shared should be published as a “formatter”. This also serves as a kind of namespace protection -- sort of “private members”.
Also the four-track structure with shorthands, styles, templates and formatters should be dropped. These are by now technically identical, and it is dubious to add that complexity for reasons not everyone will agree with.
Instead there is one root Templates._formatters. When registering a new client with \setupLuaTemplates this is given a name (say: 'manual' in the luatemplates.tex document). This will now not only be used to create the global variable manual_templates but also to create the client toplevel node Templates._formatters.manual. This will be the root where a client's formatters are hooked into, and also where the namespace and format lookup will start. A formatter at CONFIG.templates.literature.book will then be stored at Templates._formatters.manual.literature.book.
When a formatter is looked for with format() first the object's own subtree is searched (because most often the requested formatter will be in there, then the subtree for builtin formatters, and finally the subtrees for all registered clients - in the order of their addition to the main object (keep an array with these names in the main table to have the order ready). I think there should be a way to also address a formatter in a specific subtree (say you know that package XY provides that formatter you can directly call it), e.g. by passing a two-element array holding the toplevel name and the key instead of the key as a string.
This way any client can access formatters from any other client while still having its own private fields only accessible to itself.
Through this we can do without the namespace complexity. When walking over a tree the determination whether a given node is a namespace node or a formatter entry must by now be made through the presence of the f field (with the implication that f must never be used as a namespace node). Also, we don't have the problem of different clients having a different namespace.
Before the initial release it should be decided how a Templates instance can interact with other instances.
Consider one package/document using
luatemplatesand another as well. Or one package that wants to use functionality (in the Lua domain, not only the macros) from another. There has to be a way for one object to communicate with the other.Some ideas:
Templatesobject with the "parent" in setup. Extend the__indexfunction to look into all registered "children". Special consideration has to be taken with shadowing existing formatters. This should be optionally possible or prohibited.formatfunction. This sounds less intrusive and more in line with the package's design. Same about shadowing, though.