Überarbeitungsverlauf[Zurück]
|
4 |
|
|
Ein bisschen Hintergrund: TeXs Befehlsequenzen können entweder aus einem oder mehreren Buchstaben bestehen. Buchstaben sind Zeichen mit Kategorie-Code `11` (=letter). Oder sie können aus nur _einem_ Zeichen mit anderem Kategorie-Code bestehen. Wenn TeX jetzt auf das Escape-Zeichen `\` stößt und direkt danach ein Buchstabe folgt, wird alles bis zum nächsten Nicht-Buchstaben als Befehlsname interpretiert:
\bla123 => Befehlsname = \bla
Folgt dem Escape-Zeichen ein Nicht-Buchstabe, wird nur dieses Zeichen als Befehlsname interpretiert:
\123 => Befehlsname = \1
Das bedeutet, dass nach einer Befehlsequenz aus Buchstaben durch Nicht-Buchstaben angezeigt werden muss, wo sie aufhört. Das kann auch ein Leerzeichen sein. Warum aber wird das Leerzeichen verschluckt. Man könnte doch auch mit einer leeren Gruppe `{}` anzeigen, dass sie aufhört? Nun, weil D. E. Knuth so entschieden hat. Das explizite Eingeben einer Gruppe hätte außer der zusätzlichen Tipparbeit weitere Nachteile: sie würde mögliches Kerning unterdrücken, würde Konstrukte wie `\csname foo\endcsname` erheblich erschweren etc.
\bla bla ist bequemer als \bla{}bla und erlaubt außerdem eventuelles Kerning zwischen dem letzten Buchstaben
der Expansion von \bla und dem folgenden `bla'
Fazit: das Verschlucken von Leerzeichen nach Befehlssequenzen aus Buchstaben muss man einfach akzeptieren.
Was kann man machen, wenn man eine Befehlssquenz hat und möchte folgende Leerzeichen nicht unterdrücken? Vier Möglichkeiten. Die traditionelle Lösung ist eine der folgenden:
\bla{} bla
\bla\ bla
Man kann -- wie topskip schon erwähnt hat -- auch auf das Paket [`xspace`][1] von David Carlisle zurückgreifen:
\usepackage{xspace}
\newcommand*\bla{bla\xspace}
jetzt geht auch \bla bla
Dazu folgendes Caveat [von David Carlisle persönlich][2]:
> I originally implemented `xspace` a long
> time ago (for LaTeX 2.09) as, like
> most LaTeX beginners, I'd had a
> document where I had omitted a `{}` or `\`
> and so had a missing space in the
> final document.
>
> The original version used a very
> simple nested test for following
> punctuation, but it could get the test
> wrong in some (well rather a lot
> really) of cases. Morten made the
> tests a lot better so the current
> version makes the correct choice in
> more cases and is more easily
> customised) however making the tests
> more complicated highlights the
> problem with this kind of package.
>
> The rule in TeX is really quite
> simple, after a command name that uses
> letters (as opposed to single
> character command names using
> non-letters such as `\$`) white space is
> ignored. It is easy to forget to use `\`
> or `{}` but the result of forgetting is
> very predictable, you lose white space
> in the result. Conversely with `xspace`
> the macro will get the correct space
> most of the time, but it isn't easy to
> predict when it will get it wrong, and
> so it's much harder to learn to enter
> the markup in a way that is always
> correct rather than having to always
> visually check for missing space,
> which rather negates the purpose of
> the command.
>
> So, if you find it useful, fine, it's
> there. But personally I wouldn't
> recommend it.
Ein Beispiel, warum man mit `\xspace` aufpassen muss:
\documentclass{article}
\usepackage{xspace}
\newcommand*\bla{bla\xspace}
\begin{document}
\bla -- hoppla! -- blubber
\end{document}
![alt text][3]
Als vierte Möglichkeit wird oft manchmal empfohlen, den Befehl mit einem sogenannten _begrenzten_ Argument zu definieren. Der Vorteil ist, dass man eine Fehlermeldung bekommt, wenn man den Begrenzer vergisst:
\newcommand*\bla{} % nur, um nicht einen vorhandenen Befehl zu überschreiben
\def\bla/{bla}
\bla/ bla
\bla bla => gibt jetzt eine Fehlermeldung
Allerdings habe ich nicht nie gesehen, dass das jemand tatsächlich verwendet.
[1]: http://www.ctan.org/pkg/xspace
[2]: http://tex.stackexchange.com/a/86620/5049http://tex.stackexchange.com/a/86620/5049
[3]: http://texwelt.de/wissen/upfiles/xspace.png
|
|
3 |
|
|
Ein bisschen Hintergrund: TeXs Befehlsequenzen können entweder aus einem oder mehreren Buchstaben bestehen. Buchstaben sind Zeichen mit Kategorie-Code `11` (=letter). Oder sie können aus nur _einem_ Zeichen mit anderem Kategorie-Code bestehen. Wenn TeX jetzt auf das Escape-Zeichen `\` stößt und direkt danach ein Buchstabe folgt, wird alles bis zum nächsten Nicht-Buchstaben als Befehlsname interpretiert:
\bla123 => Befehlsname = \bla
Folgt dem Escape-Zeichen ein Nicht-Buchstabe, wird nur dieses Zeichen als Befehlsname interpretiert:
\123 => Befehlsname = \1
Das bedeutet, dass nach einer Befehlsequenz aus Buchstaben durch Nicht-Buchstaben angezeigt werden muss, wo sie aufhört. Das kann auch ein Leerzeichen sein. Warum aber wird das Leerzeichen verschluckt. Man könnte doch auch mit einer leeren Gruppe `{}` anzeigen, dass sie aufhört? Nun, weil D. E. Knuth so entschieden hat. Das explizite Eingeben einer Gruppe hätte außer der zusätzlichen Tipparbeit weitere Nachteile: sie würde mögliches Kerning unterdrücken, würde Konstrukte wie `\csname foo\endcsname` erheblich erschweren etc.
\bla bla ist bequemer als \bla{}bla und erlaubt außerdem eventuelles Kerning zwischen dem letzten Buchstaben
der Expansion von \bla und dem folgenden `bla'
Fazit: das Verschlucken von Leerzeichen nach Befehlssequenzen aus Buchstaben muss man einfach akzeptieren.
Was kann man machen, wenn man eine Befehlssquenz hat und möchte folgende Leerzeichen nicht unterdrücken? Vier Möglichkeiten. Die traditionelle Lösung ist eine der folgenden:
\bla{} bla
\bla\ bla
Man kann -- wie topskip schon erwähnt hat -- auch auf das Paket [`xspace`][1] von David Carlisle zurückgreifen:
\usepackage{xspace}
\newcommand*\bla{bla\xspace}
jetzt geht auch \bla bla
Dazu folgendes Caveat [von David Carlisle persönlich][2]:
> I originally implemented `xspace` a long
> time ago (for LaTeX 2.09) as, like
> most LaTeX beginners, I'd had a
> document where I had omitted a `{}` or `\`
> and so had a missing space in the
> final document.
>
> The original version used a very
> simple nested test for following
> punctuation, but it could get the test
> wrong in some (well rather a lot
> really) of cases. Morten made the
> tests a lot better so the current
> version makes the correct choice in
> more cases and is more easily
> customised) however making the tests
> more complicated highlights the
> problem with this kind of package.
>
> The rule in TeX is really quite
> simple, after a command name that uses
> letters (as opposed to single
> character command names using
> non-letters such as `\$`) white space is
> ignored. It is easy to forget to use `\`
> or `{}` but the result of forgetting is
> very predictable, you lose white space
> in the result. Conversely with `xspace`
> the macro will get the correct space
> most of the time, but it isn't easy to
> predict when it will get it wrong, and
> so it's much harder to learn to enter
> the markup in a way that is always
> correct rather than having to always
> visually check for missing space,
> which rather negates the purpose of
> the command.
>
> So, if you find it useful, fine, it's
> there. But personally I wouldn't
> recommend it.
Als vierte Möglichkeit wird oft eimpfohlen, eden empfohlen, den Befehl mit einem sogenannten _begrenzten_ Argument zu definieren. Der Vorteil ist, dass man eine Fehlermeldung bekommt, wenn man den Begrenzer vergisst:
\def\bla/{bla}
\bla/ bla
\bla bla => gibt jetzt eine Fehlermeldung
[1]: http://www.ctan.org/pkg/xspace
[2]: http://tex.stackexchange.com/a/86620/5049
|
|
2 |
|
|
Ein bisschen Hintergrund: TeXs Befehlsequenzen können entweder aus einem oder mehreren Buchstaben bestehen. Buchstaben sind Zeichen mit Kategorie-Code `11` (=letter). Oder sie können aus nur _einem_ Zeichen mit anderem Kategorie-Code bestehen. Wenn TeX jetzt auf das Escape-Zeichen `\` stößt und direkt danach ein Buchstabe folgt, wird alles bis zum nächsten Nicht-Buchstaben als Befehlsname interpretiert:
\bla123 => Befehlsname = \bla
Folgt dem Escape-Zeichen ein Nicht-Buchstabe, wird nur dieses Zeichen als Befehlsname interpretiert:
\123 => Befehlsname = \1
Das bedeutet, dass nach einer Befehlsequenz aus Buchstaben durch Nicht-Buchstaben angezeigt werden muss, wo sie aufhört. Das kann auch ein Leerzeichen sein. Warum aber wird das Leerzeichen verschluckt. Man könnte doch auch mit einer leeren Gruppe `{}` anzeigen, dass sie aufhört? Nun, weil D. E. Knuth so entschieden hat. Das explizite Eingeben einer Gruppe hätte außer der zusätzlichen Tipparbeit weitere Nachteile: sie würde mögliches Kerning unterdrücken, würde Konstrukte wie `\csname foo\endcsname` erheblich erschweren etc.
\bla bla ist bequemer als \bla{}bla und erlaubt außerdem eventuelles Kerning zwischen dem letzten Buchstaben
der Expansion von \bla und dem folgenden `bla'
Fazit: das Verschlucken von Leerzeichen nach Befehlssequenzen aus Buchstaben muss man einfach akzeptieren.
Was kann man machen, wenn man eine Befehlssquenz hat und möchte folgende Leerzeichen nicht unterdrücken? Drei Vier Möglichkeiten. Die traditionelle Lösung ist eine der folgenden:
\bla{} bla
\bla\ bla
Man kann -- wie topskip schon erwähnt hat -- auch auf das Paket [`xspace`][1] von David Carlisle zurückgreifen:
\usepackage{xspace}
\newcommand*\bla{bla\xspace}
jetzt geht auch \bla bla
Dazu folgendes Caveat [von David Carlisle persönlich][2]:
> I originally implemented `xspace` a long
> time ago (for LaTeX 2.09) as, like
> most LaTeX beginners, I'd had a
> document where I had omitted a `{}` or `\`
> and so had a missing space in the
> final document.
>
> The original version used a very
> simple nested test for following
> punctuation, but it could get the test
> wrong in some (well rather a lot
> really) of cases. Morten made the
> tests a lot better so the current
> version makes the correct choice in
> more cases and is more easily
> customised) however making the tests
> more complicated highlights the
> problem with this kind of package.
>
> The rule in TeX is really quite
> simple, after a command name that uses
> letters (as opposed to single
> character command names using
> non-letters such as `\$`) white space is
> ignored. It is easy to forget to use `\`
> or `{}` but the result of forgetting is
> very predictable, you lose white space
> in the result. Conversely with `xspace`
> the macro will get the correct space
> most of the time, but it isn't easy to
> predict when it will get it wrong, and
> so it's much harder to learn to enter
> the markup in a way that is always
> correct rather than having to always
> visually check for missing space,
> which rather negates the purpose of
> the command.
>
> So, if you find it useful, fine, it's
> there. But personally I wouldn't
> recommend it.
Als vierte Möglichkeit wird oft eimpfohlen, eden Befehl mit einem sogenannten _begrenzten_ Argument zu definieren. Der Vorteil ist, dass man eine Fehlermeldung bekommt, wenn man den Begrenzer vergisst:
\def\bla/{bla}
\bla/ bla
\bla bla => gibt jetzt eine Fehlermeldung
[1]: http://www.ctan.org/pkg/xspace
[2]: http://tex.stackexchange.com/a/86620/5049
|
|
1 |
|
|
Ein bisschen Hintergrund: TeXs Befehlsequenzen können entweder aus einem oder mehreren Buchstaben bestehen. Buchstaben sind Zeichen mit Kategorie-Code `11` (=letter). Oder sie können aus nur _einem_ Zeichen mit anderem Kategorie-Code bestehen. Wenn TeX jetzt auf das Escape-Zeichen `\` stößt und direkt danach ein Buchstabe folgt, wird alles bis zum nächsten Nicht-Buchstaben als Befehlsname interpretiert:
\bla123 => Befehlsname = \bla
Folgt dem Escape-Zeichen ein Nicht-Buchstabe, wird nur dieses Zeichen als Befehlsname interpretiert:
\123 => Befehlsname = \1
Das bedeutet, dass nach einer Befehlsequenz aus Buchstaben durch Nicht-Buchstaben angezeigt werden muss, wo sie aufhört. Das kann auch ein Leerzeichen sein. Warum aber wird das Leerzeichen verschluckt. Man könnte doch auch mit einer leeren Gruppe `{}` anzeigen, dass sie aufhört? Nun, weil D. E. Knuth so entschieden hat. Das explizite Eingeben einer Gruppe hätte außer der zusätzlichen Tipparbeit weitere Nachteile: sie würde mögliches Kerning unterdrücken, würde Konstrukte wie `\csname foo\endcsname` erheblich erschweren etc.
\bla bla ist bequemer als \bla{}bla und erlaubt außerdem eventuelles Kerning zwischen dem letzten Buchstaben
der Expansion von \bla und dem folgenden `bla'
Fazit: das Verschlucken von Leerzeichen nach Befehlssequenzen aus Buchstaben muss man einfach akzeptieren.
Was kann man machen, wenn man eine Befehlssquenz hat und möchte folgende Leerzeichen nicht unterdrücken? Drei Möglichkeiten. Die traditionelle Lösung ist eine der folgenden:
\bla{} bla
\bla\ bla
Man kann -- wie topskip schon erwähnt hat -- auch auf das Paket [`xspace`][1] von David Carlisle zurückgreifen:
\usepackage{xspace}
\newcommand*\bla{bla\xspace}
jetzt geht auch \bla bla
Dazu folgendes Caveat [von David Carlisle persönlich][2]:
> I originally implemented `xspace` a long
> time ago (for LaTeX 2.09) as, like
> most LaTeX beginners, I'd had a
> document where I had omitted a `{}` or `\`
> and so had a missing space in the
> final document.
>
> The original version used a very
> simple nested test for following
> punctuation, but it could get the test
> wrong in some (well rather a lot
> really) of cases. Morten made the
> tests a lot better so the current
> version makes the correct choice in
> more cases and is more easily
> customised) however making the tests
> more complicated highlights the
> problem with this kind of package.
>
> The rule in TeX is really quite
> simple, after a command name that uses
> letters (as opposed to single
> character command names using
> non-letters such as `\$`) white space is
> ignored. It is easy to forget to use `\`
> or `{}` but the result of forgetting is
> very predictable, you lose white space
> in the result. Conversely with `xspace`
> the macro will get the correct space
> most of the time, but it isn't easy to
> predict when it will get it wrong, and
> so it's much harder to learn to enter
> the markup in a way that is always
> correct rather than having to always
> visually check for missing space,
> which rather negates the purpose of
> the command.
>
> So, if you find it useful, fine, it's
> there. But personally I wouldn't
> recommend it.
[1]: http://www.ctan.org/pkg/xspace
[2]: http://tex.stackexchange.com/a/86620/5049
