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]>
Wed, 29 Apr 2009 22:07:23 +0200
text/plain (56 lines)
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 
>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.