feature request: "dump" method in [text]

[jmmmp]

With a dump method, it's possible to get the complete contents of a text, without building some specific circuit for it.

[Spacechild1]

What exactly do you mean with "complete contents"? In which format would you except to get content?

[porres]

I guess all lines sequentially?

[Spacechild1]

What about seperators? And what's the use case?

BTW, there's already [text tolist], but that's probably not what @jmmmp wants.

[Spacechild1]

BTW, that's probably the easiest way to get the whole text as a single list:

A "text dump" method could do this a bit more efficiently (i.e. omit the final list copy), but I'm not sure it's a common enough operation to optimize for.

[reduzent]

Isn't that what [text tolist] does? It does it in a way so that the whole text buffer can be restored with [text fromlist].

If [text dump] is meant to output all lines sequentially, then there is already [text sequence]. I don't see what [text dump] could bring to the table that is new.

[Spacechild1]

Isn't that what [text tolist] does?

Not really. [text tolist] converts the atoms to plain text, i.e. semi and comma atoms are converted to symbols and special characters inside symbols are escaped. For example, you can use this to save the whole content of [text define] with [savestate], as mentioned in savestate-help.pd. (It would be nice if this could also be mentioned in the help for [text tolist] and [text fromlist]. Ping @porres).

[Spacechild1]

I don't see what [text dump] could bring to the table that is new.

The only thing that I can imagine is joining all lines to a single list, ignoring all seperators and without conversion. I'm not saying there aren't any use cases for this, but I'm not sure they are frequent enough to warrant a dedicated function...

[reduzent]

Ok, I understand now the third case. But then I feel even stronger that an implementation that intentionally loses much information warrants its own subclass. I consider it a quite specialized case.

[jmmmp]

Hi, basically it would be the same function as dump in cyclone/coll. Which is the contrary to [text tolist]: to get all lines in a text object with one click. I need this often to parse data from textfiles, and usually have to build a [until]-contraption (which either reads the number of lines before banging, or stops it with a right-inlet bang). But it seems to me that dumping all contents at once would be an important use-case to add another method - as it was in coll. Joao

…

On 29.03.22 17:35, Roman Haefeli ***@***.***> wrote: Ok, I understand now the third case. But then I feel even stronger that an implementation that intentionally loses much information warrants its own subclass. I consider it a quite specialized case. — Reply to this email directly, view it on GitHub <#867 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFW34Z4JLL7YT5CLATAU7LVCMPLBANCNFSM4KFG5RHQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Spacechild1]

@jmmmp

Which is the contrary to [text tolist]: to get all lines in a text object with one click.

The opposite of [text tolist] is [text fromlist].

basically it would be the same function as dump in cyclone/coll.

The [dump( method for [cyclone/coll] outputs all lines sequentially. This is the same as sending [line 0, bang( to [text sequence]. So what are you missing exactly?

[porres]

we could make that more explicit as a functionality in the documentation

[jmmmp]

basically it would be the same function as dump in cyclone/coll. The [dump( method for [cyclone/coll] outputs all lines *sequentially*. This is the same as sending [line 0, bang( to [text sequence]. So what are you missing exactly? I was never missing anything, as I always managed to find a way to get the output I wanted. Being what I could think a general use case, it might be better to make it more available. I don't use [text sequence], as that concept isn't that interesting to me. But if something is there and now is clear, I can have a quick look to see if it works.

[Spacechild1]

I don't use [text sequence], as that concept isn't that interesting to me.

You should really check the documentation of an object before making a feature request...

But if something is there and now is clear, I can have a quick look to see if it works.

Yes please :-) I've already posted an example: #867 (comment)

[porres]

Trying to think of a new 'dump' message...

maybe create a 'dump' message for [text sequence] that would be the same as "line 0, bang" but would also ignore waits (not stopping when reaching them).

[Spacechild1]

but would also ignore waits (not stopping when reaching them).

But that's what [line 0, bang( already does?

[porres]

But that's what [line 0, bang( already does?

nope, if you have waits, it'll stop at them.

[Spacechild1]

nope, if you have waits, it'll stop at them.

But only if you use the -w flag... Otherwise it certainly doesn't.

I think you just read the documentation, which indeed says:

output all lines starting from current one to next waiting point

This is actually not quite correct.

@porres to the rescue!

[porres]

yeah, the whole thing says "This is a zero length list. It output all lines starting from current one to next waiting point (but note there aren't any waits in this example so all lines are output)"

and yeah, you need flags to specify waits.

so, my idea of a dump message would be to ignore waits and output them all sequentially anyway

[porres]

there's a typo there, should be "outputs"

[Spacechild1]

yeah, the whole thing says "This is a zero length list. It output all lines starting from current one to next waiting point (but note there aren't any waits in this example so all lines are output)"

Ah, I didn't look at the most recent Pd version :-) So this is already covered.

so, my idea of a dump message would be to ignore waits and output them all sequentially anyway

But we already have [line 0, bang( -> [text sequence]... Why do we need a "dump" method?

Maybe the [line 0, bang( "trick" could be mentioned explicitly somewhere in the [text] documentation?

[porres]

Why do we need a "dump" method?

In my idea, it would output everything EVEN if we have waits, cause it'll stop now if we have waits...

Not that I have a use case for this, and this is also not what this original request needs

[Spacechild1]

In my idea, it would output everything EVEN if we have waits, cause it'll stop now if we have waits...

??? If you don't want to use waits, you wouldn't write [text sequence -w] in the first place....

[line 0, bang( -> [text sequence] does exactly what a "dump" method would do...

[porres]

But I have to say that a "dump" message to plain [text] ("text define") wouldn't be bad!

[Spacechild1]

But I have to say that a "dump" message to plain [text] ("text define") wouldn't be bad!

[text define] and [array define] are just there to define an object. Then you have several "method" to interact with the object. So I'm pretty sure that [text define] should not get a "dump" method.

I would agree that [line 0, bang( -> [text sequence] might not be the most obvious mechanism, but I think it's largely a matter of documentation.

Anyway, we're now only talking about semantic sugar. There is nothing a "dump" method would offer in terms of functionality. It wouldn't even save a lot of keystrokes...

[porres]

??? If you don't want to use waits, you wouldn't write [text sequence -w] in the first place....

I don't have a use case, but it would allow one to use both

[Spacechild1]

I don't have a use case, but it would allow one to use both

??? You can have both [text sequence] and [text sequence -w] in the same patch, depending on what you want to do...

I think it's always a good idea to come up with a use case before proposing a feature ;-)