← Back to team overview

kicad-developers team mailing list archive

Re: Reverse parsing for spaces

 

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
> 


Follow ups

References