LATEX-L Archives

Mailing list for the LaTeX3 project


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
1.0 (1.0)
text/plain; charset=us-ascii
Thu, 18 Jul 2013 15:56:18 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
Chris Rowley <[log in to unmask]>
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (44 lines)

>>  Until we actually have the basics of a new format, 

A new format???

That sounds worrying as I am passing the message to the million+ everyday users of LaTeX that there will never again be a need for different 'formats' with all its technical and sociological problems, primarily because they are handy only for last century's technology levels.

So I hope we can have a consistent message on this.


Sent from a bar . . . maybe an iBar.

On 18 Jul 2013, at 09:02, Joseph Wright <[log in to unmask]> wrote:

> On 17/07/2013 19:27, Joel C. Salomon wrote:
>> Joseph Wright <joseph.wright@...> writes:
>>> At present I'm waiting to see what people thing of the code-level stuff.
>>> At the same time, I'm not sure about making package option processing
>>> too complex. The lesson I've learned is that keyval in options is
>>> governed by the LaTeX2e kernel: options are expanded, and checking for
>>> clashes doesn't 'know' about keyval. Thus I tend to think load-time
>>> options should really be limited to things that need to happen there,
>>> with later \<thing>setup to cover more complex option sets.
>> Is the behavior of package & class options expected to be different 
>> (specifically, keyval-aware) in a LaTeX3 kernel?  If so, would it be 
>> appropriate to define \UseExplPackage et al. so that the future behavior can 
>> be experimented with?
>> --Joel
> Not really worthwhile. The way that the LaTeX2e kernel does option
> processing means that expansion/space stripping happens 'early'. As
> such, you can't alter it in a way that is easy. Look at the option
> keyval-patching code in xkeyval and kvoptions to see this: you have to
> pre-load an additional package before the one where you want 'new'
> effects. Until we actually have the basics of a new format, this isn't
> going to help.
> -- 
> Joseph Wright