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
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
(now sending to list)
On Thu, 2021-11-18 at 18:21 +0100, Antoine Rousseau wrote:
the discussion is there: https://github.com/pure-data/pure-data/issues/824
Thanks for the link.
I've just closed this issue yesterday...
I see, I didn't check for closed issues.
I personally didn't encounter any problem with the new behavior.
I still cannot follow why it was changed in the first place (in 0.51). Either it was wrong all along before (up to 0.50), or what we have now is a regression.
I think it would be weird if the symbol atom hid the backslash while the list atom did not.
Actually, I find it weird now. Naturally, list atom and symbol atom would have different behaviour since space has a meaning for lists while it means nothing for symbols. For symbols it's simply a character like any other.
Roman
seems the behaviour of list box is a bit weird... if I type "hey, wassup?", print gives me "list hey , wassup?". That is, the unescaped ',' character comes out as one of three elements and unescaped. That doesn't seem like a legal character, and it did blow up Pd when using my [else/display] abstraction.
It is different than having a message with "list hey , wassup?", which gets printed as such on the terminal window.
what do you people make of it?
cheers
Em qui., 18 de nov. de 2021 às 15:25, Roman Haefeli reduzent@gmail.com escreveu:
(now sending to list)
On Thu, 2021-11-18 at 18:21 +0100, Antoine Rousseau wrote:
the discussion is there: https://github.com/pure-data/pure-data/issues/824
Thanks for the link.
I've just closed this issue yesterday...
I see, I didn't check for closed issues.
I personally didn't encounter any problem with the new behavior.
I still cannot follow why it was changed in the first place (in 0.51). Either it was wrong all along before (up to 0.50), or what we have now is a regression.
I think it would be weird if the symbol atom hid the backslash while the list atom did not.
Actually, I find it weird now. Naturally, list atom and symbol atom would have different behaviour since space has a meaning for lists while it means nothing for symbols. For symbols it's simply a character like any other.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK Roman and Christof, after some reflection I think now you are right, to assume different behaviors for different contexts!
is accepted);
has to be escaped;
addition to filter the keyboard input to only numeric characters in the "number" context?...)
Antoine
Le jeu. 18 nov. 2021 à 19:23, Roman Haefeli reduzent@gmail.com a écrit :
(now sending to list)
On Thu, 2021-11-18 at 18:21 +0100, Antoine Rousseau wrote:
the discussion is there: https://github.com/pure-data/pure-data/issues/824
Thanks for the link.
I've just closed this issue yesterday...
I see, I didn't check for closed issues.
I personally didn't encounter any problem with the new behavior.
I still cannot follow why it was changed in the first place (in 0.51). Either it was wrong all along before (up to 0.50), or what we have now is a regression.
I think it would be weird if the symbol atom hid the backslash while the list atom did not.
Actually, I find it weird now. Naturally, list atom and symbol atom would have different behaviour since space has a meaning for lists while it means nothing for symbols. For symbols it's simply a character like any other.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 11/19/21 10:02, Antoine Rousseau wrote:
- in a float atom, no space at all is allowed... (BTW wouldn't it be a nice
addition to filter the keyboard input to only numeric characters in the "number" context?...)
what's a "numeric character"?
- in a list atom, space is the delimiter, so if you want an actual
space it has to be escaped;
i'm not really sure about this to be honest. i agree that there should be a visual distinction between the atom delimiter and the sapce (within a symbol).
intuitively i would prefer something less ugly than '\ ', e.g. "␣". but what if the user actually wants the character "␣"?
probably the best would be to have delimiters a display property of the list-box, rather than of the text itself. as in the attached mockup.
dmgfsr IOhannes
what's a "numeric character"?
I guess [0123456789.e] ?
Le ven. 19 nov. 2021 à 11:51, IOhannes m zmoelnig zmoelnig@iem.at a écrit :
On 11/19/21 10:02, Antoine Rousseau wrote:
- in a float atom, no space at all is allowed... (BTW wouldn't it be a
nice
addition to filter the keyboard input to only numeric characters in the "number" context?...)
what's a "numeric character"?
- in a list atom, space is the delimiter, so if you want an actual
space it has to be escaped;
i'm not really sure about this to be honest. i agree that there should be a visual distinction between the atom delimiter and the sapce (within a symbol).
intuitively i would prefer something less ugly than '\ ', e.g. "␣". but what if the user actually wants the character "␣"?
probably the best would be to have delimiters a display property of the list-box, rather than of the text itself. as in the attached mockup.
dmgfsr IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
intuitively i would prefer something less ugly than '\ ', e.g. "␣".
As I've written elsewhere: as simple rule could be "show what you type". In a list box (and many other objects) you have to explicitly type '' to get a whitespace inside a symbol, so I think it's also fine to display it as such.
probably the best would be to have delimiters a display property of the list-box, rather than of the text itself.
But what about object boxes, comments, [text] etc.? They all follow the same rules regarding whitespace (the user has to explicitly escape it).
The only exception are cases where you are dealing with a single symbol: symbol atoms and since Pd 0.52 also all GUI object lables resp. send/receive symbols. Here it doesn't make sense to show the escape character as it is really an implementation detail and doesn't add any value to the end user. It just looks ugly.
Christof
On 19.11.2021 11:51, IOhannes m zmoelnig wrote:
On 11/19/21 10:02, Antoine Rousseau wrote:
- in a float atom, no space at all is allowed... (BTW wouldn't it be
a nice addition to filter the keyboard input to only numeric characters in the "number" context?...)
what's a "numeric character"?
- in a list atom, space is the delimiter, so if you want an actual
space it has to be escaped;
i'm not really sure about this to be honest. i agree that there should be a visual distinction between the atom delimiter and the sapce (within a symbol).
intuitively i would prefer something less ugly than '\ ', e.g. "␣". but what if the user actually wants the character "␣"?
probably the best would be to have delimiters a display property of the list-box, rather than of the text itself. as in the attached mockup.
dmgfsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On Thu, 2021-11-18 at 12:26 -0300, Alexandre Torres Porres wrote:
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).
Yeah, it definitely should keep the symbol intact. But that to make sure is an issue of the FUDI encoding. I don't type backslash escapes and I also do not want them to be displayed. The backslashes are not part of the payload, unless I type them explicitly.
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.
Yeah, that's the FUDI encoding of a list containing two symbols.
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.
Yeah, obviously list boxes are for lists and symbol boxes for symbols. I think for list boxes to be effective they need to show the FUDI encoded value, which means displaying the escaping character.
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.
Yes, it is, imho, it is dead-ugly and confuses the distinction between payload and encoding. I'm pretty happy that Python doesn't only print "b'Z\xc3\xbcrich'" when I intend to print "Zürich".
They're not that common and we can document why this happens when it happens.
That would be confusing things even more.
Roman
I completely agree with Roman here.
The space character in a list box has a different function than in a symbol box.
In a symbol box it will always be part of the symbol. Also, it can be typed as is. I really don't see a need to display the escape character here. On the contrary, I often use symbol boxes to display strings, and I find this behavior quite irritating.
In a list box, a space is used to seperate atoms. If you want to embed a space in one of the symbol atoms, you explicitly have to type "\ ". Unsurprisingly, the escape character is also displayed. The same thing applies to message boxes. There is a semantic difference between an ordinary space and an escaped space.
I think we could apply a simple rule: display what the user has typed.
Christof
On 18.11.2021 18:33, Roman Haefeli wrote:
On Thu, 2021-11-18 at 12:26 -0300, Alexandre Torres Porres wrote:
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).
Yeah, it definitely should keep the symbol intact. But that to make sure is an issue of the FUDI encoding. I don't type backslash escapes and I also do not want them to be displayed. The backslashes are not part of the payload, unless I type them explicitly.
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.
Yeah, that's the FUDI encoding of a list containing two symbols.
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.
Yeah, obviously list boxes are for lists and symbol boxes for symbols. I think for list boxes to be effective they need to show the FUDI encoded value, which means displaying the escaping character.
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.
Yes, it is, imho, it is dead-ugly and confuses the distinction between payload and encoding. I'm pretty happy that Python doesn't only print "b'Z\xc3\xbcrich'" when I intend to print "Zürich".
They're not that common and we can document why this happens when it happens.
That would be confusing things even more.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list