[PD] Hide backslash escapes in symbol atoms

[Antoine Rousseau]

the discussion is there: https://github.com/pure-data/pure-data/issues/824
I've just closed this issue yesterday...

I personally didn't encounter any problem with the new behavior.
I think it would be weird if the symbol atom hid the backslash while the
list atom did not.

Antoine


Le jeu. 18 nov. 2021 à 16:26, Alexandre Torres Porres <porres at gmail.com> a
écrit :

> I remember that discussion (I can try and find it) and I remember people
> agreed symbol box should hide "\".
>
> I guess I can agree to that. In my idea, we know what's coming out of a
> symbol box, it's a symbol, so if you have a symbol with a space, then we
> know that the space is 'escaped' (that is, we're not splitting this into
> two atoms).
>
> But I think print should keep it, in the same way we also need to keep it
> for message boxes.
>
> Outside the context of a symbol box, it is important to differentiate if
> we have, for instance, a list where one of the items contains an escaped
> space.
>
> like, the message:
>
> | list one\ item two <
>
> has two atoms "one item" and "two", and print should be able to tell us
> that.
>
> Now, I don't know about the new list box. What if we want to create a list
> with an escaped space? It seems like a special and different case/context
> of a symbol box. By the way, I've been testing it and it seems we can do
> this by putting the escaped character ourselves. That seems correct. But it
> would be different than the symbol box and maybe I guess it shouldn't be
> too problematic that the symbol box also shows escaped characters. They're
> not that common and we can document why this happens when it happens.
>
> cheers
>
> Em qui., 18 de nov. de 2021 às 11:42, Roman Haefeli <reduzent at gmail.com>
> escreveu:
>
>> Hi all
>>
>> It's just a cosmetic thing, nevertheless it concerns me.
>>
>> Up to 0.50, usage of whitespaces in symbol atoms was good. As in:
>> Whitespaces could be used while typing into symbol atoms and the
>> displayed value showed only the whitespaces without the backslashes for
>> escaping them, while saving symbols containing whitespaces in text
>> would add the backslashes as a way to preserve the symbol for next
>> read.
>>
>> Since 0.51, things regarding backslashes are quite messy. Backslashes
>> are hidden in iemgui labels, but displayed in symbol atoms and print
>> output. There is/was an issue about that on Github which I'm unable to
>> spot right now that contained a lengthy discussion about the pros and
>> cons of the current (imho: messy) situation.
>>
>> I don't quite understand if the change between 0.50 and 0.51 was
>> intentional or simply a side effect of other fixes. However, I would
>> very much prefer to get the old behavior back.
>>
>> I propose to distinguish the FUDI-encoded value from the FUDI-decoded
>> value. As long as the message is FUDI-encoded - I write it down to a
>> file or I send through the network - the backslashes should be kept.
>> However, when I decode the FUDI message, for instance, when I take a
>> symbol from a message and display it with a symbol atom, the backslash
>> should not be displayed, since I want to display the decoded value.
>> Otherwise there is no way to ever get back the decoded value.
>>
>> I'm not sure about [print], but considering it already skips the 'list'
>> selector for lists starting with a number or the 'float' selector for
>> number messages, I consider it to display the decoded value and thus it
>> should display symbols without backslash escaping.
>>
>> Roman
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211118/80e0105a/attachment-0001.htm>