Community
Participate
Working Groups
I would like to drop here a new feature request. I think it would be very useful to highlight all variable occurrences when the editor’s cursor is located over the variable. It’s also useful to be able to navigate between these occurrences to understand the variable usage evolution. I have already written plugins for JBuilder and JDeveloper that do this. If you want to see how it works, you can get them from http://home.t- online.de/home/simeon.zverinski/variablehighlighter/.
Sounds like a good feature.
First of all, I'd like to thank you for accepting and implementing this feature. I was looking on your progress in this regard and it looks very promising. And I really like the idea of extending occurrence highlighting to all "java items". BTW, I've got some mails where people say they miss this feature in Eclipse. I suggest, there are two things that can improve the usability of it: 1. Occurrence navigation. In my plugin for JBuilder it's possible to move the cursor to the previous, next, first and original occurrences by pressing ALT- Arrow keystrokes. It is very useful for relatively big classes to check, for example, all variable assignments. 2. The highlighting delay should be applied only when a document is changed. When the cursor is moved, it shouldn't be any delays to highlight a new occurrences under it. Thanks again for your work, Simeon
re 1: good idea re 2: the occurrence marker is a post selection listener hence the delay. This is intentional (performance). Did you see the new Occurrence preference page (I20040428)?
I've looked at the new preference page and, as you could expect, I like it :) And if you go in this direction, then the next step would be to implement different configurable highlight colors for different occurrence types. For example, it could help to distinguish local variables from class fields. Regarding the delay, I don't really understand the performance problem. The only heavy operation is the code parsing, which really requires a delay during typing. But when the caret is moved, the document is not changed. In my plugin I use some optimized information collected during parsing to highlight variable occurrences and it works quite instant for caret movement. I'm not familiar with your implementation, but even if you traverse the AST, it should be fast enough for the majority of the modern computers. I really don't think this issue is so important to spend significant efforts for making it better (I just get use to something different). But could you make the delay configurable?
>For example, it could help to distinguish local variables from class fields. Checkout yet another pref page: Java > Editor > Semantic Highlighting It is a time/space question: keeping an AST is discouraged due to it's size hence we have to compute it whenever the selected Java element changes.
Java > Editor > Semantic Highlighting - great! What is the size of AST that it's a problem to keep it for several opened editors? I thought it's kept anyway as a model for the Outline view. Could you keep it only for one active editor? Did you consider to use a weak reference? And I think there is another drawback with your approach. If you compute AST for every caret event, you create a lot of objects in memory that causes GC to be run more often than necessary. And GC delays are really annoying.
>What is the size of AST that it's a problem to keep it for several opened >editors? Ask on the J Core mailing list. > I thought it's kept anyway as a model for the Outline view. No: AST and Java Model elements is not the same. What makes you think so? >Could you keep it only for one active editor? Did you consider to use a weak >reference? We already do this i.e. we keep at most one in the cache. What makes you think we don't do this? Note: if you work in one editor then we "only" do the occurrence searching not the AST creation. >And I think there is another drawback with your approach. If you compute AST >for every caret event, Correct: we should either cache the last Java element or ast node key for the caret position and only search occurrences if this changed. Can I adapt the summary to reflect this?
> > I thought it's kept anyway as a model for the Outline view. > No: AST and Java Model elements is not the same. What makes you think so? I'm not familiar with your implementation. I thought it just could be. > >Could you keep it only for one active editor? Did you consider to use a weak > >reference? > We already do this i.e. we keep at most one in the cache. What makes you think > we don't do this? Note: if you work in one editor then we "only" do the > occurrence searching not the AST creation. This makes me really confused. Didn't you say in the comment # 5: "It is a time/space question: keeping an AST is discouraged due to it's size hence we have to compute it whenever the selected Java element changes." ? > >And I think there is another drawback with your approach. If you compute AST > >for every caret event, > Correct: we should either cache the last Java element or ast node key for the > caret position and only search occurrences if this changed. It's even more confused for me. I was talking about AST creation, because it was my understanding from the comment # 5. It seems you really ment something different. > Can I adapt the summary to reflect this? OK. My point from the beginning was: if you don't create a new AST with each caret event (now I know - you don't!), the occurrence search operation should be fast enough to avoid any highlight delay usage when a caret is moved. If you could manage it, I'm sure you will like it too.
time permitting for 3.0
no action for 3.0
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Is something going to be done about this for R3.1?
Thanks to the document modification stamp that I just introduced this week I could nicely improve this. We now only recompute if the caret is outside the word that caused the previous computation.
