Item #12 of https://tex.stackexchange.com/a/148734/18401 suggests that LaTeX3 maybe has something for patching (or appending code to) commands, à la etoolbox or xpatch. Is it the case?

  • No, and it won't. – egreg Nov 28 '14 at 18:43
  • xpatch by "someone" is written in expl3 code, so I would have thought that was the answer, except that you mention it in the question? – David Carlisle Nov 28 '14 at 18:44
  • @egreg OK. Does it mean it is still advised to make use of etoolbox or xpatch with LaTeX3? – Denis Bitouzé Nov 28 '14 at 18:45
  • @egreg Why is that? – Manuel Nov 28 '14 at 18:46
  • 3
    One of the ideas behind LaTeX3 is that there will be layers between the user and the kernel. Patching commands is usually done for changing the final output, but in LaTeX3 this will be easier by using templates or similar devices. A package that patches kernel function would be disastrous. – egreg Nov 28 '14 at 20:49

A big defect of the current version of LaTeX is that it mixes several levels into one. The reason is of course that it was written when computer memory was small, so efficiency was very important.

Patching commands has been very common in packages or document: in the olden days of LaTeX2.09 one of the most often used tricks was to redefine \document in order to append instructions to it. A consequence was that many packages (or style options, as they were called) were incompatible with each other, because they assumed the standard definition for \document.

The status of things improved with LaTeX2e, where some hooks were provided for common tasks. Now, consider \chapter as defined in book.cls.

% book.cls, line 360:

Instead of absorbing the arguments and then use them for subsequent tasks, the command issues some typographic instructions and does some non typographic settings. Only after this it looks at the arguments, via either \@chapter or \@schapter. If you look at the definition of \@chapter, you'll see that several instructions belonging to different levels are performed and finally the typesetting of the chapter heading is delegated to \@makechapter.

Packages are full of redefinitions of macros, either those given in other packages or in classes, but even of kernel macros!

Redefining kernel macros is the main source for package incompatibilities. If a package redefines \@array (there's one that does), no package that trusts on this macro to have its usual definition will work. Some packages will rely on the array package that's an “official” extension to the LaTeX kernel, but loading that other package will make them not work.

The fact is that \@array does several jobs that, in an ideal world, should belong to several different functions. So levels are respected and adapting a feature would not mean changing the whole setup.

The etoolbox package brings the concept to the extreme. The author of biblatex found himself in the need of adapting many functions in classes and in the kernel for his purposes. This is because the kernel hardwires several aspects of bibliographic data management in a few macros, again with levels intermixed. So he introduced some helper macros for making macro patching easier, avoiding the need of copying whole chunks of code and also helping maintenance of his code.

The LaTeX3 project aims to have a very clear distinction among levels. For instance, separating typesetting instructions from interface creation.

So, a \cite command at the user's level will not directly interact with the programming level. There will be a “command interface” for absorbing the arguments (think to xparse), then these arguments can be passed to a “document interface” where some decisions will be made according to well defined templates: a package for bibliographic data management will define its own templates. Actual typesetting instructions will be issued at a still different level, based on these templates and using the lowest level functions provided by expl3.

Such an approach (read Frank Mittelbach's papers on TUGboat for a clearer view on the subject) will make the old method of patching commands obsolete. Much more hooks will be available with the help of the “template” abstraction.

Of course one can always look at the definition of a kernel function and modify it. Such a practice is obviously discouraged. No patching function will be provided by default, because patching should become useless.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.