At 4/16/04 3:00 AM, Martin Edenhofer <[EMAIL PROTECTED]> 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
_______________________________________________
OTRS mailing list: dev - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/dev
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
