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.
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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