References: <20090425183703.GA2822@irwin.vpn.uni-freiburg.de>
            <20090424092120.GA7843@irwin.vpn.uni-freiburg.de>
            <5.1.0.14.0.20090421122917.02f41830@pop3.web.de>
            <455691F1-21A4-4C65-A025-7855791829F7@gmail.com>
            <20090424092120.GA7843@irwin.vpn.uni-freiburg.de>
            <5.1.0.14.0.20090425151542.032a0ce0@pop3.web.de>
            <20090425183703.GA2822@irwin.vpn.uni-freiburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <5.1.0.14.0.20090429211015.02aa1200@pop3.web.de>
Date:         Wed, 29 Apr 2009 22:07:23 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Uwe =?iso-8859-1?Q?L=FCck?= <uwe.lueck@WEB.DE>
Subject: Re: \in@ wrong? ("core")
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <49F5959F.5070104@elzevir.fr>
Precedence: list
Status: R

At 13:23 27.04.09, Manuel Pégourié-Gonnard wrote:
>Heiko Oberdiek a écrit :
> >> (This uses \@nil.) Putting the second split into a macro to test it 
> against
> >> \@empty is safe, but one might dislike it as "slow".
> >
> > I prefer "safe".
> >
>I agree.

But this is essentially limited below.

> > An expandable test could be used, e.g.:
> >   \ifx\\##2\\% or something else as \\
>
>Is it "allowed" to use e-TeX commands inside the kernel? If so,

As long as LaTeX supports \@TeXversion{2} ...

>\expandafter\ifx\expandafter\\\detokenize{##2}\\% or something else as \\
>
>is the safest test, as I'm sure you know.

In practice, there seems not be much to detokenize here, e.g., target 
strings have been generated from \meaning, cf. below.


>Anyway, depending on the intended use of \in@, certain resctrictions (such as
>"no unbalanced \if" or "no # token" or "no \@nil token" are probably 
>acceptable,
>as long as they are properly documented.

When I countered "unbalanced \if..." by "#", this rather meant the same.

\in@ is an internal facility that currently is used for processing options 
and for font selection. Concerning options, it is clear to me that the 
weakness is harmless. Concerning font selection, I just cannot afford at 
the moment checking whether the weakness can lead to a failure. when the 
second argument is expanded \alpha@list, it is quite clear that it is OK, I 
don't know about the other cases.

The LaTeX kernel should just provide essential things. A perfect bombastic 
substring detector is not essential. It may be good to fix the weakness a 
little just in order to prevent people like me from worrying about the 
matter -- and it is perhaps more straightforward to change the code than to 
explain that periodic strings are a problem.

This is also a comment on earlier ideas here what LaTeX3 might provide.

I rather consider essential an output routine that doesn't misplace 
footnote parts and marginal notes.

Cheers,

     Uwe.