LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Uwe Lück <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Sat, 25 Apr 2009 18:24:08 +0200
text/plain (87 lines)
At 11:47 24.04.09, Will Robertson wrote:
>It seems that the old documentation for the
>command was also written incorrectly:
>%    |\@in| is a utility macro with two arguments.  It determines
>%    whether its first argument occurs in its second (after expanding
>%    it) and sets the switch |\if@in| accordingly.
>Unless I'm mistaken, there was no expanding going on in the old
>version; I'm going to change this accordingly.

I think the parentheses mean that the second argument *may need* expansion 
in certain applications and will be expanded indeed in such cases -- by 
other means. Indeed there are many applications in latex.ltx where some 
`\expandafter's or an \edef (also by \@expandtwoargs) expand the second 

For discussion, I am quoting the *old* definition:


At 11:25 24.04.09, Morten Høgholm wrote:
>Unless I am completely mistaken, writing a new version is a simple
>task: just make the second argument start with something that should
>not appear in input, such as a the nil marker.

I wonder what "second argument" means here -- perhaps the idea is replacing 
the last line above by


However, can we be sure that \@nil (or also \@@nil) won't be in the input?


would be safer, currently there is no \@in@ in latex.ltx, and it is natural 
not to use \in@ with \@in@ in an argument. (\in@@ cannot be used since it 
is the common delimiter, and \in@ would fail with one-token second 
arguments of \[log in to unmask])

>On 24/04/2009, at 6:51 PM, Heiko Oberdiek wrote:
>>%%% begin of fixed definition %%%
>>  \def\in@@##1#1##2\in@@{%
>>    \def\in@@{##2}%
>>    \ifx\in@@\@empty
>>      \in@false
>>    \else
>>      \in@true
>>    \fi
>>  }%
>>  \in@@#2\@nil#1\in@@
>>%%% end of fixed definition %%%

(This uses \@nil.) Putting the second split into a macro to test it against 
\@empty is safe, but one might dislike it as "slow". Other proposals need 
only the first definition of a macro, \in@@.

Heiko's proposal doesn't use \in@ in the last line that calls \in@@. This 
would allow replacing \@nil by \in@, which wouldn't introduce a new control 

My favourite tends to be replacing so-far-LaTeX's test against \in@ by a 
test on emptiness (as Heiko proposed) in a way slightly similar to ifmtarg 
(third line):


With \in@{<pattern>}{<target>}, the emptiness test is correct unless 
<pattern><copy> is in <target> where <copy> is a copy of the actual \in@@. 
The final split ##2 is non-empty iff <pattern> is in <target> or <patter> 
is in <target> where <pattern> is <patter>\[log in to unmask] (The latter case includes 
that <pattern> could be a sequence of `\in@'s where ##2 would be one \[log in to unmask])

Shouldn't there be a report on the bug database for referring to the problem?