Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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-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
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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 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 La
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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 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 go
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 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. >
Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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 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 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-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.
AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?
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 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-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 > > > > - 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