This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [60cat] remaining red underlining after syntax correction | ||
---|---|---|---|
Product: | editor | Reporter: | ulfzibis <ulfzibis> |
Component: | Painting & Printing | Assignee: | issues@editor <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jlahoda |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
missing red underline
red underline remains |
Description
ulfzibis
2007-11-23 20:35:03 UTC
Created attachment 53424 [details]
missing red underline
Created attachment 53425 [details]
red underline remains
I've have it seen as well in current daily build. It's seems as painting problem, when I move the caret over the wrongly marked line the red underline went away. Don't forget, that I had errors in 2 lines, but erroneously only 1 line was underlined. Ok, two problems reported: #1 - not both lines were underlined to mark the errors #2 - when the error was corrected the second line stayed underlined I can reproduce #1 in a dev build, but not #2. With #2 I can actually see the underlining flick in there for a moment and then disappear. I'm not sure why that is, maybe a conflict between error and hint annotations? Re #2 - I can't reproduce it. Did you change font size or tweaked fonts&colors settings in any way? Or maybe this is Windows specific. Jirko, could you please double check this on linux/Mac? Thanks Re 1: I did some debugging, and the problem is possibly in OffestsBag - I have created a test case, which shows what happens - I would assume that the HighlightSequence should be non-empty on the last line. Is that right? Thanks. public void test122663() throws BadLocationException { Document doc = new PlainDocument(); doc.insertString(0, " 567890123456789", SimpleAttributeSet.EMPTY); OffsetsBag bag = new OffsetsBag(doc); SimpleAttributeSet attribsA = new SimpleAttributeSet(); SimpleAttributeSet attribsB = new SimpleAttributeSet(); attribsA.addAttribute("set-name", "attribsA"); attribsB.addAttribute("set-name", "attribsB"); bag.addHighlight(5, 10, attribsA); bag.addHighlight(5, 15, attribsB); assertTrue(bag.getHighlights(5, 15).moveNext()); } > Re #2 - I can't reproduce it. Did you change font size or tweaked fonts&colors settings in any way? No, I used fresh installed RC2 without imported settings. > Or maybe this is Windows specific. Could be. Painting problem makes sence, because only each 2nd pixel of the red underline remains after error correction. #2: I've testes it once more time and I can see this only on Win, others platforms (Linux, Mac) are ok #1 - Thanks for the test case. Yes, the sequence should not be empty? I assume you are saying that it *is* empty and the test fails, which is obviously a bug. #2 - Thanks for the extra testing. I'll switch to Windows and try to hunt it down. #1: yes, the sequence should be non-empty, IMO, but it is empty with the current implementation, so the test fails. moving opened issues from TM <= 6.1 to TM=Dev can't reproduce #1 with 6.7m3, there is gray highlighting for i in first row and red highlighting in second row. after correction rd remained in second row and after click in editor all gone, it seems #2 is still reproducible, also not sure if highlighting on first row should be gray. I don't understand. If in 6.7m3 only 2nd line is underlined, it is reproducible as shown in 1st attachment. _Both_ lines (or at least 1st line) should be underlined red. Note that also in build 200711201000 variable i seems underlined grey (difficult to see in attached compressed JPEG). Integrated into 'main-golden', will be available in build *200911060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3c33ed7e852b User: Vita Stejskal <vstejskal@netbeans.org> Log: #122663: fixing addHighlights (see the issue for the testcase; many thanks to jlahoda for such an excellent testcase) Is #2 (corrupted repaint on Windows) also covered by this fix ? No, it's not. There is an other bug for it, see issue #114595. Usually changing the font or its size helps. I'm sorry. |