<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 27.03.2022 11:01, Roman Haefeli wrote:<br>
<blockquote type="cite"
cite="mid:77e9d57f7524291f4bd51e9439da412a23cf4fa4.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">On Sun, 2022-03-27 at 01:10 +0100, Christof Ressi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">In my experience, commas in [text] are broken... Best not to use them
:-)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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. </pre>
</blockquote>
<p>Sure. I was a bit tongue-in-cheek :-)<br>
</p>
<p>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).<br>
</p>
<p>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]</p>
<p>The only case where commas do already work is in [text sequence
-g]:</p>
<pre>foo 1 2 3, bar baz</pre>
<p>This<i> </i>will indeed send the messages "1 2 3" and "bar baz"
to destination "foo".</p>
<blockquote type="cite"
cite="mid:77e9d57f7524291f4bd51e9439da412a23cf4fa4.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">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. </pre>
</blockquote>
<p>comma *atoms* always have that meaning. It just appears to be
different depending on which level you look at it: "patch file" VS
"patch"<br>
</p>
<p>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:</p>
<blockquote type="cite"
cite="mid:77e9d57f7524291f4bd51e9439da412a23cf4fa4.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">#X floatatom 26 77 5 0 0 0 - - -, f 5;</pre>
</blockquote>
<p>That's really the same as:<br>
</p>
<pre class="moz-quote-pre" wrap="">#X floatatom 26 77 5 0 0 0;</pre>
<pre class="moz-quote-pre" wrap="">#X f 5;
</pre>
<p>(And you're right that it causes troubles when trying to parse Pd
patch files within Pd.)<br>
</p>
<p>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:<br>
</p>
<pre>#X msg 39 327 vis 0 \, vis 1;</pre>
<p>(In [text] it appears as a symbol atom, so it can be set and
retrieved with [text set] and [text get].)<br>
</p>
<p>Here's a combination of these two layers of meaning:<br>
</p>
<pre>#X msg 49 252 foo 1 2 3 \, 5 6 7, f 20;
</pre>
<p>The first (escaped) comma belongs to the message box, but the
second one will just send the following message to #X (= the
current object).</p>
<p>---<br>
</p>
<p>As a side note: although the comma in<br>
</p>
<pre>[foo 1 2 3, bar baz(</pre>
<p>and</p>
<pre>[;foo 1 2 3, bar baz(</pre>
<p>might seem to have different functionality, it really is the
same. <br>
</p>
<p>In the first case, the implicit receiver is the hidden <i>t_messresponder</i>
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".<br>
</p>
<p>In the second case, there is an explicit receiver "foo", which
will receive the messages "1 2 3" and "bar baz".<br>
</p>
<p>Christof<br>
</p>
</body>
</html>