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

[Liam Goodacre]

Something else I've noticed: if you send a list of numbers to [text get], the object breaks. It gives an error message and then persists with this even if you send it a float. I know that a list is invalid input, but it would probably be good to protect against it in some other way.


________________________________
From: Pd-list <pd-list-bounces at lists.iem.at> on behalf of Liam Goodacre <liamg_uw at hotmail.com>
Sent: 02 January 2017 16:55
To: PD list
Subject: [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170104/b6592eed/attachment.html>