comment / text behaviour

Jan 9, 2007 at 10:24am

comment / text behaviour

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.

#29572
Jan 9, 2007 at 11:36am

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;
#N vpatcher 15 55 615 455;
#P window setfont “Sans Serif” 14.;
#P number 357 44 51 14 2 0 1 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 426 101 68 9109513 random 256;
#B color 1;
#P newex 351 101 68 9109513 random 256;
#B color 1;
#P newex 278 101 68 9109513 random 256;
#B color 1;
#P toggle 299 33 30 0;
#P window setfont “Sans Serif” 14.;
#P number 352 206 40 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P number 305 206 40 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P number 257 206 40 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 278 179 83 9109513 unpack 0 0 0;
#B color 1;
#P user swatch 278 128 128 43;
#P window setfont “Sans Serif” 14.;
#N thispatcher;
#Q end;
#P newobj 28 276 161 9109518 thispatcher;
#B color 1;
#P newex 28 239 365 9109518 sprintf script send comment[1] frgb %i1 %i2 %i3;
#B color 1;
#P window setfont “Sans Serif” 9.;
#P newex 299 71 68 9109513 metro 200;
#B color 1;
#P window setfont “Sans Serif” 18.;
#P comment 16 31 272 9109522 Gotta love them comments!;
#B frgb 201 138 239;
#P objectname comment[1];
#P connect 6 0 2 0;
#P connect 2 0 3 0;
#P lcolor 2;
#P connect 7 0 2 1;
#P connect 5 0 6 0;
#P lcolor 2;
#P connect 1 0 10 0;
#P connect 10 0 4 0;
#P connect 4 0 5 0;
#P lcolor 2;
#P connect 9 0 1 0;
#P lcolor 2;
#P connect 5 1 7 0;
#P lcolor 2;
#P connect 11 0 4 1;
#P connect 1 0 11 0;
#P connect 5 2 8 0;
#P lcolor 2;
#P connect 13 0 1 1;
#P connect 8 0 2 2;
#P connect 12 0 4 2;
#P connect 1 0 12 0;
#P pop;

#92800
Jan 9, 2007 at 1:02pm

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.

#92801
Jan 10, 2007 at 2:41am

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

#92802
Jan 11, 2007 at 11:30am

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

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 128 119 28 196617 r b;
#P window linecount 2;
#P message 50 74 97 196617 a b c d e f g h i j k b c d e f g h end;
#P window linecount 1;
#N vpatcher 35 455 345 709;
#P inlet 40 41 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P message 150 97 52 196617 a b c d e f g h i j k ; b;
#P window linecount 2;
#P newex 40 64 50 196617 prepend set;
#P window linecount 3;
#P message 95 97 52 196617 a b c d e f g h i j k ; b;
#P window linecount 1;
#P message 40 97 41 196617 a;
#P window linecount 5;
#P comment 104 156 142 196617 change the middle box by hand to have more
or less lines as before , close the subpatch and bang the big message
box before reopening…;
#P connect 5 0 3 0;
#P connect 3 0 1 0;
#P pop 1;
#P newobj 50 119 70 196617 p;
#P connect 1 0 0 0;
#P window clipboard copycount 3;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#92803
Jan 11, 2007 at 6:26pm

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

#92804
Jan 11, 2007 at 8:08pm

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
http://www.timara.oberlin.edu/GaryLeeNelson

#92805
Jan 11, 2007 at 8:54pm

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.

#92806
Jan 11, 2007 at 9:22pm

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
http://www.timara.oberlin.edu/GaryLeeNelson

#92807
Jan 11, 2007 at 10:06pm

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

#92808
Jan 12, 2007 at 12:57am

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
http://www.timara.oberlin.edu/GaryLeeNelson

#92809
Jan 12, 2007 at 2:14am

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

#92810
Jan 12, 2007 at 2:33am

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
http://www.timara.oberlin.edu/GaryLeeNelson

#92811
Jan 12, 2007 at 2:47am

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
http://www.timara.oberlin.edu/GaryLeeNelson

#92812
Jan 15, 2007 at 9:48am

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

#92813
Jan 15, 2007 at 9:49am

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

#92814

You must be logged in to reply to this topic.