LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced 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
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Uwe Lück <[log in to unmask]>
Date:
Fri, 1 May 2009 11:46:17 +0200
Content-Transfer-Encoding:
8bit
Content-Type:
text/plain; charset="iso-8859-1"; format=flowed
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (26 lines)
An essential problem for \in@ are patterns containing `{...}' (with usual 
catcodes). The present approach to find a substring <pattern> by defining a 
macro that has <pattern> in its parameter text is perfectly unable to deal 
with this. At least one of stringstrings, ted, xstring *is* able to do this 
because of a very different imlementation -- analyzing tokens one by one 
and creating an "internal representation" of the <pattern>. But this is a 
heavy machinerybthat should *not* be in the LaTeX kernel -- cf.:

>Date: Wed, 29 Apr 2009 22:07:23 +0200
>From: Uwe Lück <[log in to unmask]>
>At 13:23 27.04.09, Manuel Pégourié-Gonnard wrote:
>>Heiko Oberdiek a écrit :
[solutions dealing with unbalanced \if... and #]
>>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.
[...]
>The LaTeX kernel should just provide essential things.
>A perfect bombastic substring detector is not essential.

Cheers,

     Uwe.

ATOM RSS1 RSS2