LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sat, 18 Sep 2010 11:00:34 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
Joseph,

 > 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.

yes i guess you get that, and no there is no explicit formal statement that
the above would be the case nor is there a statement that

   [ \section ]

is not a valid input in this case.  [ And yes, there have been people who
complained that \footnote{\chapter{foo}} doesn't work and that this is not
documented, and no I don't think we will document it]

Instead the specification of \usepackage [optionlist] is that optionlist is a
list of named options separated with comma and optional spaces around the
comma. And what is acceptable as a "name" in LaTeX is fairly  well defined
though again not too formal and yes, therefore this also has boundary cases
(often producing problems if you have language  specifics like ":" being an
active char making names for labels blow etc)

Option names have no spaces and no braces and so the result of passing such
stuff is undefined (well not undefined as the behavior is deterministic, but
there can be "surprising" behaviour for boundary cases). So the result of
undefined usage doesn't classify as a bug.

So all i nall I don't think it is a bug but it is an extended usage of an
interface for something it wasn't intended for so that the boundary cases are
a bit surprising, ie

 "optionlist" will be processed so that all spaces within are removed and that
 brace groups that are surounded at the outside by spaces (or the beginning or
 end of optionlist) get the braces removed

oh well. not sure I got that fully right :-) but ...

frank

ATOM RSS1 RSS2