expl3hooks
Consider the following example, which tries to add some code to a command's hook. If I replace g__mytest_tl to simply mytest then everything works fine. Does this mean that the hook system do not support command names with underscore?
\documentclass{article}
\begin{document}
\ExplSyntaxOn
\tl_new:N \g__mytest_tl
\hook_gput_code:nnn { cmd/g__mytest_tl/after } { test }
{
Test~text
}
\tl_use:c { g__mytest_tl }
\ExplSyntaxOff
\end{document}
Instead of \everydisplay, \everymath could be used. This applies to gather as well. To avoid coloring of inline math, you could check if you are within gather or align similar to amsmath's own checks.
Complete example:
\documentclass{article}
\usepackage{amsmath,color}
\newcommand*{\eqcolor}{\color{blue}}
\makeatletter
\everymath{%
\ifingather@ \eqcolor%
\else \ifinalign@ \eqcolor
\fi
\fi
}
\makeatother
\begin{document}
\begin{gather*}
1+\cos x
\end{gather*}
\begin{align*}
1+\cos x
\end{align*}
\centering $1 + \cos x$
\end{document}
As you can see, inline math is not colored. Regarding other displayed math: instead of equation or \[ ... \] you could use gather or gather*, respectively. This could be done in the preamble, without changes to equation environments in the text, such as
\let\equation\gather
\let\endequation\endgather
Generic hooks (such as cmd hooks) are used in very specific places (cmd hooks are used when a command is called) and should not be manually used elsewhere. Nothing stops you from doing so, but that may cause confusion. Generic hooks are treated differently, since their definition (they are defined implicitly when you do \AddToHook{some/generic/hook}) to their usage (used automatically inside another command or environment), so you shouldn't use it as a normal hook.
The second option is the correct one: You create a normal hook called mypkg/something, and use it normally with \UseHook.
Also, using mypkg/somehook is a bit faster than using a generic cmd hook because the latter tries to patch a command at \begin{document}, which takes some (negligible) time, so there is no reason to misuse a generic cmd hook.
Generic cmd hooks exist for a reason, of course! Suppose you wrote a nice package for typesetting tables, and you have a command like this:
\NewDocumentCommand \MagicTable { m m }
{
\begin{tabular}{rl}
#1 & #2 \\
\end{tabular}
}
(not really impressive, I know :) and you want to, say, provide a hook for adding a header to that impressive table. If a user just did \AddToHook{cmd/MagicTable/before}{<header>}, the contents would be put outside of the tabular environment, and obviously not work. You could then provide for such users:
\NewDocumentCommand \MagicTable { m m }
{
\begin{tabular}{rl}
\UseHook{cmd/MagicTable/before}
#1 & #2 \\
\end{tabular}
}
\NewHook{cmd/MagicTable/before}
In this case, you would “make the generic hook normal”, and the hook system wouldn't try to patch the hook into \MagicTable because you already told it the hook exists (by doing \NewHook).
This example is a bit obvious because tabular material simply doesn't work outside of the tabular environment, but in other cases, the package author could fine-tune the position of the cmd/.../before and cmd/.../after hooks after people have been using such hooks.
But if you are providing new functionality that is not simply “run this bunch of code before that command”, the correct alternative is to use a normal hook name.
Best Answer
If you type
hat the error message you will get more info:Your command starts with
\g__and that marks it as private. A generic cmd-hook is a tool to change commands from another package and so by design it doesn't touch private commands.If the variable is from your package you don't need the slower hook system you can simply append the code: