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
      max v2;
    • 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|
    • 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|
    • 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|
    • 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