Mail-Followup-To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
References: <4C93A430.1020103@morningstar2.co.uk>
            <20100917180303.GA7348@oberdiek.my-fqdn.de>
            <19603.49961.484432.456512@morse.mittelbach-online.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20100918103114.GB25082@oberdiek.my-fqdn.de>
Date:         Sat, 18 Sep 2010 12:31:15 +0200
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: Heiko Oberdiek <heiko.oberdiek@GOOGLEMAIL.COM>
Subject: Re: Option parsing bug or 'feature'?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <19603.49961.484432.456512@morse.mittelbach-online.de>
Precedence: list
Status: R

On Fri, Sep 17, 2010 at 09:36:09PM +0200, Frank Mittelbach wrote:

> Hi Heiko,
> 
>  > LaTeX2e uses \zap@space to remove the spaces in the option lists.
>  > As a side effect \zap@space also removes the braces around the
>  > comma, because the group is followed immediately after a space:
> 
> since you already looked at the different implementations, any suggestion on
> how to best improve the LaTeX2e behaviour?

Because of the frozen nature of LaTeX2e I don't expect that LaTeX2e
is/can/will improved. In the next postings you have already answered
it that way.

Example, preserving spaces in option names (with or without around
equals) will break, for instance:
  \documentclass[a4 paper, 12 pt]{documentclass}

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.

Yours sincerely
  Heiko <oberdiek@uni-freiburg.de>