Lines: 42
References: <CAMVYejDKyWdZ1QpjKGKTHhw-wV5pQi2EQV_OzBqAF9Fgxa1uqQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: 40tude_Dialog/2.0.15.41de
Message-ID:  <8t4qihf0fz0p.dlg@nililand.de>
Date:         Mon, 26 Oct 2015 14:09:03 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Ulrike Fischer <news3@NILILAND.DE>
Subject: Re: Spaces in l3keys keys
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Am Sat, 24 Oct 2015 16:20:01 +0200 schrieb Manuel Blanco:

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

Personally I would like it if spaces wouldn't matter. While it makes
keys names easier to memorize when they contains spaces it makes it
more difficult to type them correctly (and in an expl3 context one
always had to remember to type "x~tick"). 

But a change in l3keys wouldn't affect tikz so you should perhaps
make a feature request on the pgf site.

> Are there any problems or downsides this would cause? 

You naturally loose potential key names. And there is the danger
that there is somewhere a package which relies on the current
implementation. 

Perhaps one could add a \keys_set_trimkeyspaces:nn command. 


-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/