Bei Befehlen mit Argument funktioniert das Anhängen von Code an den Befehl nur, wenn der Befehl sein Argument selbst liest. Wird das Argument hingegen von einem Unterbefehl gelesen, so wird der angehängte Code stattdessen ganz oder teilweise zum Argument. Beispiel: \documentclass{article} \usepackage{xpatch} \newcommand*{\textformatierung}{\textbf} \xapptocmd{\textformatierung}{+++}{}{} \begin{document} \textformatierung{Der Text soll fett werden.} \end{document} Erzeugt kein fettes `Der »`Der Text soll fett werden.` werden.`« gefolgt von drei Pluszeichen, sondern nur ein fettes `+` »`+`« gefolgt von zwei nicht fetten `+`, »`+`«, gefolgt von einem nicht fetten `Der »`Der Text soll fett werden.`. werden.`«. Sieht man sich die aus dem `\xapptocmd` resultierende Definition mit Hilfe von `\show\textformatierung` an, wird auch klar, woran das liegt: >`> \textformatierung=macro: >->\textbf +++.` Demnach ist `\textformatierung` jetzt wie \newcommand*{\textformatierung}{\textbf+++} definiert, was auch genau der Spezifikation von `\xpatchcmd` entspricht. Damit ist `{Der »`{Der Text soll fett werden.}` werden.}`« nicht einmal mehr ein Argument von `\textbf` (oder `\textformatierung`), sondern einfach nur eine Gruppe mit dem Text als Inhalt. Bei `\part` ist es sogar noch etwas komplizierter. Diese Anweisung muss noch vor dem Lesen des ersten Arguments testen, ob ein Stern folgt, was prinzipiell so geschieht: \newcommand*{\part}{\@ifstar {\@spart}{\@part}} Hängt man hier mit `\xpatchcmd` Code an, dann prüft `\@ifstar` nicht mehr, ob nach `\part` ein Stern folgt, sondern ob das erste Token dieses angehängten Codes ein Stern ist, bevor es die weiteren Token des angehängten Codes teilweise als Argument von `\@spart` oder `\@part` verwendet. Da man ohne Kenntnisse der Definition eines Befehls nie wissen kann, ob er seine Argumente selbst auswertet oder nicht, muss man mit diesem Problem grundsätzlich rechnen. Bei Befehlen, die eine Sternform besitzen, gibt es das Problem grundsätzlich. Bei `\xpretocmd` kann ein solches Problem dagegen nie auftreten.auftreten. Dasselbe Problem betrifft übrigens auch `\apptocmd` von `etoolbox` und ähnliche Befehle.

Bei Befehlen mit Argument funktioniert das Anhängen von Code an den Befehl nur, wenn der Befehl sein Argument selbst liest. Wird das Argument hingegen von einem Unterbefehl gelesen, so wird der angehängte Code stattdessen ganz oder teilweise zum Argument. Beispiel: \documentclass{article} \usepackage{xpatch} \newcommand*{\textformatierung}{\textbf} \xapptocmd{\textformatierung}{+++}{}{} \begin{document} \textformatierung{Der Text soll fett werden.} \end{document} Erzeugt kein fettes `Der Text soll fett werden.` gefolgt von drei Pluszeichen, sondern nur ein fettes `+` gefolgt von zwei nicht fetten `+`, gefolgt von einem nicht fetten `Der Text soll fett werden.`. Sieht man sich die aus dem `\xapptocmd` resultierende Definition mit Hilfe von `\show\textformatierung` an, wird auch klar, woran das liegt: >`> \textformatierung=macro: >->\textbf +++.` Demnach ist `\textformatierung` jetzt wie \newcommand*{\textformatierung}{\textbf+++} definiert, was auch genau der Spezifikation von `\xpatchcmd` entspricht. Damit ist `{Der Text soll fett werden.}` nicht einmal mehr ein Argument von `\textbf` (oder `\textformatierung`), sondern einfach nur eine Gruppe mit dem Text als Inhalt. Bei `\part` ist es sogar noch etwas komplizierter. Diese Anweisung muss noch vor dem Lesen des ersten Arguments testen, ob ein Stern folgt: folgt, was prinzipiell so geschieht: \newcommand*{\part}{\@ifstar {\@spart}{\@part}} Hängt mir man hier mit `\xpatchcmd` Code an, dann prüft `\@ifstar`, `\@ifstar` nicht mehr, ob nach `\part` ein Stern folgt, sondern ob das erste Token dieses angehängten Codes ein Stern ist, bevor es die weiteren Token des angehängten Codes teilweise als Argument von `\@spart` oder `\@part` verwendet. Da man ohne Kenntnisse der Definition eines Befehls nie wissen kann, ob er seine Argumente selbst auswertet oder nicht, muss man mit diesem Problem grundsätzlich rechnen. Bei Befehlen, die eine Sternform besitzen, gibt es das Problem grundsätzlich. Bei `\xpretocmd` kann ein solches Problem dagegen nie auftreten.

Bei Befehlen mit Argument funktioniert das Anhängen von Code an den Befehl nur, wenn der Befehl sein Argument selbst liest. Wird das Argument hingegen von einem Unterbefehl gelesen, so wird der angehängte Code stattdessen ganz oder teilweise zum Argument. Beispiel: \documentclass{article} \usepackage{xpatch} \newcommand*{\textformatierung}{\textbf} \xapptocmd{\textformatierung}{+}{}{} \xapptocmd{\textformatierung}{+++}{}{} \begin{document} \textformatierung{Der Text soll fett werden.} \end{document} Erzeugt kein fettes `Der Text soll fett werden.`, werden.` gefolgt von drei Pluszeichen, sondern nur ein fettes `+` gefolgt von zwei nicht fetten `+`, gefolgt von einem nicht fetten `Der Text soll fett werden.`. Sieht man sich die aus dem `\xapptocmd` resultierende Definition mit Hilfe von `\show\textformatierung` an, wird auch klar, woran das liegt: >`> \textformatierung=macro: >->\textbf +.` +++.` Demnach ist `\textformatierung` jetzt wie \newcommand*{\textformatierung}{\textbf+} \newcommand*{\textformatierung}{\textbf+++} definiert, was auch genau der Spezifikation von `\xpatchcmd` entspricht. entspricht. Damit ist `{Der Text soll fett werden.}` nicht einmal mehr ein Argument von `\textbf` (oder `\textformatierung`), sondern einfach nur eine Gruppe mit dem Text als Inhalt. Bei `\part` ist es sogar noch etwas komplizierter. Diese Anweisung muss noch vor dem Lesen des ersten Arguments testen, ob ein Stern folgt: \newcommand*{\part}{\@ifstar {\@spart}{\@part}} Hängt mir hier mit `\xpatchcmd` Code an, dann prüft `\@ifstar`, ob das erste Token dieses angehängten Codes ein Stern ist, bevor es die weiteren Token des angehängten Codes teilweise als Argument von `\@spart` oder `\@part` verwendet. Da man ohne Kenntnisse der Definition eines Befehls nie wissen kann, ob er seine Argumente selbst auswertet oder nicht, muss man mit diesem Problem grundsätzlich rechnen. Bei Befehlen, die eine Sternform besitzen, gibt es das Problem grundsätzlich. Bei `\xpretocmd` kann ein solches Problem dagegen nie auftreten.

Bei Befehlen mit Argument funktioniert das Anhängen von Code an den Befehl nur, wenn der Befehl sein Argument selbst liest. Wird das Argument hingegen von einem Unterbefehl gelesen, so wird der angehängte Code stattdessen ganz oder teilweise zum Argument. Beispiel: \documentclass{article} \usepackage{xpatch} \newcommand*{\textformatierung}{\textbf} \xapptocmd{\textformatierung}{+}{}{} \begin{document} \textformatierung{Der Text soll fett werden.} \end{document} Erzeugt kein fettes `Der Text soll fett werden.`, sondern nur ein fettes `+` gefolgt von einem nicht fetten `Der Text soll fett werden.`. Sieht man sich die aus dem `\xapptocmd` resultierende Definition mit Hilfe von `\show\textformatierung` an, wird auch klar, woran das liegt: >`> \textformatierung=macro: >->\textbf +.` Demnach ist `\textformatierung` jetzt wie \newcommand*{\textformatierung}{\textbf+} definiert, was auch genau der Spezifikation von `\xpatchcmd` entspricht. Bei `\part` ist es sogar noch etwas komplizierter. Diese Anweisung muss noch vor dem Lesen des ersten Arguments testen, ob ein Stern folgt: \newcommand*{\part}{\@ifstar {\@spart}{\@part}} Hängt mir hier mit `\xpatchcmd` Code an, dann prüft `\@ifstar`, ob das erste Token dieses angehängten Codes ein Stern ist, bevor es die weiteren Token des angehängten Codes teilweise als Argument von `\@spart` oder `\@part` verwendet.