LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced 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
Mime-Version:
1.0 (Apple Message framework v1081)
Content-Type:
text/plain; charset=us-ascii
Date:
Sat, 18 Sep 2010 13:04:13 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Philipp Stephani <[log in to unmask]>
Message-ID:
In-Reply-To:
Content-Transfer-Encoding:
8bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (22 lines)
Am 18.09.2010 um 12:31 schrieb Heiko Oberdiek:

> My recommendation for package authors that use key value interfaces
> is to provide a \<package>setup command for setting the options
> and getting rid of the option limitations of LaTeX2e.
> 
> Also setting options in \usepackage makes problems with option
> clashes more likely, especially if the package is already loaded
> without options.
> 
> Another problem is that the option share the same namespace.
> Global options can trigger wanted and unwanted actions in
> different packages, that knows the same option. That's even
> more problematic for key value options, where the packages
> interprete the same keys, but the values with different syntax.

I agree.  I use the following policy for package options, which I believe is defensive enough:

- Avoid options whenever possible.
- If an option is required (e.g. if a package loads another package conditionally), always process it locally using \ProcessLocalKeyvalOptions (kvoptions) or \ProcessKeysPackageOption (l3keys2e).
- Never process global options except "standard" ones like "draft".

ATOM RSS1 RSS2