You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Dmitry Semikin <dm...@gmail.com> on 2020/06/23 21:48:29 UTC
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone
point at similar code?
Hello Everyone,
The topic does not seem to attract too much attention, but I hope, it is just lack of time. It is the same for me, so the progress does not go as fast as I’d like it to…
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
Besides after some wandering around in the depths of NetBeans projects I found, where the highlightings for whitespaces are implemented. The following files are involved:
HighlightsContainer implementation for Whitespaces:
netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\WhitespaceHighlighting.java
Corresponding factory:
netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\Factory.java
Registration of the factory is done in the following layer.xml:
netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\resources\layer.xml
Specification of the categories (~FontsAndColors.xml)
netbeans\ide\editor\src\org\netbeans\modules\editor\resources\NetBeans-editor.xml
It's virtual path in Layer.xml:
Editors/FontsColors/NetBeans/Defaults/org-netbeans-modules-editor-highlight-colorings.xml
Layer.xml, in which NetBeans-editor.xml is actually registered:
netbeans\ide\editor\src\org\netbeans\modules\editor\resources\layer.xml
Localization of the category-names shown in options dialog
netbeans\ide\editor\src\org\netbeans\modules\editor\Bundle.properties
So I see two possibilities, how the EOLs could be treated:
- Handle them together with whitespaces in WhitespaceHighlighting.java.
- Or create separate HighlightsContainer specifically dedicated for EOLs.
Could someone suggest, which approach is better? I personally would rather go with the second one for two reasons: first, then I would use the solution, which I already have. Second, if something goes wrong, it is more independent, so it is easier to remove the changes.
I tried to check, who did the changes to the mentioned files recently, but it seems, that they were not modified since the donation of the source code to Apache Foundation. I don’t see the history further backwards. Original authors of those two classes are Miloslav Metelka and Vita Stejskal. If these people are still involved in the development, probably they could give me some advice.
I would be very grateful to anyone, who could give any comment or advice.
With kind regards,
Dmitrii Semikin.
On 2020/06/15 21:33:07, Dmitry Semikin <dm...@gmail.com> wrote:
> Hello Everyone, hello Christian,
>
> Thank you for your hint. Looking at the module you pointed to and at “NetBeans Mark Occurrences Module Tutorial” I put together a module, which kind of does the job. It is not yet completely ready, but I have couple of technical and organizational questions:
>
> - 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?
> - 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.
> - Which Z-Order would be reasonable for EOL?
> - HighlightsLayer.create() function takes as input “fixedSize” parameter, which, if I understand it correctly should tell they system, if the text-size may change as a result of highlight. In my understanding this depends on the AttributeSet used. My question is: is there some utility function, which would define “fixedSize” parameter based on provided AttributeSet, i.e. return “true”, if the AttributeSet explicitly contains font family or font size etc.?
>
> Another couple of question related to integration to Netbeans:
> - 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?
> - If existing module, which one?
> - If new module, what is naming convention for the module and for the package (suggestions for the specific names would be nice).
> - Are any automated tests needed for this particular case? What is considered to be useful to test?
>
> The actual state of the module is available here:
> https://github.com/DmitrySemikin/nb-eol-highlighter
>
> Any additional suggestions and critics are very welcome.
>
> My further planned step for now is to replace implementation, which re-scans whole file for every change with the implementation, which only checks the changed fragment of text. Then try to figure out myself (or with the help of the answers, if any), how to specify colors using options dialog.
>
> Thanks in advance for any kind of comments.
>
> Dmitrii.
>
> On 2020/06/09 08:05:28, Christian Lenz <ch...@gmx.net> wrote:
> > Hey Dimitrii,
> >
> > cool to hear that you want to work on it. Maybe you can find some more insights in this plugin too: https://github.com/tunnelvisionlabs/goworks/tree/master/tvl.editor.whitespace
> >
> >
> > Cheers
> >
> > Chris
> >
> >
> > Von: Dmitrii Semikin
> > Gesendet: Dienstag, 9. Juni 2020 08:29
> > An: dev@netbeans.apache.org
> > Betreff: Re: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
> >
> > Hello once again,
> >
> > I did some digging and I hope, I realized the general idea about coloring. There are categories of tokens defined in Lexer of specific language. And there are "fontsColors.xml" files, which provide mapping of the categories of tokens to particular color. They also provide the list of coloring categories for the Options dialog.
> >
> > So, to provide option for the coloring of EOLs separately one would need to:
> > - Introduce new category of tokens in the language lexer (ultimately, in lexers for each language, if we want to have this feature in every language).
> > - Adjust "fontsColors.xml" to provide coloring-category and default values for the color.
> >
> > Could someone confirm, that my understanding is correct (or point out that it is not correct, maybe providing also some hint about what exactly is wrong)?
> >
> > Could someone also tell, if it is a good idea to modify lexers for languages e.g. like Java (being honest I did not look at the implementation yet)?
> >
> > Thank you in advance.
> > Dmitrii.
> >
> >
> > On 2020/06/06 15:54:25, Dmitrii Semikin <dm...@gmail.com> wrote:
> > > Hello Everyone,
> > >
> > > There is an issue: NETBEANS-1678 : Option for coloring EOL (https://issues.apache.org/jira/browse/NETBEANS-1678).
> > >
> > > I prefer to have whitespace characters on, but find it annoying, that EOL is displayed with the same color as normal text - balck (too bold for me).
> > >
> > > I woud probably try to implement this feature. So I would be greatful, if someone could point me to the place in code, where some similar coloring feature is already implemented (it would also increase chances, that it will be done :)). Also any addiitional ideas, suggestions or advices regarding the implementation would be very appreciated. I should say, that I have some idea about development for NB platform, but I am still rather inexperienced.
> > >
> > > Thank you in advance.
> > >
> > > Dmitrii.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
> >
>
>
Sent from Mail for Windows 10
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point
at similar code?
Posted by Ernie Rael <er...@raelity.com>.
On 6/27/2020 7:51 AM, Tim Boudreau wrote:
> ...A handy library for
> that (and in general working with coalescing intersecting ranges of
> coordinates - I used it in a memory manager for a virtual filesystem as
> well) is here: https://github.com/timboudreau/util/tree/master/range -
> maven central coordinates are com.mastfrog:range:2.6.11.
For ranges how about google's RangeSet, guava
https://github.com/google/guava/wiki/NewCollectionTypesExplained#rangeset,
and related?BTW, ranges are in both versions of guava that NB's used, 15
and 27.
Prompted by this discussion, I went back and took a look at some old
highlight stuff I've got. I'm exploring using RangeSet to implement a
"rangeInBagValid". So that I don't need to compute the highlights for
the entire document and only need to compute the highlights once for any
given region. Normally, there are very few ranges; typically a single
range gets extended, and a new range created when you jump around the file.
-ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point
at similar code?
Posted by Tim Boudreau <ni...@gmail.com>.
Funny, I implemented HighlightsContainer a while back for performance
reasons (coalescing large numbers of overlapping highlights resulting in
multi-second hangs), for the Antlr preview stuff where the highlighting
gets regenerated frequently and can be very complex. A handy library for
that (and in general working with coalescing intersecting ranges of
coordinates - I used it in a memory manager for a virtual filesystem as
well) is here: https://github.com/timboudreau/util/tree/master/range -
maven central coordinates are com.mastfrog:range:2.6.11. I've thought
about patching OffsetsBag to use it - I have a whole bunch of
collections-based-on-primitive-arrays-and-binary-search classes that could
probably improve the performance of a lot of editor functionality that I've
developed over the years (ironically, I got started doing that with the
class that manages line offsets in the output window - autoboxed Integer
instances are around 9x slower, and that's critical path of painting code).
Looking at your code a bit, a few comments:
- I don't think you need the call to fire events on changedUpdate() in
your DocumentListener - that *should* (YMMV) only be called for attribute
changes in the document, not text changes
- You probably want StyleConstants.Background if you want anything to be
visible - newlines don't have a foreground color. That said, the result is
probably not what you're trying to do -
https://timboudreau.com/files/screen/06-27-2020_10-07-18.png - since the
entire end of every line gets painted as a solid color. There is a custom
NetBeans attribute for drawing top / left / bottom / right edges of a box
around a token (I think this is what the editor uses for boxes around
things during instant rename). Setting that attribute for just the *left
edge* of the characters matched - EditorStyleConstants.LeftBorderLineColor
- ought to achieve the goal of simply drawing some sort of mark where the
newline is. That might be closer to just an indication of where the
newline is, though it isn't terribly pretty:
https://timboudreau.com/files/screen/06-27-2020_10-27-04.png
- In playing with it, I tried out a few other likely SwingConstants
options - draw a pilcrow in an icon and paint it, or use
ComposedTextAttribute to draw one, but it seems the editor doesn't support
those - so without a different approach to get hold of the Graphics during
painting, EditorStyleConstants.LeftBorderLineColor may be as good as it gets
- In updateHighlightsOnRemoval(), don't you want the second argument to
fireHighlightsChange() to be removedBlockEndOffset? Right now the change
is always zero-sized
- Your code for the HighlightsContainer follows the tutorial code, which
is fine. I've found it more efficient to weakly attach a ComponentListener
to the editor component, and when it becomes visible, start listening to
the document, and when it gets hidden/removed, detach the document
listener. That way, if the user, say, does a Git pull in a shell while a
file is open in the IDE, you don't wind up recomputing a bunch of
highlights that will may never be shown
- You will want to make the color settable and make it possible to turn
off EOL highlighting - options panel or added color in font color settings,
however you choose. Hint: If you don't want to make the color settable,
but want it to guarantee its shows up, but not annoyingly, just grab the
default foreground and background from FontColorSettings, and use
Color.toHSBColor() to convert both to HSB, and then adjust the brightness
component from the background some percentage toward the foreground
color's, and convert the result back to a Color and use that.
-Tim
On Tue, Jun 23, 2020 at 5:51 PM Dmitry Semikin <dm...@gmail.com>
wrote:
> Hello Everyone,
>
> The topic does not seem to attract too much attention, but I hope, it is
> just lack of time. It is the same for me, so the progress does not go as
> fast as I’d like it to…
>
> 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
>
> Besides after some wandering around in the depths of NetBeans projects I
> found, where the highlightings for whitespaces are implemented. The
> following files are involved:
>
> HighlightsContainer implementation for Whitespaces:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\WhitespaceHighlighting.java
>
> Corresponding factory:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\Factory.java
>
> Registration of the factory is done in the following layer.xml:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\resources\layer.xml
>
> Specification of the categories (~FontsAndColors.xml)
>
> netbeans\ide\editor\src\org\netbeans\modules\editor\resources\NetBeans-editor.xml
> It's virtual path in Layer.xml:
>
> Editors/FontsColors/NetBeans/Defaults/org-netbeans-modules-editor-highlight-colorings.xml
>
> Layer.xml, in which NetBeans-editor.xml is actually registered:
> netbeans\ide\editor\src\org\netbeans\modules\editor\resources\layer.xml
>
> Localization of the category-names shown in options dialog
> netbeans\ide\editor\src\org\netbeans\modules\editor\Bundle.properties
>
>
> So I see two possibilities, how the EOLs could be treated:
>
> - Handle them together with whitespaces in WhitespaceHighlighting.java.
> - Or create separate HighlightsContainer specifically dedicated for EOLs.
>
> Could someone suggest, which approach is better? I personally would rather
> go with the second one for two reasons: first, then I would use the
> solution, which I already have. Second, if something goes wrong, it is more
> independent, so it is easier to remove the changes.
>
> I tried to check, who did the changes to the mentioned files recently, but
> it seems, that they were not modified since the donation of the source code
> to Apache Foundation. I don’t see the history further backwards. Original
> authors of those two classes are Miloslav Metelka and Vita Stejskal. If
> these people are still involved in the development, probably they could
> give me some advice.
>
> I would be very grateful to anyone, who could give any comment or advice.
>
> With kind regards,
> Dmitrii Semikin.
>
>
>
> On 2020/06/15 21:33:07, Dmitry Semikin <dm...@gmail.com> wrote:
> > Hello Everyone, hello Christian,
> >
> > Thank you for your hint. Looking at the module you pointed to and at
> “NetBeans Mark Occurrences Module Tutorial” I put together a module, which
> kind of does the job. It is not yet completely ready, but I have couple of
> technical and organizational questions:
> >
> > - 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?
> > - 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.
> > - Which Z-Order would be reasonable for EOL?
> > - HighlightsLayer.create() function takes as input “fixedSize”
> parameter, which, if I understand it correctly should tell they system, if
> the text-size may change as a result of highlight. In my understanding this
> depends on the AttributeSet used. My question is: is there some utility
> function, which would define “fixedSize” parameter based on provided
> AttributeSet, i.e. return “true”, if the AttributeSet explicitly contains
> font family or font size etc.?
> >
> > Another couple of question related to integration to Netbeans:
> > - 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?
> > - If existing module, which one?
> > - If new module, what is naming convention for the module and for the
> package (suggestions for the specific names would be nice).
> > - Are any automated tests needed for this particular case? What is
> considered to be useful to test?
> >
> > The actual state of the module is available here:
> > https://github.com/DmitrySemikin/nb-eol-highlighter
> >
> > Any additional suggestions and critics are very welcome.
> >
> > My further planned step for now is to replace implementation, which
> re-scans whole file for every change with the implementation, which only
> checks the changed fragment of text. Then try to figure out myself (or with
> the help of the answers, if any), how to specify colors using options
> dialog.
> >
> > Thanks in advance for any kind of comments.
> >
> > Dmitrii.
> >
> > On 2020/06/09 08:05:28, Christian Lenz <ch...@gmx.net> wrote:
> > > Hey Dimitrii,
> > >
> > > cool to hear that you want to work on it. Maybe you can find some more
> insights in this plugin too:
> https://github.com/tunnelvisionlabs/goworks/tree/master/tvl.editor.whitespace
> > >
> > >
> > > Cheers
> > >
> > > Chris
> > >
> > >
> > > Von: Dmitrii Semikin
> > > Gesendet: Dienstag, 9. Juni 2020 08:29
> > > An: dev@netbeans.apache.org
> > > Betreff: Re: NETBEANS-1678: Option for coloring EOL - Could someone
> point at similar code?
> > >
> > > Hello once again,
> > >
> > > I did some digging and I hope, I realized the general idea about
> coloring. There are categories of tokens defined in Lexer of specific
> language. And there are "fontsColors.xml" files, which provide mapping of
> the categories of tokens to particular color. They also provide the list of
> coloring categories for the Options dialog.
> > >
> > > So, to provide option for the coloring of EOLs separately one would
> need to:
> > > - Introduce new category of tokens in the language lexer (ultimately,
> in lexers for each language, if we want to have this feature in every
> language).
> > > - Adjust "fontsColors.xml" to provide coloring-category and default
> values for the color.
> > >
> > > Could someone confirm, that my understanding is correct (or point out
> that it is not correct, maybe providing also some hint about what exactly
> is wrong)?
> > >
> > > Could someone also tell, if it is a good idea to modify lexers for
> languages e.g. like Java (being honest I did not look at the implementation
> yet)?
> > >
> > > Thank you in advance.
> > > Dmitrii.
> > >
> > >
> > > On 2020/06/06 15:54:25, Dmitrii Semikin <dm...@gmail.com>
> wrote:
> > > > Hello Everyone,
> > > >
> > > > There is an issue: NETBEANS-1678 : Option for coloring EOL (
> https://issues.apache.org/jira/browse/NETBEANS-1678).
> > > >
> > > > I prefer to have whitespace characters on, but find it annoying,
> that EOL is displayed with the same color as normal text - balck (too bold
> for me).
> > > >
> > > > I woud probably try to implement this feature. So I would be
> greatful, if someone could point me to the place in code, where some
> similar coloring feature is already implemented (it would also increase
> chances, that it will be done :)). Also any addiitional ideas, suggestions
> or advices regarding the implementation would be very appreciated. I should
> say, that I have some idea about development for NB platform, but I am
> still rather inexperienced.
> > > >
> > > > Thank you in advance.
> > > >
> > > > Dmitrii.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > > >
> > > > For further information about the NetBeans mailing lists, visit:
> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > >
> > >
> > >
> > >
> >
> >
> Sent from Mail for Windows 10
>
>
--
http://timboudreau.com
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point
at similar code?
Posted by Ernie Rael <er...@raelity.com>.
Sounds like you've made some pretty good progress.
There's https://github.com/emilianbold/netbeans-releases which is a git
repository of the old netbeans stuff. And there's
http://source.apidesign.org/hg/netbeans/ which has old mercurial
repositories.
I haven't looked at highlighting for a long time, I seem to recall that
OffsetsBag had quite a bit of functionality (and I could be
miss-remembering); threading/listeners/... Implementing your own, rather
than using OffsetsBag, sounds risky and bug prone and extra work. Why
did you make that choice?
I'm lazy, I'd probably start with the whitespace implementation. Maybe
1. copy whitespace and just do EOL with it
2. starting with 1. evaluate incorporating it into whitespace.
Possibly 1. could be made into a plugin to get some feedback, then roll
that into NB proper or merge it into whitespace.
-ernie
On 6/23/2020 2:48 PM, Dmitry Semikin wrote:
> Hello Everyone,
>
> The topic does not seem to attract too much attention, but I hope, it is just lack of time. It is the same for me, so the progress does not go as fast as I’d like it to…
>
> 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
>
> Besides after some wandering around in the depths of NetBeans projects I found, where the highlightings for whitespaces are implemented. The following files are involved:
>
> HighlightsContainer implementation for Whitespaces:
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\WhitespaceHighlighting.java
>
> Corresponding factory:
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\Factory.java
>
> Registration of the factory is done in the following layer.xml:
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\resources\layer.xml
>
> Specification of the categories (~FontsAndColors.xml)
> netbeans\ide\editor\src\org\netbeans\modules\editor\resources\NetBeans-editor.xml
> It's virtual path in Layer.xml:
> Editors/FontsColors/NetBeans/Defaults/org-netbeans-modules-editor-highlight-colorings.xml
>
> Layer.xml, in which NetBeans-editor.xml is actually registered:
> netbeans\ide\editor\src\org\netbeans\modules\editor\resources\layer.xml
>
> Localization of the category-names shown in options dialog
> netbeans\ide\editor\src\org\netbeans\modules\editor\Bundle.properties
>
>
> So I see two possibilities, how the EOLs could be treated:
>
> - Handle them together with whitespaces in WhitespaceHighlighting.java.
> - Or create separate HighlightsContainer specifically dedicated for EOLs.
>
> Could someone suggest, which approach is better? I personally would rather go with the second one for two reasons: first, then I would use the solution, which I already have. Second, if something goes wrong, it is more independent, so it is easier to remove the changes.
>
> I tried to check, who did the changes to the mentioned files recently, but it seems, that they were not modified since the donation of the source code to Apache Foundation. I don’t see the history further backwards. Original authors of those two classes are Miloslav Metelka and Vita Stejskal. If these people are still involved in the development, probably they could give me some advice.
>
> I would be very grateful to anyone, who could give any comment or advice.
>
> With kind regards,
> Dmitrii Semikin.
>
>
>
> On 2020/06/15 21:33:07, Dmitry Semikin <dm...@gmail.com> wrote:
>> Hello Everyone, hello Christian,
>>
>> Thank you for your hint. Looking at the module you pointed to and at “NetBeans Mark Occurrences Module Tutorial” I put together a module, which kind of does the job. It is not yet completely ready, but I have couple of technical and organizational questions:
>>
>> - 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?
>> - 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.
>> - Which Z-Order would be reasonable for EOL?
>> - HighlightsLayer.create() function takes as input “fixedSize” parameter, which, if I understand it correctly should tell they system, if the text-size may change as a result of highlight. In my understanding this depends on the AttributeSet used. My question is: is there some utility function, which would define “fixedSize” parameter based on provided AttributeSet, i.e. return “true”, if the AttributeSet explicitly contains font family or font size etc.?
>>
>> Another couple of question related to integration to Netbeans:
>> - 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?
>> - If existing module, which one?
>> - If new module, what is naming convention for the module and for the package (suggestions for the specific names would be nice).
>> - Are any automated tests needed for this particular case? What is considered to be useful to test?
>>
>> The actual state of the module is available here:
>> https://github.com/DmitrySemikin/nb-eol-highlighter
>>
>> Any additional suggestions and critics are very welcome.
>>
>> My further planned step for now is to replace implementation, which re-scans whole file for every change with the implementation, which only checks the changed fragment of text. Then try to figure out myself (or with the help of the answers, if any), how to specify colors using options dialog.
>>
>> Thanks in advance for any kind of comments.
>>
>> Dmitrii.
>>
>> On 2020/06/09 08:05:28, Christian Lenz <ch...@gmx.net> wrote:
>>> Hey Dimitrii,
>>>
>>> cool to hear that you want to work on it. Maybe you can find some more insights in this plugin too: https://github.com/tunnelvisionlabs/goworks/tree/master/tvl.editor.whitespace
>>>
>>>
>>> Cheers
>>>
>>> Chris
>>>
>>>
>>> Von: Dmitrii Semikin
>>> Gesendet: Dienstag, 9. Juni 2020 08:29
>>> An: dev@netbeans.apache.org
>>> Betreff: Re: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
>>>
>>> Hello once again,
>>>
>>> I did some digging and I hope, I realized the general idea about coloring. There are categories of tokens defined in Lexer of specific language. And there are "fontsColors.xml" files, which provide mapping of the categories of tokens to particular color. They also provide the list of coloring categories for the Options dialog.
>>>
>>> So, to provide option for the coloring of EOLs separately one would need to:
>>> - Introduce new category of tokens in the language lexer (ultimately, in lexers for each language, if we want to have this feature in every language).
>>> - Adjust "fontsColors.xml" to provide coloring-category and default values for the color.
>>>
>>> Could someone confirm, that my understanding is correct (or point out that it is not correct, maybe providing also some hint about what exactly is wrong)?
>>>
>>> Could someone also tell, if it is a good idea to modify lexers for languages e.g. like Java (being honest I did not look at the implementation yet)?
>>>
>>> Thank you in advance.
>>> Dmitrii.
>>>
>>>
>>> On 2020/06/06 15:54:25, Dmitrii Semikin <dm...@gmail.com> wrote:
>>>> Hello Everyone,
>>>>
>>>> There is an issue: NETBEANS-1678 : Option for coloring EOL (https://issues.apache.org/jira/browse/NETBEANS-1678).
>>>>
>>>> I prefer to have whitespace characters on, but find it annoying, that EOL is displayed with the same color as normal text - balck (too bold for me).
>>>>
>>>> I woud probably try to implement this feature. So I would be greatful, if someone could point me to the place in code, where some similar coloring feature is already implemented (it would also increase chances, that it will be done :)). Also any addiitional ideas, suggestions or advices regarding the implementation would be very appreciated. I should say, that I have some idea about development for NB platform, but I am still rather inexperienced.
>>>>
>>>> Thank you in advance.
>>>>
>>>> Dmitrii.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>>
>>>> For further information about the NetBeans mailing lists, visit:
>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>>
>>
> Sent from Mail for Windows 10
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
Posted by Dmitrii Semikin <dm...@gmail.com>.
Hello Ernie, Svata and Everyone
First of all thank you for your detailed answers. I think, it should give me
the direction, where to move further.
Still I wanted to answer to some of your comments (and probably ask some more
questions). I will answer to both emails at once. I hope, it should not cause too
much confusion.
Related to OffsetBag:
[Ernie]:
> I haven't looked at highlighting for a long time, I seem to recall that
> OffsetsBag had quite a bit of functionality (and I could be
> miss-remembering); threading/listeners/... Implementing your own, rather
> than using OffsetsBag, sounds risky and bug prone and extra work. Why
> did you make that choice?
[Svata]:
> If you do not modify directly the WhitespaceHighlighting, which computes
> the chunks lazily, consider using the OffsetsBag
The tutorial uses OffsetBag, so I started with the implementation, which uses
it, but it also updated highlights for the whole document for each change.
This worked fine, but I guess, the performance is not optimal. I decided, that
I want to make sure, that at least on edits only the modified part is updated
(probably there are still better approaches, but this will be discussed
later). When I tried to implement the new version, where only part of the
OffsetBag was either removed or added, then I've got very strange effect, that
highlight flickers after some text is removed (or several lines are pasted at
once). The flickering happened, when one just moves the cursor around (so even
the document was not modified). I look a bit into the problem and noticed,
that when I remove highlights from the OffsetBag, they are not completely
removed, but just become 0-length. After some fiddling with it I managed to
make the highlights really be deleted, but even then flickering did not go
away. At that point I decided, that I will try to implement
HighlightsContainer myself. The logic is not too complicated (even though, as
Svata pointed out, multithreading issues should be addressed).
Regarding OffsetBag, I have no idea, why it happens... Maybe I used it wrong,
but I don't think so. Unfortunately I did not keep the implementation.
Probably I will try to re-create it in separate branch, if someone finds it
useful.
[Ernie]:
> I'm lazy, I'd probably start with the whitespace implementation. Maybe
>
> 1. copy whitespace and just do EOL with it
> 2. starting with 1. evaluate incorporating it into whitespace.
>
>
> Possibly 1. could be made into a plugin to get some feedback, then roll
> that into NB proper or merge it into whitespace.
Yes, thank you. My thoughts are not exactly like this, but go in the same
direction. :)
All further citations are from Svata.
> Looking at the impl, there will be slight performance issues, especially
> with large documents w/ lots of small lines (xml, html, ...).
Do you mean only on startup? Or generally. On startup - I agree, because the
whole document is processed at once. I admit, that I did not profile, but I
guess, that the penalty should be not to high even for several thousands of
lines... on the other hand, it is very generic highlight, so it probably
should survive also opening Log-files several Gb long... In this case
appproach with processing only the part, which is currently shown is much
better. The problem is, of course, that inside the HighlightsContainer we
don't explicitly control, for which region HighlightSequence will be
requested. Of course, we may hope, that the requested range is normally for
only part of the text, which is shown at the moment. Then it is quite small
and we can calculate it on the fly. This approach sounds for me more univeral,
so I will try it (and probably also do some profiling with long files).
> 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.
Unfortunately in the HighlightersContainer itself we don't
control it, so we cannot guarantee, that it is the case. But from common sense
point of view, most likely it will always be the case, so probably we still
can rely on this assumption.
> If you do not modify directly the WhitespaceHighlighting, which computes
> the chunks lazily, consider using the OffsetsBag:
see above
> callbacks like
> insertUpdate/removeUpdate may happen in any thread, while hightlight
> sequences are likely to execute in EDT thread.
I am not 100% sure, but I beleive, highlights SPI documentation makes some
statements about it...
> Your code is not
> thread-safe maintaining highlightsStartOffsets; at least, the
> EolHighlightSequence should get an immutable copy of the list.
Thank you for pointing this out. I will check it and adjust according to you
suggestion.
> 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.
This behaviour (throwing this exception) is described as required by SPI
documentation.
See e.g. here:
http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/org/netbeans/spi/editor/highlighting/HighlightsSequence.html
Implementation: Any HighlightsSequence obtained from any of the classes in the Highlighting API will behave as so called fast-fail iterator. It means that it will throw ConcurrentModificationException from its methods if the underlying data (highlights) have changed since when the instance of the HighlightsSequence was obtained.
> > - 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) ?
>
This is good point and also a question from my side. I also was thinking about
just implementing highlights for EOL, which would use same attributes as
"trailing whitespaces". On the other hand, the issue, which I referred to
originally (NETBEANS-1678) suggest creation of new category.
So, could you tell, what should be the solution from the user point of view?
Should just EOL respect the defined highlight style for trailing-whitespaces?
Or should it get independent category in highlights section in Options window?
> >> - 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.
.. well, so it looks like this point needs further investigation. By the way,
this may be a problem, if we want to incorporate EOLs into trailing
whitespace. I guess, that some people want to use background color to make
trailing whitespaces visible (and even annoying), but if with EOL the
highlighting will be spanned till the end of the line, the whole idea will be
broken...
> >> - 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.
OK. I will also look at the existing tests for whitespaces (now I can do it, as I found, where
the functionality is implemented).
As a next step, I will try to look more carefully into implementation for trailing whitespaces, and try to understand, if adding EOLs there is a complicated task.
Besides, I will have a look at automated tests.
The questions about highlight spanning to the right border of the editor, and about my problems with OffsetBags are still open. Maybe I will try to look into it either, but I am not sure, that I will find time soon.
Thanks again to everyone, who spends his/her time to read these emails and share the thoughs.
Best Regards,
Dmitrii.
On 2020/06/24 14:49:49, Svata Dedic <sv...@gmail.com> wrote:
> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point
at similar code?
Posted by Svata Dedic <sv...@gmail.com>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists