It probably doesn't make much sense at this point given that the file format is going to be replaced in v6 so it will be a moot issue. I plan on quoting all strings in the new file format so spaces will pose no problem.
On 02/16/2018 06:57 PM, hauptmech wrote: > Just adding another opinion to the mix here. > > %20 does not make the current file format any more difficult to read > than it already is. The current format can be parsed by a human and > edited with a text editor. That's good, and that's all you need. > > \x20 (which is what you would use if you were to use a \ escape format > that is in wide use) is the same for readability. > > \<space> is cleaner visually but will confuse more people as there are > less tools (mostly shells) that use this escape. > > All have the potential to clash with existing files in the wild. > > If you tweak the format then you introduce file migration headaches and > issues for tools that read kicad files directly (I have a few and I > don't think I'm the only one.) > > Please just leave it as it is (no spaces) until 6. > > > > > On 17/02/18 10:17, Wayne Stambaugh wrote: >> My beef with % encoding is that it is not human readable. Human >> readability is an important goal when designing KiCad file formats. >> >> On 2/16/2018 4:04 PM, Jeff Young wrote: >>> Yeah, that’s why I was suggesting %-encoding. Substituting %20 for >>> spaces wouldn’t be a file format change. And it’s a common enough >>> escape sequence that anyone writing 3rd-party tools could easily deal >>> with it. >>> >>> I think %-encoding is probably better than ‘\’-prefixing, mostly >>> because it can also handle the space issue. >>> >>>> On 16 Feb 2018, at 20:56, Wayne Stambaugh <stambau...@gmail.com> wrote: >>>> >>>> The space issue is tricky because it's not a quoted string. Quoting >>>> the >>>> string would be a file format change although you could make the >>>> argument so is the space. >>>> >>>> I believe all of the other strings in question are quoted in the file >>>> format so it should just be a matter of quoting any special characters >>>> with a '\' character. That is what I intend to do with the LIB_ID >>>> parser and formatter after v5 is released. This will change both the >>>> schematic and board file formats. That's why I wont do this until >>>> after >>>> the new schematic file format is implemented so it will be a non issue. >>>> An easy solution is to use a validator to veto any forbidden characters >>>> from being used where applicable. >>>> >>>> The other place '/' cannot be used is in sheet names because the human >>>> readable sheet path uses '/' to separate each sheet name. I'm sure >>>> there are some other places this issue exists as well. >>>> >>>> On 2/16/2018 3:32 PM, Jeff Young wrote: >>>>> There was an issue a while back where we were considering reverse >>>>> parsing something or another so that spaces didn’t trip us up. >>>>> What’s the status of that? >>>>> >>>>> The reason I ask is that I’m looking at another bug where a user >>>>> wants to put ‘/‘ characters in their global labels (which we of >>>>> course use as a path delimiter between sheets and labels. >>>>> >>>>> In general we need to get our implementation out of the way of >>>>> users. So I was thinking about applying %-encoding to the label >>>>> case now, and perhaps rolling it out more widely in 6.0. Which >>>>> brought me to wondering if it would work for the space problem we >>>>> were having…. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : kicad-developers@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp