[PD] some feature requests for the [text] object

[Christof Ressi]

First of all, happy new year to everyone! 

I second on your thoughts about [text]. some comments from my side:

2.) This would be really nice. Just like a line number beyond the range will append a line, a field number beyond the range could append fields. Since this is an error right now (and not handled silently), it won't break patches if we allow it in the future.

4.) This can already been achieved with [bang( -> [text sequence]

Two more suggestions:

a) since Pd 0.47 we have the very helpful 'delete' method which deletes lines of text. what about an equally helpful 'insert' method to insert lines of text? 

b) a simple mechanism to pop the text window. Right now I'm using a hack with mouse messages, but a more elegant way would be very much appreciated :-).

Christof




 
 

Gesendet: Montag, 02. Januar 2017 um 17:55 Uhr
Von: "Liam Goodacre" <liamg_uw at hotmail.com>
An: "PD list" <pd-list at lists.iem.at>
Betreff: [PD] some feature requests for the [text] object

Since 0.48 is coming up, I thought I would bring up some requests I have for the text family of objects. Some of these I brought up at the conference and some of them have only occurred to me since then. There are a lot of text storage objects out there and some of them still do things which can't be done in Vanilla. But IMO the implementation of the [text] is so successful that it deserves a few more features.
 
1. [text define] should send out a bang when the text window is saved. I mentioned this in a recent post. As it stands, there is no way of sensing when the text has been manually edited. It would be very useful to have this information if you ie. wanted to send the text to a list. A bang to the left outlet, or a new right outlet, or even a special receive channel would all work perfectly well here (ie. [receive mytext] gets a bang when [text define mytext] is edited).
 
2. A way to append text to the end of a line. [text set] has the third inlet to determine the field number on a given line, but it won't let you append text beyond the given line length. Is there a reason for this? Compare with "add2" from [textfile]. It seems to me that there should be a way of increasing a line indefinitely.
 
3. [text tolist] and [text fromlist] should accept customs separators. As it stands, the only accepted separator is \; , which is very awkward to work with from inside the patch. It would be great if both objects had an optional argument which specified the separator, so ie. [text tolist mytext &] would create list "list item 1 & item 2 & item 3 &", and [text fromlist mytext &] would accept the same list. Of course, leaving the argument blank would give the current \; separator.
 
3.1 I would also propose that we consider an option for specifying no separator for [text tolist], ie. the whole file comes out as one big list. This would break the symmetry with [text fromlist], but would still be useful in some circumstances.
 
4. A "flush" message to [text get] outputs each line of text iteratively, all at once. This of course can be done with [until], but I would love it if it was possible in one shot.
 
5. A flag on the read command that interprets commas as symbols, not line ends. ie. "read -a text-with-commas.txt". This would be useful when using [text] to read and print plain English files, ie. for help messages and such. Right now I'm having to write a whole lot of instructions without using commas. It's an interesting creative exercise, but something I'd rather avoid! [msgfile] can read commas correctly, so zexy has the upper hand here.
 
 
I hope that these are useful suggestions, and that some of them can be implemented without difficulty.
 
Liam
_______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list