The top-level help for [text] suggests that you can access and manipulate its contents by line, but is that really true? [text] seems to be message oriented and the line structure is just a side-effect of what terminators (comma or semicolon) are bound with each message. One has to add extra plumbing to make [text get] behave as though it were line oriented, e.g. "please return the 2nd message on the 5th line".

Follow up: OK well, as far as I can tell, here's what I have to go through to make [text get] line oriented. I happened to notice that if each line only contains one message and all messages contain the same number of atoms, then the contents start to resemble a 2D table. So I made such a table that contains the message indexes of the irregular table that I'm really interested in, i.e. the former table helps me translate line indexing to the kind of message indexing that [text] prefers. See what I'm sayin'?
text by line.pd

Nice, thanks! I haven’t fully explored the [text] object yet, even though I’m already using it in a pretty deep way in one of my own projects. I’m working on a system called Envion, and I can definitely see this trick being useful later on, especially when dealing with lists coming from external APIs. It’s a good way to treat incoming data as if it were tabular, even though it’s really just message sequences.

@jameslo In the past I just used something other than a comma (or had pd replace the commas) to separate messages so I could get the whole line, dump it into a [list store], find the appropriate delimiters and get the message I wanted. Not as efficient as your method but don't need to keep two [text]s synced. I almost made an abstraction of your way but the ugliness of automating the generation of the mask [text] sapped my motivation, the [text[ way of doing things just fights you here.

@oid Yeah, I don't like having to keep those two texts sync'd either. It would've been even worse (but not uninteresting) if they had to change during the course of a run--I mostly use them for table-driven logic where they never change. OK, so you're saying you arrange for each line in the source [text] to only contain one message (with special sub-message separators that you've devised) and then copy to [list] to access the contents of each line? If I've understood you correctly, then may I assume you agree with me that [text] help is misleading?

(Actually, I think insert only inserts messages assuming they will be the last message on the line, which seems inconsistent with the way text is inserted in [text define])

@jameslo I sort of agree but honestly, thinking too hard about [text] is something I have learned to avoid doing. If memory serves I did not really devise a separator, I did a [text tolist], dripped and escaped the escapes of the commas, then [text fromlist] so my delimiter was \,. I used my list search abstraction to find the delimiters and fetch the message I was looking for. I am pretty sure that version of [l-find] can do it with ease, not yet on the new laptop and don't have time right now to dig. I probably used [l-find] to replace the commas as well. These days, I think I would just use [pdlua] and get actual tables.

Edit: actually I don't think that version of [l-find] will find all instances and output a list of their indices, so not quite easy. I can upload that later if you want it.

@oid Nah, I'm actually fine with what I've got, thanks. My issue is mostly with help.