Ross Moore wrote:
However, I'm not convinced that this is the most robust way
of tackling this issue.
Should it be localised to just when linguex is used?
Here is how I think this kind of interaction-between-packages
specific kind of issue should be solved. What do you think?
\def\implementTIPAtextx#1{#1\egroup}
\def\implementTIPAtextxx#1{\endlinechar=-1 \scantokens{#1}\egroup}
\AtBeginDocument{\let\textipa\implementTIPAtext}
\expandafter\ifx\csname scantokens\endcsname\relax
\else
\atbegindocumen...@ifpackageloaded{linguex}{%
\let\implementTIPAtextx\implementTIPAtextxx}}
\fi
If everyone agrees, this is how the next subversion
of Xunicode will deal with this.
Not convinced this is optimal. Whilst linguex may be
unusual in grabbing everything up to the next \par as
#1 to \ex., there can be no guarantee that it is the
only package so to do. Therefore, rather than risk
having to add additional packages to the
\...@ifpackageloaded {linguex}
test, might it not be better to simply use \scantokens
regardless ? As to whether eTeX is buggy in its
implementation of \scantokens, I would argue not :
the documentation clearly says --
\scantokens,
when followed by a <general text>, decomposes the
> <balanced text> of the <general text> into the
> corresponding sequence of characters as if the
> <balanced text> were written unexpanded to a file;
> it then uses TeX's \input mechanism to re-process
> these characters under the current \catcode régime.
> As the \input mechanism is used, even hex notation
> (^^xy) will be re-interpreted. Parentheses and a single
> space representing the pseudo-file will be displayed
> if \tracingscantokens (q.v.) is positive and non-zero.
where the key part is "uses TeX's \input mechanism"; if it
is unclear why this yields a final space, please try
the following :
File "A" : pre\input B\relax post\end
File "B" : middle
Philip Taylor
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
