At 4/16/04 3:00 AM, Martin Edenhofer wrote:

On Tue, Apr 13, 2004 at 06:33:21PM +0200, Alessandro Ranellucci wrote:

...

On 13-04-2004 at 17:47, Alessandro Ranellucci wrote:

...

...

$Self->{Body} =~ s/(> )?(.{$NewLine}[^\s]*\s)/$2\n/g;

Actually that line should be as follow to prevent un-quoting of quoted text:

$Self->{Body} =~ s/((> )?.{$NewLine}[^\s]*\s)/$1\n/g;

How about lines with more the $NewLine chars? Do you know an regexp to insert an \n bevor $NewLine is reached?

For example: "His is a long line with a lot of words an here is a loooooooooonnnnnggggg word."

$NewLine is there: -----------------------------------^

But I want to insert the \n bevor "loooooooooonnnnnggggg".

Do you have an solution?

This will work: $Self->{Body} =~ s/(.{1,$NewLine})(?:\s|\z)/$1\n/g; It correctly handles the case you mentioned. Because regexps are greedy, the {1,$NewLine} grabs as many characters as it can up to (but not more than) $NewLine characters. (The "\z" makes sure that the final line of a message isn't broken at the final space if it's missing a trailing newline.) Now that I think about it, pre-quoted lines probably should not be rewrapped at all, actually, leading to something more like: $Self->{Body} =~ s/(^>.*|.{1,$NewLine})(?:\s|\z)/$1\n/gm; Currently, AgentCompose.pm uses this to wrap lines of incoming messages: $Data{Body} =~ s/(.{$NewLine}.+?\ s)/ $1\n/g; This wraps lines at 75 characters or greater, rather than 75 characters or less, which is what we really want. If the latter line were: $Data{Body} =~ s/(^>.*|.{1,$NewLine})(?:\s|\z)/$1\n/gm; ... the results are MUCH better. I've made this change on my version of OTRS and tested it on all the edge cases I can think of, and it seems to be working well. It still isn't perfect in quoting the original text when the sender uses a line length greater than 75 characters (the quoted text gets broken into a long line of up to 75 characters and a short, single-word next line); I'll work on that (although actually my e-mail program does exactly the same thing with mail above 77 characters, so maybe this is just something that's inherent to the process). If I can work out that last kink (or decide it can't be fixed), I would then like to submit a patch if it is likely to be accepted. The patch would need to remove the hard wrap from all the templates for this change to work properly; would that be an issue? Does anyone actually like/use the browser wrap type for anything that would be missed if OTRS correctly handled the wrapping in code? (I personally have had no end of wrapping problems due to the hard wrap; in particular, my browser [Safari] actually varies the amount of text the textarea can contain depending on whether the text in it causes a vertical scroll bar to appear. Unbelievable. It actually also uses variable-width fonts for textareas by default, which I had to override in the OTRS CSS style. Sheesh.) -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ "Ignorance more frequently begets confidence than does knowledge." -- Darwin