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