LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
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:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Uwe Lück <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
8bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
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 
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.

ATOM RSS1 RSS2