Re: [Kicad-developers] Reverse parsing for spaces

[Wayne Stambaugh]

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

Re: [Kicad-developers] Reverse parsing for spaces

[hauptmech]

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.


\ 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  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

Re: [Kicad-developers] Reverse parsing for spaces

[Jeff Young]

> My beef with % encoding is that it is not human readable.

I won’t argue with that.  It’s a struggle at best.


> On 16 Feb 2018, at 21: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  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

Re: [Kicad-developers] Reverse parsing for spaces

[Wayne Stambaugh]

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

Re: [Kicad-developers] Reverse parsing for spaces

[Jeff Young]

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

Re: [Kicad-developers] Reverse parsing for spaces

[Wayne Stambaugh]

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

Re: [Kicad-developers] Reverse parsing for spaces

[Seth Hillbrand]

Hi Jeff-

I was working on that but just got slammed at work, so there's been less
time for testing/fixing all of the places where it touches.  But there's a
three-day weekend coming up here in the states, so I'm hopeful (eternally
so) that there will be sufficient time to complete it.

That said, if you're casting about I'm happy to send along my partial work
if it helps you.

-S

2018-02-16 12:32 GMT-08:00 Jeff Young :

> 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