If you run an recognizer for linebreaks, ascii-art etc in your email app (e.g. Mozilla Mailnews after I submitted my patches) to make mail look nicer (e.g. variable width font where appropriate, wrap at window width), bugzilla spam doesn't look too good. The worst problem I ran into is that the "------- Additional Comme..." is recognized as ascii-art, and switched the whole following paragraph to fixed width font, which is hard to read. I don't know a workaround on the Mozilla side (other than special-case hacks), so could bugzilla just output an empty line between "------- Additional Comme..." and the comment itself? That's how it is outputted on the web version, too. Also, the long horizontal bar under the diff headers, e.g. What |Old Value |New Value ---------------------------------------------------------------------------- CC| |mozilla@bucksch.org is really long with an variable width font (you should be able to see that even with stock Mozilla Mailnews) and unnecessarily causes a horzontal scrollbar. Could we just remove it, or replcae it with iterating spaceas and dashes, e.g. "- - - ..."? Similar for the "------- Additional Comme..."-line: The dashes are not really necessary. If somebody points me at the right code, I can submit a patch. Would be nice, if this could go in 2.12.

code for this is in globals.pl, look for a routine called "GetLongDescriptionAsText"

Yes, thanks. I already found it. What do you think? Am I selfish or is this a general improvement?

I like the idea of adding a space after the Additional Comments line. For the horizontal divider in the activity table though, I think it'll look funny in a fixed font if you change it.

What if I just insert a space every five or ten dashes?

1. Added empty line after "Additional Comments" 2. Insert 1 space every 10 dashes in the long hor. line. 3. Changed pointless "What" to "Field" I did not change the "Additional Comments" line itself. Attaching patch. Cyeh, how do we proceed now? Can you r=? Do I need a=? (I have an CVS account.) When will the changes take effect on bugzilla.mozilla.org?

installed this patch on my system so I could see what it looks like... Additional comments look good. The broken up horizontal bar looks, um, interesting. :) It makes it hard to separate out the columns if you only have one or two things changed on a bug, for some reason...

dave, suggestions welcome. IMO, one long line is a bad idea, you can see this even on normal readers with a variable width font and a small window (not that the new mail notification would look good in variable width font :-(, but that's what I'm trying to change on the client side.)

can somene paste-in what the output looks like so that others can comment easily?

Date: Thu, 14 Sep 2000 19:35:21 -0700 From: InTrec Bugs <bugs@intrec.com> To: dave@intrec.com Subject: [Bug 195] Changed - test file and testing still http://bugs.intrec.com/show_bug.cgi?id=195 dave@intrec.com changed: Field |Old Value |New Value ---------- ---------- ---------- ---------- ---------- ---------- ---------- Target Milestone|--- |A Priority|P2 |P3 ------- Additional Comments From dave@intrec.com 2000-09-14 19:35 ------- changing a few things and adding a comment to see what the comment and change text will look like. Typing a little bit more so we have enough to make a three line paragraph.

What about this now?

with the mail flags created with the mail notification preferences (see bug 17464), It would probably be easily doable now to have it output a few different ways, and let the user pick one. Heck, might even have an HTML choice with the changes in an actual table (not by default of course - many email programs hate HTML).

Yes, a simple (ocde human-readable) HTML table would be ultra-cool! Can you file a bug and cc me?

what's the status on this? still plan to do something with this for 2.12 or is it worth holding off for 2.14 in order to implement bug 65477 instead of this one, and make the suggestion here be one of those options in that one?

I vote with Dave on this. Let's close this out in favor of the other but. Marking as a (psuedo) dupe just so the info gets recorded in the other bug. *** This bug has been marked as a duplicate of 65477 ***

Tara, please fix it on 2.12. It is annoying and has a workaround. You can still include the better fix in 2.14. REOPENing to trigger a reaction.

And the workaround is annoying for people who like the old way (like me). I vote to wait for the ability for the user to pick one.

*** This bug has been marked as a duplicate of 65477 ***

This isn't entirely a dupe but I'll verify it as such because I wouldn't want the spaces either.

Unsetting target milestone so we can delete the old (inappropriate) Mozilla target milestones from Webtools.

moving to Bugzilla product reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE