Hi
[text get] has a second outlet for the type of the message. There is a distinction between messages terminated by semicolon and messages terminated by comma.
Is there also a way to add messages of different types? I haven't found any. [text set] and [text insert] usually add messages terminated by semicolon (type 0). OK, there is [text fromlist], but I'm interested in a more granular way to edit the text buffer and add messages of different types.
Roman
Anyone?
Roman
On Tue, 2022-03-22 at 22:33 +0100, Roman Haefeli wrote:
Hi
[text get] has a second outlet for the type of the message. There is a distinction between messages terminated by semicolon and messages terminated by comma.
Is there also a way to add messages of different types? I haven't found any. [text set] and [text insert] usually add messages terminated by semicolon (type 0). OK, there is [text fromlist], but I'm interested in a more granular way to edit the text buffer and add messages of different types.
Roman
In my experience, commas in [text] are broken... Best not to use them :-)
On 26.03.2022 23:20, Roman Haefeli wrote:
Anyone?
Roman
On Tue, 2022-03-22 at 22:33 +0100, Roman Haefeli wrote:
Hi
[text get] has a second outlet for the type of the message. There is a distinction between messages terminated by semicolon and messages terminated by comma.
Is there also a way to add messages of different types? I haven't found any. [text set] and [text insert] usually add messages terminated by semicolon (type 0). OK, there is [text fromlist], but I'm interested in a more granular way to edit the text buffer and add messages of different types.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote:
In my experience, commas in [text] are broken... Best not to use them :-)
What is the purpose of 'type' in [text] then? I find your advice of not using a feature because it is broken - frankly - disconcerting. If it's broken, then it ought to be fixed.
Apparantly, FUDI uses both, commas and semicolons. In message boxes, they have a different meaning. The selector of a message after a semicolon is considered a send symbol. Everything after a comma i considered simply a message.
In texts, the distinction was not clear to me, but it seems the Pd patch format itself uses both:
#X floatatom 26 77 5 0 0 0 - - -, f 5;
the message 'f 5' defines the width of the number box. I'd like to be able to modify Pd files with [text], since I believe both [text] and the Pd parser use the same infrastructure for parsing and composing. However, it seems that types are only implemented in the parsing component of [text], but not in the composing part.
Yes, I could use the new [file] facility to edit Pd patches as binary files, but it seems the wrong tool, since Pd patch format is FUDI and [text] works with FUDI.
Roman
On 27.03.2022 11:01, Roman Haefeli wrote:
On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote:
In my experience, commas in [text] are broken... Best not to use them :-)
What is the purpose of 'type' in [text] then? I find your advice of not using a feature because it is broken - frankly - disconcerting. If it's broken, then it ought to be fixed.
Sure. I was a bit tongue-in-cheek :-)
Currently, [text get] just strips all atoms after the first comma and outputs 1 (= colon) as the type. There is no way to get the rest of the message. I think [text get] could simply output all sublists consecutively. By checking the right outlet you know if a message spans a whole line (= 0), or is part of a comma seperated list of messages (= 1).
Another issue that you have mentioned is that we can't *set* lines that include actual commas. One simply solution could be to add a flag to [text set] that interprets the list as *escaped* text, just like [text fromlist]
The only case where commas do already work is in [text sequence -g]:
foo 1 2 3, bar baz
This//will indeed send the messages "1 2 3" and "bar baz" to destination "foo".
Apparantly, FUDI uses both, commas and semicolons. In message boxes, they have a different meaning. The selector of a message after a semicolon is considered a send symbol. Everything after a comma i considered simply a message.
comma *atoms* always have that meaning. It just appears to be different depending on which level you look at it: "patch file" VS "patch"
A Pd patch files is really just a sequence of messages, and consequently it can make use of comma atoms as a shortcut, just like in your example:
#X floatatom 26 77 5 0 0 0 - - -, f 5;
That's really the same as:
#X floatatom 26 77 5 0 0 0;
#X f 5;
(And you're right that it causes troubles when trying to parse Pd patch files within Pd.)
When comma atoms are used inside a patch (e.g. in message boxes, [text define], etc.), they have to be escaped in the Pd patch file:
#X msg 39 327 vis 0 , vis 1;
(In [text] it appears as a symbol atom, so it can be set and retrieved with [text set] and [text get].)
Here's a combination of these two layers of meaning:
#X msg 49 252 foo 1 2 3 , 5 6 7, f 20;
The first (escaped) comma belongs to the message box, but the second one will just send the following message to #X (= the current object).
As a side note: although the comma in
[foo 1 2 3, bar baz(
and
[;foo 1 2 3, bar baz(
might seem to have different functionality, it really is the same.
In the first case, the implicit receiver is the hidden /t_messresponder/ object, which just sends all messages to the message box outlet. Consequently, the message box will output 2 messages "foo 1 2 3" and "bar baz".
In the second case, there is an explicit receiver "foo", which will receive the messages "1 2 3" and "bar baz".
Christof
There is no way to get the rest of the message. I think [text get] could simply output all sublists consecutively. By checking the right outlet you know if a message spans a whole line (= 0), or is part of a comma seperated list of messages (= 1).
To be more precise: it should output all sublists when you request a *whole line* (field number = -1).
If you have the following text:
1 2 3, foo bar baz, 5 6 7;
[0( -> [text get] would output "1 2 3" (type 1), "foo bar baz" (type 1) and "5 6 7" (type 0)
But how would you access individual sublists?
I guess you should be able to do [3 3( -> [text get] to get the second sublist, but [3 4( -> [text get] should probably trigger an out-of-range error.
But we do not know the indices and sizes of the individual sublists!
Maybe [text size] could have an extra outlet to provide that information? Maybe output a list of indices?
This definitely needs a bit of thinking...
Christof
On 27.03.2022 18:22, Christof Ressi wrote:
I guess you should be able to do [3 3( -> [text get] to get the second sublist, but [3 4( -> [text get] should probably trigger an out-of-range error.
I meant to write [0 3 3( -> [text get] and [0 3 4( -> [text get]...
Another side note: it would be nice if a negative field count for [text get] would output all fields up to the next seperator (comma or semi). To retrieve a sublist, we would only need to know the *index*, i.e. [<line> <index> -1( -> [text get]
On Sun, 2022-03-27 at 22:39 +0200, Christof Ressi wrote:
On 27.03.2022 18:22, Christof Ressi wrote:
I guess you should be able to do [3 3( -> [text get] to get the second sublist, but [3 4( -> [text get] should probably trigger an out-of-range error.
I meant to write [0 3 3( -> [text get] and [0 3 4( -> [text get]...
Another side note: it would be nice if a negative field count for [text get] would output all fields up to the next seperator (comma or semi).
I agree and it does so already.
Roman
Another side note: it would be nice if a negative field count for [text get] would output all fields up to the next seperator (comma or semi).
I agree and it does so already.
I don't think so:
1 2 3 a b c d e f;
[0 3 -1( -> [text get]
gives me: "text get: bad field count (-1)"
On Sun, 2022-03-27 at 18:22 +0200, Christof Ressi wrote:
There is no way to get the rest of the message. I think [text get] could simply output all sublists consecutively. By checking the right outlet you know if a message spans a whole line (= 0), or is part of a comma seperated list of messages (= 1).
To be more precise: it should output all sublists when you request a *whole line* (field number = -1).
If you have the following text:
1 2 3, foo bar baz, 5 6 7; [0( -> [text get] would output "1 2 3" (type 1), "foo bar baz" (type
- and "5 6 7" (type 0)
[0( now returns only '1 2 3'. [1( accesses 'foo bar baz', and [2( '5 6 7' (type 0).
But how would you access individual sublists?
There is no need to access _sublist_ since lists of either type are accessed and counted the same. I think, this aspect of accessing messages is already consistent and complete.
You cannot _create_ lists ending with a comma, however. I propose a 'type' inlet in [text set] and [text insert], just for completeness and consistency.
[11 12 13( [2( [1( <- type | / / [text insert ]
with above text buffer example would create:
1 2 3, foo bar baz, 11 12 13, 5 6 7;
Roman
I guess you should be able to do [3 3( -> [text get] to get the second sublist, but [3 4( -> [text get] should probably trigger an out-of-range error.
But we do not know the indices and sizes of the individual sublists!
Maybe [text size] could have an extra outlet to provide that information? Maybe output a list of indices?
This definitely needs a bit of thinking...
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
You cannot _create_ lists ending with a comma, however. I propose a 'type' inlet in [text set] and [text insert], just for completeness and consistency.
[11 12 13( [2( [1( <- type | / / [text insert ]
with above text buffer example would create:
1 2 3, foo bar baz, 11 12 13, 5 6 7;
Roman
This sounds reasonable! Also, we could add a "type" outlet to [text size], so I can know the type of a "line" without actually outputting its content. Maybe also for [text sequence].
Sorry again for the confusion. At least I could help you resolve your original issue :-)
On Sun, 2022-03-27 at 18:04 +0200, Christof Ressi wrote:
On 27.03.2022 11:01, Roman Haefeli wrote:
On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote:
In my experience, commas in [text] are broken... Best not to use them :-)
What is the purpose of 'type' in [text] then? I find your advice of not using a feature because it is broken - frankly - disconcerting. If it's broken, then it ought to be fixed.
Sure. I was a bit tongue-in-cheek :-)
Currently, [text get] just strips all atoms after the first comma and outputs 1 (= colon) as the type. There is no way to get the rest of the message.
This is not what I experience. Commas don't wrap, so what comes after a comma is still on the same line. However, [text get] and [text size] are consistent in that they consider messages and not lines.
eins;
zwei;
drei, vier;
fuenf;
[text size] returns 5. [2(-[text get] returns 'symbol drei'. The message after that is accessed with [3(-[text get].
I think [text get] could simply output all sublists consecutively.
I think it does exactly that.
By checking the right outlet you know if a message spans a whole line (= 0), or is part of a comma seperated list of messages (= 1).
Another issue that you have mentioned is that we can't *set* lines that include actual commas. One simply solution could be to add a flag to [text set] that interprets the list as *escaped* text, just like [text fromlist]
The only case where commas do already work is in [text sequence -g]:
foo 1 2 3, bar baz This will indeed send the messages "1 2 3" and "bar baz" to destination "foo".
Apparantly, FUDI uses both, commas and semicolons. In message boxes, they have a different meaning. The selector of a message after a semicolon is considered a send symbol. Everything after a comma i considered simply a message.
comma *atoms* always have that meaning. It just appears to be different depending on which level you look at it: "patch file" VS "patch"
A Pd patch files is really just a sequence of messages, and consequently it can make use of comma atoms as a shortcut, just like in your example:
#X floatatom 26 77 5 0 0 0 - - -, f 5;
That's really the same as:
#X floatatom 26 77 5 0 0 0; #X f 5;
That's really interesting. That's exactly how I "worked-around" the issue a few years ago and today I was thinking: 'What the hell am I doing here? That looks broken'. Indeed, the effect of both examples is the same. So, if those are equivalent, then I don't actually need commas and the issue I am trying to address is moot.
(And you're right that it causes troubles when trying to parse Pd patch files within Pd.)
Pd seems to parse:
#X floatatom 26 77 5 0 0 0; #X f 5;
just fine.
When comma atoms are used inside a patch (e.g. in message boxes, [text define], etc.), they have to be escaped in the Pd patch file:
No, when editing patch files, I don't want escaped commas. I'd like to preserve their meaning. Adding esacped commas is easy (or at least, I think so), whereas adding un-escaped commas are impossible (but not strictly necessary, as you can get the same meaning by other means).
#X msg 39 327 vis 0 , vis 1; (In [text] it appears as a symbol atom, so it can be set and retrieved with [text set] and [text get].)
Here's a combination of these two layers of meaning:
#X msg 49 252 foo 1 2 3 , 5 6 7, f 20; The first (escaped) comma belongs to the message box, but the second one will just send the following message to #X (= the current object).
My initial question was about how to do the second case: Creating a message that _ends_ with a comma. Not: Creating a message that _contains_ a comma.
The former is achieved with:
[list sechs , sieben( | [text set]
Roman
On 28.03.2022 22:43, Roman Haefeli wrote:
eins; zwei; drei, vier; fuenf;[text size] returns 5. [2(-[text get] returns 'symbol drei'. The message after that is accessed with [3(-[text get].
Wow, you're right of course! *big facepalm* In all these years I never realized that comma seperate messages count as seperate "lines"!
The documentation of [text] only always speaks of "lines" and one would think that "line" would mean, well, "line of text".
From [text get]:
"text get" reads the nth line from the named text and outputs it.
From [text size]:
"text size" reports the number of lines in the text or the length of a specified line.
How am I supposed to know that
1 2 3, a b c, foo bar baz;
actually counts as 3 "lines"?
I think a more proper term would be "message". I think the documentation has to be improved. @porres to the rescue!! :-)
Christof
-
Christof Ressi -
Roman Haefeli