Mime-Version: |
1.0 |
Content-Type: |
text/plain; charset="iso-8859-1"; format=flowed |
Date: |
Sat, 25 Apr 2009 18:24:08 +0200 |
Reply-To: |
|
Subject: |
|
From: |
|
In-Reply-To: |
|
Content-Transfer-Encoding: |
8bit |
Sender: |
|
Parts/Attachments: |
|
|
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 \@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
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@{<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?
Cheers!
Uwe.
|
|
|