LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Thu, 13 Oct 2011 05:40:49 -0400
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
From: Bruno Le Floch <[log in to unmask]>
Parts/Attachments: text/plain (23 lines)
>> If you really thing the n/N distinction is confusing, what about a
>> "currying" mechanism whereby regexes automatically create their prebuilt
>> form and save it in an internal macro which is used for subsequent calls
>> to the same regex?
> AS you say, I don't think removing stuff is the right way forward at
> this point. The reason for raising this was to be clear that the current
> approach is the best one. Having a set of n/N functions does seem to
> require quite a lot of variants in the documentation, so I wanted to be
> clear that this is best.
> As Will says, an alternative is simply to save all regexes
> automatically, and check for the existence of the regex before building
> it. That of course costs in terms of macros, so the question is how many
> regexes are likely to be used. (We are talking about a typesetting
> system, so really this should not normally be 100s.)

You guys are right. I'll add this automatic storage this weekend, and
remove the N variants (since they will be done automatically).