comment / text behaviour


    Jan 09 2007 | 10:24 am
    Hi; I'm being tormented by the eccentricities of comment formatting... Wide comment boxes becoming narrower, other ones becoming super wide, and sometimes all but a line of text disappearing. I know it's not a text layout tool, but for preparing lecture notes etc some slightly less 'colourful' behaviour would be oh so nice.
    I'm on 4.5.5 - maybe this has been addressed in 4.6?
    best, E.D.

    • Jan 09 2007 | 11:36 am
      Stretch your comment windows about 20 percent more to the right, so that switching computers/platforms/font sets doesn't make the text wrap (ditto for objects and message boxes). If this happens, it can make things cluttered, not just comment boxes.
      Put a semicolon at the end of a comment sentence, *then* hit return. That line break has a lot more staying power.
      Other than that...? ...you can real-time colorize the comment box with a script send frgb message? fun
    • Jan 09 2007 | 1:02 pm
      Am 09.01.2007 um 11:24 schrieb Eamonn Doyle: > I'm being tormented by the eccentricities of comment formatting... > Wide comment boxes becoming narrower, other ones becoming super wide, > and sometimes all but a line of text disappearing.
      Hi,
      do you know about the "2 byte compatible" checkbox in the inspector? Don't know about your disappearing text, but it'll keep line breaks.
      cheers, g.
    • Jan 10 2007 | 2:41 am
      On 9-Jan-2007, at 5:24, Eamonn Doyle wrote: > I'm being tormented by the eccentricities of comment formatting...
      I can confirm that comment and message boxes have some erratic behavior.
      First up: I know about Cmd-J (aka Fix Width), stretching the box manually, "2-byte compatible", using semi-cola to force line breaks, etc. I really do.
      Nevertheless, since v4.5 or so I have experienced that I can put a multi-line comment box in a subpatcher, manually size it to what I want, close the subpatcher, and when the subpatcher is reopened the comment box has been magically resized, usually to about three times the width of my screen.-(
      This behavior is unfortunately not regularly reproducible, I have found no three-step cookbook recipe which recreates the failure. Indeed, usually when I get the comment box back to the shape I want for a second time, it tends to stay that way. This is a bit like Lewis Carroll's Bellman in The Hunting of the Snark, just not quite as extreme. Annoying but irreplaceable, hence it's impossible to file a proper bug report.
      > I'm on 4.5.5 - maybe this has been addressed in 4.6?
      TTBOMK, no. Again, when I fix the "colorful" behavior, it seems to stay fixed. You just have to be more stubborn than Max.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 11 2007 | 11:30 am
      Eamonn Doyle wrote: > Hi; I'm being tormented by the eccentricities of comment > formatting... Wide comment boxes becoming narrower, other ones > becoming super wide, and sometimes all but a line of text > disappearing. I know it's not a text layout tool, but for preparing > lecture notes etc some slightly less 'colourful' behaviour would be > oh so nice.
      I have to jump into that:
      I am sure you refer to message boxes and not to comments. Comments do not have this behaviour, at least if you check two-byte compatibility in the inspector, but message boxes do...
      It's absolutely annoying the way message boxes are reformatting without being asked (because they try to keep the number of lines constant). Before 4.5 it was working. It's still breaking a lot of my old patches without a chance of a workaround!!! All patches which deal with changing content are absolutely messed up (always if its displaying a file path for example). I reported and complained a lot, I know. I consider this a severe bug, worth to correct before Max 5.0
      Peter Castine wrote: > This behavior is unfortunately not regularly reproducible, I have > found no three-step cookbook recipe which recreates the failure.
      Below it is, but thats what the change since 4.5 was intended to be, keep the number of lines constant (which makes sense for a very limited number of cases). Unfortunately it even doesn't recognise that, after it once had been saved. If you changed the numbers of lines by changing the text by hand or resize the box and reopen, it will snap to the old number of lines. My workaround: if I change a message box, I copy and then paste-replace it again. Did I mention that this is very annoying?...
      Another non consitent behaviour is when I script message boxes with the message: If I define the size in the script, and the message exceeds the defined size, it will sometimes wrap (as I'd expect it to do) and sometimes insist on staying on one line. The same patch, nothing else changed will have both behaviours. The patch is big, on small ones its more consistant...
      I'd like to hear a comment of the bug departement if this behaviour will change, or if C74 would like to keep it ugly. (In the latter case do not expect me to stop complaining... ;-)
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 11 2007 | 6:26 pm
      On 11-Jan-2007, at 6:30, Stefan Tiedje wrote:
      > I am sure you refer to message boxes and not to comments. Comments do > not have this behaviour, at least if you check two-byte > compatibility in > the inspector, but message boxes do...
      I have experienced mysterious resizings with Comment Boxes. Really, comment boxes. (But, yes, I've had the magic ever-expanding message box effect, too.)
      2-byte compatibility seems to help, but it is nevertheless frustrating to set a comment box to a given width, close the patch (or subpatcher), re-open it only to find that Max has resized it. I suspect this may be a problem with parameters in linecount messages.
      I know, I know, I need to get a reproducable set of steps to track this one down. I'll try.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 11 2007 | 8:08 pm
      Make a message box with back-slashed linefeeds. Make a second message box by duplicating the first. Make one change in the second box. Save the reopen. The line feeds in the second are gone.
      On 1/11/07 1:26 PM, "Peter Castine" wrote:
      > On 11-Jan-2007, at 6:30, Stefan Tiedje wrote: > >> I am sure you refer to message boxes and not to comments. Comments do >> not have this behaviour, at least if you check two-byte >> compatibility in >> the inspector, but message boxes do... > > I have experienced mysterious resizings with Comment Boxes. Really, > comment boxes. (But, yes, I've had the magic ever-expanding message > box effect, too.) > > 2-byte compatibility seems to help, but it is nevertheless > frustrating to set a comment box to a given width, close the patch > (or subpatcher), re-open it only to find that Max has resized it. I > suspect this may be a problem with parameters in linecount messages. > > I know, I know, I need to get a reproducable set of steps to track > this one down. I'll try. > > -- P. > > > -------------- http://www.bek.no/~pcastine/Litter/ ------------- > Peter Castine +--> Litter Power & Litter Bundle for Jitter > Universal Binaries on the way > iCE: Sequencing, Recording & > Interface Building for |home | chez nous| > Max/MSP Extremely cool |bei uns | i nostri| > http://www.dspaudio.com/ http://www.castine.de > >
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 11 2007 | 8:54 pm
      Quote: Peter Castine wrote on Thu, 11 January 2007 10:26 ----------------------------------------------------
      > I have experienced mysterious resizings with Comment Boxes. Really
      I have had the exact same behaviour: closing a subpatcher and re-opening it made the comment resize itself. Fix it once, and it sticks.
      And it seems sporadic.
    • Jan 11 2007 | 9:22 pm
      It sticks as long as you don't edit it. Change it and you lose all of the line feeds when you save. Same with message and textedit.
      On 1/11/07 3:54 PM, "Arne Eigenfeldt" wrote:
      > > Quote: Peter Castine wrote on Thu, 11 January 2007 10:26 > ---------------------------------------------------- > >> I have experienced mysterious resizings with Comment Boxes. Really > > I have had the exact same behaviour: closing a subpatcher and re-opening it > made the comment resize itself. Fix it once, and it sticks. > > And it seems sporadic.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 11 2007 | 10:06 pm
      On Jan 11, 2007, at 1:22 PM, Gary Lee Nelson wrote:
      > It sticks as long as you don't edit it. Change it and you lose all > of the > line feeds when you save. Same with message and textedit.
      FWIW, atom parsing (which is what this elimination of whitespace is due to) is only guaranteed to be avoidable using two byte compatible comments.
      -Joshua
    • Jan 12 2007 | 12:57 am
      Yes, that is covered in the manual but there does not seem to be a two-byte option for messages or textedit. If you put returns in a message then edit the message, the returns are lost. In a textedit you can edit but the returns are gone when next you load the patch. This is 4.6 on an Intel book.
      On 1/11/07 5:06 PM, "Joshua Kit Clayton" wrote:
      > > On Jan 11, 2007, at 1:22 PM, Gary Lee Nelson wrote: > >> It sticks as long as you don't edit it. Change it and you lose all >> of the >> line feeds when you save. Same with message and textedit. > > FWIW, atom parsing (which is what this elimination of whitespace is > due to) is only guaranteed to be avoidable using two byte compatible > comments. > > -Joshua > > >
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 12 2007 | 2:14 am
      On 11-Jan-2007, at 15:08, Gary Lee Nelson wrote: > Make a message box with back-slashed linefeeds. Make a second > message box > by duplicating the first. Make one change in the second box. Save the > reopen. The line feeds in the second are gone.
      This I am also (!) aware of, and this one I understand. It's as Joshua says, every time you edit text, the text gets re-parsed and non-escaped whitespace is collapsed to a single blank. Annoying but, in a perverse sort of way, consistent.
      What I've been referring to is filling a comment box (comment box, comment box, what I tell you three times is true!) with a nice long chunky text, like a full paragraph, something akin to the paragraph you are currently reading. No line feeds, no carriage returns, just a long-winded, verbose, prolix, lengthy, protracted, long-drawn-out, overlong, rambling, circumlocutory, periphrastic, pleonastic, loquacious, garrulous, voluble text like the one you see here. Then I grab the lower right hand corner of the comment box (comment box, comment box) and resize it so the comment box (we're talking about comment boxes, right?) is only 200 pixels wide and flows over, oh, I dunno, two dozen lines or something. OK, now close the subpatcher and re-open it. And what do you have then? Max has gone and turned it into a two thousand pixel wide single-line comment box.
      Why? Why? Why?
      Anyone sez I shouldn' write long texts gets a punchinnanose.
      &-)
      Arne understood me the first time through. Next beer's on me, Arne.
      -- Peter
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 12 2007 | 2:33 am
      Let me clarify. Who cares about comment boxes? Once I write them, I seldom edit them. Messages and textedit, on the other hand, are fluid in my world - especially the latter.
      One of the hallmarks of the Macintosh interface is that text editing is built into the kernel, ROM, whatever. It is CONSISTENT from application to application. It is a pain in the neck to scan a large textedit box to visually parse run-on message sequences that were initially nicely formatted as lines ending with commas (for separator , message which works great BTW). I don't want to punch anyone's nose but this is not why I use computers. It is, in fact, very annoying and should be fixed. I am finishing a commission on a piece that has nearly 100 scripts expressed as messages sequences in textedits that are stored and recalled with pattr. If I change a tempo from 120 to 121, 50+ messages flock like lemmings. What a waste of time.
      On 1/11/07 9:14 PM, "Peter Castine" wrote:
      > On 11-Jan-2007, at 15:08, Gary Lee Nelson wrote: >> Make a message box with back-slashed linefeeds. Make a second >> message box >> by duplicating the first. Make one change in the second box. Save the >> reopen. The line feeds in the second are gone. > > This I am also (!) aware of, and this one I understand. It's as > Joshua says, every time you edit text, the text gets re-parsed and > non-escaped whitespace is collapsed to a single blank. Annoying but, > in a perverse sort of way, consistent. > > What I've been referring to is filling a comment box (comment box, > comment box, what I tell you three times is true!) with a nice long > chunky text, like a full paragraph, something akin to the paragraph > you are currently reading. No line feeds, no carriage returns, just a > long-winded, verbose, prolix, lengthy, protracted, long-drawn-out, > overlong, rambling, circumlocutory, periphrastic, pleonastic, > loquacious, garrulous, voluble text like the one you see here. Then I > grab the lower right hand corner of the comment box (comment box, > comment box) and resize it so the comment box (we're talking about > comment boxes, right?) is only 200 pixels wide and flows over, oh, I > dunno, two dozen lines or something. OK, now close the subpatcher and > re-open it. And what do you have then? Max has gone and turned it > into a two thousand pixel wide single-line comment box. > > Why? Why? Why? > > Anyone sez I shouldn' write long texts gets a punchinnanose. > > &-) > > Arne understood me the first time through. Next beer's on me, Arne. > > -- Peter > > > > -------------- http://www.bek.no/~pcastine/Litter/ ------------- > Peter Castine +--> Litter Power & Litter Bundle for Jitter > Universal Binaries on the way > iCE: Sequencing, Recording & > Interface Building for |home | chez nous| > Max/MSP Extremely cool |bei uns | i nostri| > http://www.dspaudio.com/ http://www.castine.de > >
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 12 2007 | 2:47 am
      And while I am in a bad mood...
      Text and coll edit boxes retain line formatting. This is good. However, find & replace do not work as they should. A text window like this (bear with me)
      A A A A A
      With find & replace A->B turns into this if you execute it too many times.
      B B B B BBBBBBBBB
      "Replace all" does not work and wrap seems to be ignored.
      On 1/11/07 9:33 PM, "Gary Lee Nelson" wrote:
      > Let me clarify. Who cares about comment boxes? Once I write them, I seldom > edit them. Messages and textedit, on the other hand, are fluid in my world > - especially the latter. > > One of the hallmarks of the Macintosh interface is that text editing is > built into the kernel, ROM, whatever. It is CONSISTENT from application to > application. It is a pain in the neck to scan a large textedit box to > visually parse run-on message sequences that were initially nicely formatted > as lines ending with commas (for separator , message which works great > BTW). I don't want to punch anyone's nose but this is not why I use > computers. It is, in fact, very annoying and should be fixed. I am > finishing a commission on a piece that has nearly 100 scripts expressed as > messages sequences in textedits that are stored and recalled with pattr. If > I change a tempo from 120 to 121, 50+ messages flock like lemmings. What a > waste of time.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 15 2007 | 9:48 am
      Peter Castine wrote: > 2-byte compatibility seems to help, but it is nevertheless frustrating > to set a comment box to a given width, close the patch (or subpatcher), > re-open it only to find that Max has resized it. I suspect this may be > a problem with parameters in linecount messages.
      I am sure the copy - paste-replace would solve it, but its annoying and there should something be done about it... I do not need to resize a comment as often as to resize a message box, that's why for me its mainly related to messages. I am certain that its the same problem...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 15 2007 | 9:49 am
      Gary Lee Nelson wrote: > With find & replace A->B turns into this if you execute it too many > times. > > B B B B BBBBBBBBB > > "Replace all" does not work and wrap seems to be ignored.
      I gave up using any texteditor features in Max long ago for the simple reason that there is Textwrangler or other free editors which do it right and they are specialized for these tasks. Even Apples native Textedit works better, though its kind of limited.
      The only thing I did: include a better find/replace feature into my wishlist for Max 5.0. The text part of it is workaroundable, but for finding objects in the non text version of patches, Max needs a lot of enhancement....
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com