Hi,
I do not follow exactly from the start, but ...
Dne 23. 06. 20 v 23:48 Dmitry Semikin napsal(a):
Nevertheless, meanwhile I updated the example implementation, so that it
implements now HighlightsContainer directly instead of using OffsetsBag. If
someone is interested it is still available on GitHub here:
https://github.com/DmitrySemikin/nb-eol-highlighter
Looking at the impl, there will be slight performance issues, especially
with large documents w/ lots of small lines (xml, html, ...).
You probably do not need to keep *complete* index of all EOLs in the
text here; the HightlightSequence is only called for a limited amount of
text that is visible during drawing.
If you do not modify directly the WhitespaceHighlighting, which computes
the chunks lazily, consider using the OffsetsBag: callbacks like
insertUpdate/removeUpdate may happen in any thread, while hightlight
sequences are likely to execute in EDT thread. Your code is not
thread-safe maintaining highlightsStartOffsets; at least, the
EolHighlightSequence should get an immutable copy of the list.
As for concurrency: highlighters AFAIK collect events from document /
other modifications and fire highlight change *at any time* even while
the highlight sequence might be interated through by editor's painting
code (from EDT) . I think the code that throws ConcurrentModException in
your sequence will break things somewhat.
- Handle them together with whitespaces in WhitespaceHighlighting.java.
I'd suggest to incorporate the changes into WhitespaceHighlighting; the
newline is always part of 'traling whitespace', although not painted by
default.
- In the provided example the font settings are retrieved using
“org.netbeans.api.settings.FontColorSettings.getFontColors()”. But I cannot
easily find, where can I add my own setting “EOL”, so that it is configurable
from the Options dialog?
Do you want to color EOLs separately from the regular 'traling
whitespace', or do you want rather to include EOL character in the
traling whitespace (when it is printed) ?
- When I change the background of the EOL symbol, this background spans till
the very right edge of the text editor. Is it expected? In my opinion it does
not look nice. Can it be fixed somehow? I tried to pass the option
HighlightsContainer.ATTR_EXTENDS_EOL = Boolean.FALSE, but it did not help.
It's strange, but I could not find even a bit of code that _reads_ that
attribute; maybe I missed something.
Note that EOL painting is quite peculiar: the character may or may not
be displayed - which is handled by NewlineView that optionally paints
the character. IMHO ATTR_EXTENDS_EOL should be handled there, since that
code paints background to editorView.getMaxX() if the hightlight item
covers the newline character.
- If this functionality is going to ever be integrated into Netbeans, how
should it be implemented: as separate module, or as part of existing module?
IMHO the current state seems more like omission (combination: paint
trailing whitespace + show nonprintables). So I think yes.
- If existing module, which one?
Whitespace stuff is handled in editor.lib2
- Are any automated tests needed for this particular case? What is considered
to be useful to test?
Yes !! Absolutely. In this case, you need to check various the highlight
layer + editor view paint combinations. To ensure the rest of line is
NOT painted; you're likely the first after LONG time to use
ATTR_EXTENDS_EOL = false.
-Svata
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
