indeed, this is sooo helpful, i´d vote to haveit in the helpfile for [text define].
thanks a lot, liam! hans www.hans-w-koch.net > Am 02.01.2017 um 21:09 schrieb Christof Ressi <christof.re...@gmx.at>: > >> This can be done with "click" and "close" messages. > > Nice! :-D It's not in the help patch... Thanks a lot! > > > > Gesendet: Montag, 02. Januar 2017 um 20:03 Uhr > Von: "Liam Goodacre" <liamg...@hotmail.com> > An: "Christof Ressi" <christof.re...@gmx.at> > Cc: "PD list" <pd-list@lists.iem.at> > Betreff: Re: [PD] some feature requests for the [text] object > > > > > > 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" <liamg...@hotmail.com> > An: "PD list" <pd-list@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@lists.iem.at mailing > list UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ------------------------------------------------------------ > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
