> 4.) This can already been achieved with [bang( -> [text sequence]
Ah, of course.
> 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 :-).
This can be done with "click" and "close" messages.
Gesendet: Montag, 02. Januar 2017 um 17:55 Uhr
Von: "Liam Goodacre" <[email protected]>
An: "PD list" <[email protected]>
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
_______________________________________________ [email protected] mailing
list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
________________________________
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
