Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id o8I92M1M016030 for ; Sat, 18 Sep 2010 11:02:23 +0200 Received: (qmail 14498 invoked by alias); 18 Sep 2010 09:02:17 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 18 Sep 2010 09:02:17 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx070) with SMTP; 18 Sep 2010 11:02:17 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id o8I90xmJ028162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Sep 2010 11:01:00 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id o8HN2dYr020290; Sat, 18 Sep 2010 11:00:41 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 438810 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 18 Sep 2010 11:00:41 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id o8I90fCQ003827 for ; Sat, 18 Sep 2010 11:00:41 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id o8I907HN016421 for ; Sat, 18 Sep 2010 11:00:11 +0200 Received: from morse.mittelbach-online.de (p3EE3F804.dip.t-dialin.net [62.227.248.4]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MY20C-1PIlk51B5M-00UrlM; Sat, 18 Sep 2010 11:00:37 +0200 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 8262F6472C; Sat, 18 Sep 2010 11:00:34 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4C93A430.1020103@morningstar2.co.uk> <20100917180303.GA7348@oberdiek.my-fqdn.de> <19603.49961.484432.456512@morse.mittelbach-online.de> <4C93DCDA.3010707@morningstar2.co.uk> <19604.28880.24959.737588@morse.mittelbach-online.de> <4C9473D3.1030903@morningstar2.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:nQ2/1ysfta+7w6faTxQi7PLgjEgvWCu+9jFNd7flm+g GXjaXTpJXwK/ecgZpUZ8FhlwJbQzo4jxalPlTHWX6cHkieZl1g eJ4bIBeqQMr5SqBRDSvB7olkq2iVCj2amAb6fQTXfREh5UXLiy 3+neamMLymw2BwTHUHuUVVvnRcosjaEYDbsqpEMODhSs/jlxVz lHAoh2CmQUhpEcUEDpn8w== X-Spam-Whitelist-Provider: Message-ID: <19604.32690.377127.814320@morse.mittelbach-online.de> Date: Sat, 18 Sep 2010 11:00:34 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Option parsing bug or 'feature'? To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4C9473D3.1030903@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p6i75npGen84eVAEFK/syJmAVhAT3mu30VXXBXVubWw5QTKyWVvBu5v+7fbk 2WURP2W/wkmw19y9Ejp5Znp38PV00hlwJxZB/ig130NWiZ37CATwM/wL8F8pqDqlDaBYO79O0tQH bq4FA==V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6406 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