[texhax] tools/3888: \bm (from bm.sty) overrides \protect

Uwe Lück uwe.lueck at web.de
Sun Sep 24 13:30:37 CEST 2006


thanks a lot for so much care with a submission that seems to
turn out to be very RTFM-like. Maybe I hadn't been in the mood
to read another item ("strange failures") in the list of "features"
of the bm package, or maybe I didn't realize that that strange
experience of mine -- and presumably of Ken's --, just instantiates
what the bm documentation warns about in exactly this subsection

(I reply somewhat late because WEB.DE put your answer
into my "unsolicited" folder.)

Now: I wonder about the status of tools/3888.
Isn't "open" entirely wrong now? Shouldn't it be "closed"
or so? Maybe accompanied with another pointer to the
documentation and a hint to put curly braces {...}
around difficult inputs? Maybe with our correspondence here?

-- /A related point:/ I am happy that the original author of /xspace/
replies here. The present discussion seems to have arisen
from an attempt -- posted to texhax -- to use \xspace in an
argument of \bm. Ken, who posted the original query, reports
that my suggestion to replace \xspace by a version that
first tests whether one is outside math mode indeed works well.
Since user-inserted spaces don't affect spacing in math mode
anyway, I'd suggest to /redefine/ \xpace about as follows:

     \renewcommand{\xspace}{\ifmmode \else \expandafter \yspace \fi}



At 23:20 21.09.06, David Carlisle wrote:

>>I consider this a bug since short math things (involving \bm) may appear 
>>in section titles and may involve some assigning macros.
>bm needs to get "into" the definition of commands in order to find out 
>what fonts are being used, and to switch to bold.
>The mechanism used is inherently unsafe as the latex \protect mechanism 
>wasn't really designed to allow this, however bm
>is designed to work for a range of cases that at least cover the main font 
>If you put complicated code directly inside bm then it may fail , and 
>\protect doesn't  recover in this case,. As noted in the doc, you should 
>always be able to
>surround the code with an extra {..} as bm never goes into brace groups 
>(it uses a different mechanism for groups, essentially that of amslatex 
>% \subsection{Strange failures}
>% In order to get the correct spacing, |\bm| has to `investigate' the
>% definition of the commands in its argument. It is possible that
>% some strange constructions could `confuse' this investigation.
>% If this happens then \LaTeX\ will almost certainly stop with a strange
>% error. This should not happen with any of the math symbols
>% defined in the base \LaTeX\ or AMS distributions, or any commands
>% defined in terms of those symbols using normal \LaTeX\ math
>% constructs. However if some command does fail to work inside |\bm|
>% you should always be able to surround it with an extra set of braces
>% |\bm{{\cmd}}| rather than |\bm{\cmd}|. |\bm| will not then attempt
>% to set the correct spacing, so you may need to set it explicitly,
>% for instance, for a relation, |\bm{\mathrel{\cmd}}|.
>So, sorry I think I need to put this down as an unfortunate but probably 
>unavoidable feature rather than a bug,

More information about the texhax mailing list