## 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? ("core")

From:

Date:

Wed, 29 Apr 2009 22:07:23 +0200

Content-Type:

text/plain

Parts/Attachments:

 text/plain (55 lines)
 At 13:23 27.04.09, Manuel Pégourié-Gonnard wrote: >Heiko Oberdiek a écrit : > >> (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". > > > > 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.