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