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?
1 Answer
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:
\newcommand\chapter{\if@openright\cleardoublepage\else\clearpage\fi
\thispagestyle{plain}%
\global\@topnum\z@
\@afterindentfalse
\secdef\@chapter\@schapter}
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.
xpatch
by "someone" is written inexpl3
code, so I would have thought that was the answer, except that you mention it in the question?etoolbox
orxpatch
withLaTeX3
?