MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <49A453A1.9040000@morningstar2.co.uk>
            <FB18C832-EA5E-42F0-9BF7-6853DB79B805@gmail.com>
            <49A4F031.50405@morningstar2.co.uk>
            <49A4FE4F.6040304@morningstar2.co.uk>
            <27990a880902250600v21963220v319195a504107625@mail.gmail.com>
Message-ID:  <18853.41758.364009.703166@morse.mittelbach-online.de>
Date:         Wed, 25 Feb 2009 20:59:26 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Missing expl3 primitives
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <27990a880902250600v21963220v319195a504107625@mail.gmail.com>
Precedence: list
Status: R

Will Robertson writes:
 > On Wed, Feb 25, 2009 at 6:46 PM, Joseph Wright
 > <joseph.wright@morningstar2.co.uk> 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