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
Show All Mail Headers

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

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 25 Feb 2009 20:59:26 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
Will Robertson writes:
 > On Wed, Feb 25, 2009 at 6:46 PM, Joseph Wright
 > <[log in to unmask]> wrote:
 > > Over all, I think I prefer the first option, as these do all go
 > > together. (If we go for _every_, do we have a very short module
 > > "l3every" for this? If not, where do these things go?)
 > 
 > I think I agree with you here. And I think it would be fine to define
 > these in l3toks for lack of any better location (they're not necessary
 > "early", so it doesn't really matter, I suppose; since they're token
 > registers then putting them in toks makes sense).

well I guess I only partly agree. I don't think that at this point in time we
should provide any expl interface to these \every... other than as
\tex_every...D

I really expect all (or nearly all) of them to used in higher-level
interfaces, each in one specific module and that the low-level functionality
outside these interfaces should not be accessed at all.
This is precisely the issue that exists in LaTeX2e right now which has a very
specific use for \everypar (but only a poorly developed inferface to access it
by others. As a result packages mistakenly use \everpar directly only to find
out that they die in certain situation or produce unexpected results.

So yes, we do want a functionality like \everypar available, but if LaTeX3
implements a galley module (whether it be variant of galley2 or something
leaner like xfmgalley or ...) then this functionality will not be provided
through the primitive \everpar but through something else that fits that
model.

Same essentially for every other \every... command: "every end of file" might
be useful and should be provided, but probably not through the primitive as
the l3file might as well have something to do at the end of every file first
(hijacking that lowlevel and instead providing something else for other
packages).

as i expect kernel (or near kernel) modules for all areas that offer
\every... I would leave this alone as \tex_every_...:D for now

if it turns out that one or the other is not going to be hijacked by the
kernel we can in the end still offer it as programmer available, but not
before

frank

ATOM RSS1 RSS2