Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t9OEMFxj005843 for ; Sat, 24 Oct 2015 16:22:16 +0200 Received: from relay2.uni-heidelberg.de ([129.206.119.212]) by mx-ha.gmx.net (mxgmx011) with ESMTPS (Nemesis) id 0MB2pw-1ZiKDF3SJo-00A0no for ; Sat, 24 Oct 2015 16:22:10 +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 t9OEK9uZ015970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Oct 2015 16:20:09 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t9NM13dO010569; Sat, 24 Oct 2015 16:20:09 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 12805680 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 24 Oct 2015 16:20:08 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t9OEK8CB002129 for ; Sat, 24 Oct 2015 16:20:08 +0200 Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t9OEK2eB031221 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 24 Oct 2015 16:20:05 +0200 Received: by obbwb3 with SMTP id wb3so113901997obb.0 for ; Sat, 24 Oct 2015 07:20:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=M3YAtQlRIKsq4tWVbKjMM9GYT3TVsKYRVwQYlmVhwF4=; b=fn4AhLc6egnDib980roY8bhSUmLr9fbx2USsSr4QxX6JF1Lkt48El6EhGnCzasR2YK VyZRp48M+GYtyeu4bB/kFHXuI+mR++EF1BQgGGhORbNTy4D02g4HWuUL9IXbuIyF04oK UpN4v1aoUvH6Aowccb0nJ3X7IlHy2mIQJzbfrjXZtTSJhROYwLNqwJQV8y5KYHymSkQm w4EQTSP9hVDmFBkXkKAcODTYVKRMlIzMgarCnAcT7WCCfmFm+FX6f6PYWJBPt8GwKxlQ 1oQ1+1/xsEQm5YPV+ENT0NUm9DnaEc264ZLicT4hXP3LDsd5x4+PGPp14VnqQgIE9xol HxpA== X-Gm-Message-State: ALoCoQlwvpJdHrl0nAA0yXtMnIiOBanMVCs4ZSbx64zCrsDPhhHfxDqF/1DkwfQk/DzZOIXkFdMv MIME-Version: 1.0 X-Received: by 10.182.16.226 with SMTP id j2mr19500749obd.4.1445696402026; Sat, 24 Oct 2015 07:20:02 -0700 (PDT) Received: by 10.202.105.1 with HTTP; Sat, 24 Oct 2015 07:20:01 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id t9OEK8CB002130 Message-ID: Date: Sat, 24 Oct 2015 16:20:01 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Manuel Blanco Subject: Spaces in l3keys keys To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-MIME-Autoconverted: from 8bit to quoted-printable by relay2.uni-heidelberg.de id t9OEK9uZ015970 Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:31ikbIGevCk=:OzEHbhCEHsIDJJpAf4yDH1/ik5 u1rjWtpALoZNM9itd9NBeDFcEr3uHklj632IcAPDlDTCQcO7Euz5/PNF5cES6mk3nY19ffRH0 DcWFGCbmnEQGLztTY0AQvSkqwXAZ0YC+XcAQuEU2H08aaV2QlMRSvo3RhE2iz9z01YgOBsH6L jpPUfkbIUaYsgOfWpjh7qzQtvNMhL+Evh+9bM12Gt/2jHinzAsLQj1YTNBp8Abu4mqbluVG3H F/57DpZWz6rFdcWACL7DqYkk51DMdH4ynn7L9ixTM8RBu666RAYVCRC11vbwCEkgwRSjSlYqJ ehuhd+82R3kDHuFiFAmTWr3ofbjP5g8aoidF5/DGNQvpYHwPgRrYT63mbXYB6Rec34oyrfATj PSShZzXoQqHNjdhjHwc4C0qAnjzub1sOPupbaG5x/2/aUVTRVm1Zcs7rADlAsrClllaqU9fmE L6Yd3XMySQ8ujp6z+HDTJ9V9AhV9gEgyLyGuAanOLVYyZdLpqWBDUp+2tgkSN6fV0QK4fGp0Y Be5fbBqrxJzWydcKn3uHAKk4f0r7oVNE82y62f2BmTmB6CcI6WT/G2QFs8Tb7UkIXAsdq70Lw iyOFTjGMoiMxSmhAUjEDTlOHAf2eZmjiRKTl1jUp055YKfYvJ4Nkgp7vwKumdfoXQqLu9BWnC T01KunGut0KwzUV9zWrZFaooZlwzdEDQjrTBpIL8O6qB/xCPuDITf4kAWMMhvpfx7fmTY0EyY gslDqPlKUemB1LqfMs3Hfo3aKvaStZYV3lcmAYlFDGYGTsgoB+GEcSSZ+iKV0nlEWyEC4iOX5 a3xTqkaYeewkIVvxUMkLCce9Gj4C4n9xCGmxrCkj+6jThPNW0GCBwwOgxnp8mc9xT6kCVZoQU u6LG61LoEpWEKQo9OH2cCxHTUcTX1LddnNKdDmxoIqarvG7tmrXGuwRe16LVr9OCsXhEijR+L +oS8r71j6/ZO0c3Ja+WCkJ+kN9SjOKkYnaGmuRLZ9+auLrfP1ykNeKDaanPCKYrluqiZ7rThh pe8pOoP8NpzCZ0YqjKQPAwpz/fcxHMS9lE9BJIPEyK91XknBDejKGnedi087I/c+urUbFLcxq nIBKolmXwy70+VUpQaGEAp5lpL+pdQ8H2iCOU21Dw5N8mOaqRQNMC9U9OgykA+nAYsKqFrFsb SyaLeRjohe0GH6MalVdQfFx+YRq3kOdZq1v+41aDH5d5E2THA/mIfzHDwE7ed4QlX9rQtxyKo m5tosJ5TyFo3DbBl89tDcb6KIYDHMHYpOOWQvEGzsY+EGzjwB6/DUtPIOXGoUe6r5lgIsKJw+ 1fOPbCT1pU52AsMckwArJoTSOCvBdqgor5oerBF7aec1ewpAGTdRJmfoBQg4R2Z+2qtC+pY3Z 5JHC4a5iqcnhBEpZ1bvZ5e/E9YMYMKtF5x8d3zWsPZW/DFutGqEcz3wN/H4EL39A1v7kpXfOI wSp4RbtbPoXUeN4JBoBYV3Pebjdybq76IrKUifMRmM0s8uGJ+YtBjQ8FtdSWBE6ZSLd8Dr3aO ucB/nutM0NvSYhSCVmaA= X-UI-Loop:V01:DtC3me5Lj30=:SPyZn4jjUU6v5cb/9LqlEi2lkUQSsHW2dsR0UvG2pbA= X-UI-Out-Filterresults: notjunk:1;V01:K0:4GX5yhtzkL4=:jDUMFFR88Indd0vGIFdovs 4oLMd+9buLfYBwlfFY9RKNy1ZYQ3IN2dhT0MwPhzim35pL50KqEw4I5cJ3m9R0F3TZBTnBKHy Z1/GryzZ8/gYA4B6jMwmjacIk+VTqmVySrg/zfQ5HQ8qNSVhMtT/w+KXB9uEvV7nGSPPhfhSz L+JpQro2KG/J3/091ftcbvNsRjG1q+juBBN4664jjOrR6mLTSK7yiqfjTGvckZZcNtoT2pl3Y 1uSu/XHNur7nm3EjV4bkykq1ZsTIvxDmI/7i9Tz28GthPzVs76o/1QU5tqMgDYSYwyBPc4YBG AqCtBLgxiCry1B7g7bjvR55fgWLtM19v640KQGXKg/keYCR8M88rf40ntnmRiDSGvfCSSRBZ8 oOboI9t3TgGJXQ+SWI7078wpCTZosoa3h01AeGz89LabwzV8imIRw2AXF5rybA08NzBZFoZ2X j5Mj68tVZsE4SE5QXkvwP8/ymLyQJLcszCh+DEca0yxachtE3ecCfGsnVXXd8M049XqoclCbt Vx2bMbJWOeySQlHLLM1jRJMC8L2qHOG0jIFMwn4Utdy X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by h1439878.stratoserver.net id t9OEMFxj005843 Status: R X-Status: X-Keywords: X-UID: 7900 Hello list, Regarding l3keys, has it been considered the idea of ignoring whitespace in keys? I think it would be a good idea, adds flexibility and presents practically zero problems. If there's a key defined [do this=true] or [align at=0pt], it's almost sure that the user or package author hasn't defined [dothis=true] or [alignat=0pt] to do different things. And if they have defined, I think the L3 Team can put that in the list of "don't do this" and it wouldn't be a bad decision. That implies that spaces are probably not really relevant in key names, so why not remove them all? That would ease the use of keys, would let users choose the way to input of keys, and would probably help those who struggle to remember keys in large packages (e.g., TikZ / pgfpplots [xtick] vs. [x tick], [x tick labels] vs. [xtick labels] vs. [xticklabels], etc.). Are there any problems or downsides this would cause? May be I'm missing something, but it sounds all perfect to me. There would be some small things to take in account, but I think it would be good. --- In any case, somewhat related but not much, here's an annoying behaviour. \keys_define:nn { foo } { unknown .code:n = { [\l_keys_key_tl] } } \keys_set:nn { foo } { \key } that prints [\key ] with a weird space at the end of \key. I know it's a “side effect” of \detokenize but still it's a bit annoying. (1) Spaces are trimmed from the key (i.e., [ foo = bar] => "foo" is the key, not " foo "), (2) spaces are usually gobbled after control sequences. So it's weird that [ foo =bar] gives "foo" as the key and [\foo=bar] gives "\foo " with a trailing space. What could be done? Does trimming spaces *after* \detokenize would do any harm? (May be to \tl_set_rescan:?) If not possible to remove, you could add a note to the manual so it's not a surprise. Manuel