bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug swing/26354] Removing single characters in JTextArea leaves model i


From: thebohemian at gmx dot net
Subject: [Bug swing/26354] Removing single characters in JTextArea leaves model in broken state
Date: 20 Feb 2006 12:12:51 -0000


------- Comment #3 from thebohemian at gmx dot net  2006-02-20 12:12 -------
It took me a while to find out what is causing these strange problems. I post
my findings for later reference.

The GapContent problem:
-----------------------

I took pen & paper to simulate what should happen in shiftGapEndUp and came to
the
conclusion that there is no reason why the mark should be set to newGapEnd + 1
and that the correct new mark would have been newGapEnd.

Here is my example:

< - gap start

> - gap end

This is the starting situation. You can reach this by inserting "abc\ndef\n" at
position 0 in an empty array and then moving the gap down to 4 (= shiftGap(4)
).

 a b c . <d e> d e f .
0 1 2 3 4  5 6  7 8 9 10

Now, finish the removal of the 'd' by calling shiftGapEndUp(7). The result
should be:

 a b c . <d e d> e f .
0 1 2 3 4  5 6 7  8 9 10

Obviously a Position that pointed to the 'd' (mark = 6) should now point to the
'e' at mark 7 and not 8 what classpath does without this patch.

I mauve test that supports my argument was already added. It is the last case
in
gnu.testlet.javax.swing.text.GapContent.remove.testGeneral. Ah, yes. There are
no regression with this patch.

The AbstractDocument problem:
-----------------------------

While the GapContent fix makes it possible to remove the 'd' in this document
correctly:

abc
def

The change of the order of operations in AbstractDocument.remove makes it
possible to remove the 'c' from the same document.

What was wrong before the patch is that the content was already changed when
PlainDocument.removeUpdate is invoked. In the example above that method calls
getElementIndex() for offset 3 which was initially on the first line but since
the content is already modified it returns that offset 3 is on the second line.
This in turn leads the algorithm to the assumption that a line-spanning removal
has taken place and that the Elements representing these lines have to be
joined.

A mauve test for this issue can be found in
gnu.testlet.javax.swing.text.PlainDocument.remove.testBehavior().


-- 

thebohemian at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |0.21


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26354





reply via email to

[Prev in Thread] Current Thread [Next in Thread]