Subject: | |
From: | |
Reply To: | |
Date: | Sat, 18 Sep 2010 09:09:55 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On 18/09/2010 08:57, Frank Mittelbach wrote:
> Joseph Wright writes:
> > On 17/09/2010 20:36, Frank Mittelbach wrote:
> > > since you already looked at the different implementations, any suggestion on
> > > how to best improve the LaTeX2e behaviour?
> >
> > I take it that this does possibly count as a bug then, rather than as a
> > 'feature'?
>
> it doesn't count as a bug I would say, for the simple reason that per
> specification the optional argument of \usepackage doesn't support a key value
> list but just a list of option names (that themselves have no spaces)
> separated by comma. Only later packages appeared that internally added
> something like keyval and manipulated the received option list from
> \usepackage as a key/val list, but that happens after \usepackage has already
> removed spaces and unfortunately in this case also the braces.
>
> pragmatic approach:
>
> you state that one needs to say ={,} to make things work as this is a fairly
> seldom issue
>
> more elaborate approach
>
> change \@pass@ptions so that it only removes spaces up front, around a comma
> and at the end
>
> problem with the latter is that the current definition of \@pass@ptions is at
> the core of what LaTeX does, ie it is used by every package and any change in
> its behaviour might result in unexpected changes somewhere.
>
> so at the moement I'm a bit reluctant to make a change on the 2e-level for the
> sake of of one very specific case unless it is fairly minimal and appears to
> be "save". But I'm open to suggestions which is why I asked
>
> frank
>
The bug as I see it is that here the code not only removes the space but
also the brace group around a single token. I assume you'd get the same with
[ word {a} word ] => 'wordaword' not 'word{a}word'
which isn't as far as I know detailed.
--
Joseph Wright
|
|
|