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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
