kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <stambaughw@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp