#95 Continuous wrap updating bugs

[Eddy De Greef]

Bug report submitted via discuss mailing list
by Randal Koene:

Hi there,

Replacing selected text causes program to segfault.
Continuous line wrapping produces erroneous <nl>
(newline) codes.

These bugs occur only for very specific files. The
file must be an HTML file and it must have a single
line. The bug was not replicated for longer HTML
texts. It was also not replicated for plain text. I
did not test all language modes. The bug occurs with
pre-existing files, not with HTML text typed into a
new window.

The bug does *not* appear with NEdit installed
without a personalized .nedit file. With my existing
.nedit (used previously with nedit-5.1) file, the
bug *does* occur. Some further testing shows that
the bug occurs only with my (highly customized)
.nedit when default text fonts are set to the
following:
nedit.textFont:
-adobe-courier-bold-r-normal--12-120-75-75-m-70-iso8859-1
nedit.boldHighlightFont:
-adobe-courier-bold-r-normal--14-*-*-*-*-*-*-*
nedit.italicHighlightFont:
-adobe-courier-bold-i-normal--12-120-75-75-m-0-iso8859-1
nedit.boldItalicHighlightFont:
-adobe-courier-bold-o-normal--14-*-*-*-*-*-*-*

It does not occur, if bold, italic and bolditalic
fonts are assigned with the "fill from primary"
button in the default text fonts selection widget.
If I set the fonts accordingly in an uncustomized
.nedit file no bug occurs. For the purpose of
replication I have included the problematic .nedit
file as an attachment to this email.

A good example is the following:

bash$ echo '<P>' > somefile.html
bash$ nedit somefile.html

Then select ALL the text in the file and press
backspace. At that point the program should
disappear. A segmentation fault is produced.

Note: The bug can be avoided by performing the
backspace erasure of the text in the following way:
(1) switch the language mode to "plain"
(2) select and erase the text

This is *not* restricted to erasure with backspace.
Selecting all the text with the mouse and then
pressing a key (e.g. space) to replace it, or using
the cut keys (ctrl+x) causes the same crash. The
same is true if the text is selected by choosing
"select all" from the edit menu.

The second bug, which occurs when continuous line
wrapping mode is on and editing an existing file
such that the cursor nears the end of the line, also
appears to be caused by the font settings. For the
purpose of replication, I have also included a short
HTML text as an attachment, for which the bug
occurs. Open the text with nedit (using the .nedit
file supplied). Go to the end of the line that reads
"incurred if the phase relationship is not
present.". Then type on. Once you near the border of
the window, the next line should change to
"</CODE><nl><UL>", where <nl> is a non-printable
character representing a newline. If you type
another character at that point, all text below the
cursor location is erased. This looks like another
bounds checking problem that could lead to a
segmentation fault. Again, it is related to the use
of the default fonts in the customized .nedit file.

The version of NEdit is 5.2, installed from the
binary distribution file nedit-5.2-linux-x86.tar.Z
with file size 1268195 bytes and checksum (cksum)
3276223212, as obtained from the www.nedit.org site.

[Eddy De Greef]

.nedit file causing the problem

[Eddy De Greef]

Html file showing the second bug

[Eddy De Greef]

Logged In: YES
user_id=73597

The cause of both bugs is the same: when a buffer is
modified, the text display widget tries to calculate the
affected region. This goes fine in almost all cases,
except one: when countinous wrap is used in combination
with variable font widths (eg, bold font is larger than
normal font, or proportional fonts), the calculation needs
the style information as it existed _before_ the
modification, but that is no longer available. The updated
style information is used instead, possibly leading to
wrong calculations and/or crashes eventually.

I would call this a design bug, and there's no easy way
to work around it. I've literally spent days trying to find
a simple solution, but I always got stuck somewhere.
Eventually I came up with the (huge) patch that is attached:
it performs part of the necassary calculations before the
buffer is modified, and part of them afterwards. This is
only done when necessary, to reuse the more efficient
implementation in non-problematic cases.

Conceptually, it is the right thing to do, I believe,
but I am a bit hesitating to apply it to cvs without a
second opinion. But since this stuff is so hard to
understand, I don't think I will get a second opinion ...

[Eddy De Greef]

bugfix patch

[Eddy De Greef]

Logged In: YES
user_id=73597

I've committed the patches.

[Eddy De Greef]

Logged In: YES
user_id=73597

I've committed the patches.

[Eddy De Greef]

Logged In: YES
user_id=73597

The fix appears to be fine (and is also required for
bug #510631), so I'm closing this.