LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 18 Jul 2013 09:02:53 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
text/plain (27 lines)
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

ATOM RSS1 RSS2