Community
Participate
Working Groups
Created attachment 271707 [details] Element Info example Example: public static final int MAX_SPEED = 240; F2 / Hover: int com.example.counter.CharacterCounterExample.MAX_SPEED : 240 [0xf0] The value 240 should be colored like literals inside source code editor. this would reduce the time to detect the value of constants.
I think what you are asking for is full syntax coloring in hovers where currently the only adornments are linkifying and rendering of javadoc. If so, that would be a big task, potentially one where help from the community would be needed. @Noopur, how similar are javadoc hover and source hover? In case we'd want to support this request, would it be feasible to copy functionality from the source hover, which has this highlighting? Another problem might be the choice of colors, since hovers have their own sets of colors which may not be compatible with the syntax colors in source editors.
(In reply to Stephan Herrmann from comment #1) > @Noopur, how similar are javadoc hover and source hover? In case we'd want > to support this request, would it be feasible to copy functionality from the > source hover, which has this highlighting? Javadoc is presented as HTML whereas source is a string where syntax coloring is applied via source viewer configuration. So both are different. If constant values are colored in Javadoc then it should be done for both Javadoc hover and Javadoc view, keeping the following in mind: > Another problem might be the choice of colors, since hovers have their own > sets of colors which may not be compatible with the syntax colors in source > editors.
The request from Michael is not to replicate the correct syntax highlighting in the Javadoc view/hover but to use a different highlighting to make it easier to see this. So we could use a different fixed color. I agree with Michael that is is currently hard to see the value (and the value is really important for a constant).
(In reply to Lars Vogel from comment #3) > The request from Michael is not to replicate the correct syntax highlighting > in the Javadoc view/hover but to use a different highlighting to make it > easier to see this. So we could use a different fixed color. I agree with > Michael that is is currently hard to see the value (and the value is really > important for a constant). Michael filed this as a bug, not an enhancement request, which made it appear that he believes syntax coloring is already in place, just one particular aspect is not working. Since the assumption is wrong, no syntax coloring is applied, I changed it to an enhancement request, with a scope that would be consistent: full syntax coloring. Perhaps Michael should speak for himself, if he wanted that partial (I'd say: inconsistent) solution of highlighting one aspect while leaving the rest in monochrome. As a rule of thumb, with such partial implementation the next bunch of users will consider any missing aspect of syntax coloring as a bug, not an enhancement. I'm pretty sure though (in correspondence with Dani setting this to wontfix) that no-one in JDT/UI has time to spare for this feature - neither partial nor complete.
(In reply to Stephan Herrmann from comment #4) > > Michael filed this as a bug, not an enhancement request I told Michael to ignore this classification because nobody is using that. I was wrong.;-) > Perhaps Michael should speak for himself User new to our process are typically shy, but I discussed Michaels requirements with him in person. > I'm pretty sure though (in correspondence with Dani setting this to wontfix) > that no-one in JDT/UI has time to spare for this feature - neither partial > nor complete. Bug is already correctly marked as "helpwanted".
(In reply to Lars Vogel from comment #3) > The request from Michael is not to replicate the correct syntax highlighting > in the Javadoc view/hover but to use a different highlighting to make it > easier to see this. So we could use a different fixed color. That's what I call an inconsistent or incomplete solution. I don't see anyone in JDT/UI adopting this, even if an implementation is contributed. > I agree with Michael that is is currently hard to see the value I disagree, I have no problems seeing the value. > (and the value is really important for a constant). I disagree again. The purpose of a constant is to abstract over its value. Needing to know the value should be an exception, not the rule. (In reply to Lars Vogel from comment #5) > Bug is already correctly marked as "helpwanted". I set this flag wrt the solution of full syntax coloring.
(In reply to Stephan Herrmann from comment #6) > (In reply to Lars Vogel from comment #3) > I don't see anyone in JDT/UI adopting this, even if an implementation is > contributed. Noopur as project lead, what do you think?
