classpath-patches
[Top][All Lists]
Advanced

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

Re: [cp-patches] Patch: several fixes for DefaultStyledDocument


From: Anthony Balkissoon
Subject: Re: [cp-patches] Patch: several fixes for DefaultStyledDocument
Date: Tue, 20 Dec 2005 14:07:48 -0500

On Tue, 2005-12-20 at 11:01 -0500, Anthony Balkissoon wrote:
> On Mon, 2005-12-19 at 17:54 -0500, Anthony Balkissoon wrote:
> > This is the first part of the work I'm doing on DefaultStyledDocument.
> > This fixes a couple issues associated with PR 24744 but the bug is not
> > completely fixed yet, so the testcase for that PR still crashes.  I will
> > continue to work on this but these changes are ready to go in and may
> > help get some text/html test apps up and running so I'm committing this
> > now.
> 
> This patch caused some Mauve regressions because it's causing an
> unexpected exception, I'm working on this and will also be checking in
> the Mauve tests I wrote while creating this patch.
> 
> --Tony

Okay, I've fixed the regressions and made progress with the attached
patch.  Yesterday I put code in ElementBuffer.insertContentTag to join
Elements if they had the same attribute sets.  This was incorrect and
led to the Mauve regressions.  The problem was that the wrong
information was being passed to insertContentTag.
DefaultStyledDocument.insertUpdate basically makes a list of
ElementSpecs that it wants the ElementBuffer to turn into Elements.
There was a problem in this method that was causing the wrong
ElementSpecs to be sent to the ElementBuffer (and eventually to
insertContentTag).  This is fixed, but the solution is somewhat of a
hack.  

The reason for the hack is as follows.  To create a LeafElement (a
structural object) we call AbstractDocument.createLeafElement which
takes as one of its parameters an AttributeSet that you want the
LeafElement to have.  However, in the process of creating the
LeafElement we actually add an attribute to the set that describes the
LeafElement's start and end offset positions.  So for instance, the
following code would print "false" (the parent, start_offset, end_offset
arguments are not important to this discussion):

SimpleAttributeSet set = new SimpleAttributeSet();
set.addAttribute("A", "B");
Element e = createLeafElement(parent, set, start_offset, end_offset);
System.out.println (e.isEqual(set));

And this is the basis of our problem .. before we were comparing the
AttributeSet that we were going to use to create an Element with the
attribute set from an Element that already existed and so we'd always
get that they were not equal.  So the hack basically calls
createLeafElement to create an Element from which we get an
AttributeSet, and we use _that_ set in our comparisons.  The element
returned from createLeafElement is then thrown away, we don't actually
add it to the Document structure.

Since I consider this a bit of a hack, comments are appreciated (Roman?)
in case another solution is preferred.

2005-12-20  Anthony Balkissoon  <address@hidden>

        * javax/swing/text/DefaultStyledDocument.java:
        (ElementBuffer.insertContentTag): If the direction is 
        OriginateDirection split all the time, don't check the attribute sets.
        Removed the special case for the first insertion.  These cases should
        fall under the direction JoinPreviousDirection. Changed the comments to
        reflect this.
        (insertUpdate): Added a hack to get the right result when comparing
        the attributes of the new ElementSpec to the attributes of either
        the previous or next Element.

--Tony

Attachment: DefaultStyledDocumentFixes2.diff
Description: Text Data


reply via email to

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