## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: \in@ wrong?

From:

Date:

Sat, 25 Apr 2009 18:24:08 +0200

Content-Type:

text/plain

Parts/Attachments:

 text/plain (86 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 argument. For discussion, I am quoting the *old* definition: \def\in@#1#2{% \def\in@@##1#1##2##3\in@@{%    \ifx\in@##2\in@false\else\in@true\fi}%   \in@@#2#1\in@\in@@} 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   \in@@#2\@nil#1\in@\in@@} However, can we be sure that \@nil (or also \@@nil) won't be in the input?   \in@@#2\@in@#1\in@\in@@} 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#2{% >> \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 \@[log in to unmask]) 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@@[log in to unmask] Heiko's proposal doesn't use \in@ in the last line that calls \in@@[log in to unmask] This would allow replacing \@nil by \in@, which wouldn't introduce a new control word. 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): \def\in@#1#2{%   \def\in@@##1#1##2\in@@{%    \ifx\in@@##2\in@@\in@false\else\in@true\fi}%   \in@@#2\in@#1\in@@} With \in@{}{}, the emptiness test is correct unless is in where is a copy of the actual \in@@[log in to unmask] The final split ##2 is non-empty iff is in or is in where is \[log in to unmask] (The latter case includes that 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? Cheers!      Uwe.