Community
Participate
Working Groups
Taking out the the details from https://bugs.eclipse.org/bugs/show_bug.cgi?id=547665#c31 and #https://bugs.eclipse.org/bugs/show_bug.cgi?id=547665#c32 Lars wrote: One of the things I find not good about this feature is that is makes the code jumpy if I'm writing new code, e.g.: String s = "Hello"; -> Warnings jumps in that the code is unused. If I use now s, the warning goes away again which makes the text in the editor jump again up. Not sure what to improve here, so I cannot open a bug but maybe others have an idea. Sarika wrote: Also, like we just wrote sysout , it shows the syntax error and hence a line jump. After we complete it the error disappears and again a line jump. Can we have a quick way to disable/enable this from editor itself? So when we are doing active development we can just turn it off and after a logical end we can enable it. Going to Preferences page every time is tedious.
Niko or Mickael, can you please have a look for M1?
> Can we have a quick way to disable/enable this from editor itself? So when we are doing active development we can just turn it off and after a logical end we can enable it. Going to Preferences page every time is tedious. I don't think a quick way to enable/disable it is worth it: it would still require going to menus and so on, or allocating a shortcut (for which there aren't many slots remaining). Instead, I suggest we discuss what would be the desired behavior. Would you like the code mining "space" to remain (even empty) on the line you're editing if a code mining has been displayed once while typing on this line, and then removed (if empty), when moving to a new line?
I thought about this a bit, without implementing anything yet. What are the issues? (assuming we edit a Java file) 1) As soon as we stop typing for ~100 ms, the JDT parser kicks in. As it's really fast, it will report all the errors of our broken intermediate state of the edited file. Example: We are in a method body and type "sysout". Before we hit Ctrl-Space to auto-complete, we pause to think what we want to print. JDT parser kicks in, and tells us that "sysout" cannot be recognized. This gets even worse if we effect other parts of the file. For example, we type "}", pause, and JDT gets very confused about the rest of the file (because we didn't yet add the corresponding opening brace above). This leads to lots of errors, thus lots of added annotation lines. 2) For actual errors, the annotations disappear and appear again. This makes all the following lines jumping up and down. I'd see this as a synchronization issue between error annotations and JDT -- or any other underlying error-producing source, respectively. I see several solution approaches: a) Provide toggle command, possibly with default key binding b) Update code minings only on some event, e.g. save c) Limit the update rate of annotation code minings d) Handle added/changed and deleted annotations differently Ad a): Providing the command should not be an issue. Whether we have a default binding needs to be discussed, there were some remarks that there aren't that many bindings available any more. In any case, Ctrl-3 should give quick access, and everybody is free to configure their own binding. However, this is only a crude way to soothe the issue, not even a workaround. Ad b): The previous implementation reacted only on markers, so effectively it only changed on save. I found this extremely annoying, because the error stayed in the editor even after I fixed it (until I pressed Ctrl-S). If we find another fitting event this might be an option, though. Ad c): If we updated the annotations e.g. at most once every second, the jumping should be reduced. It still serves the purpose to see errors without mousing around. We're not capable of understanding the error message in less than a second anyway: We have to read it, understand it, and relate it to the written code. As a drawback, every now and then (i.e. several times each coding hour) we will happen to hit our second mark at the moment when all errors are gone. Then they disappear, the whole text moves around, only to move back in the next second. More generally, solving synchronization issues (see issue 2)) with waiting seems a bad approach. We could wiggle out of this argument by stating timing as the actual issue here: The problem is not that lines disappear and appear again, but that they do this often and rapidly. I don't think it's feasable to properly synchronize with all possible error-producing sources. Ad d): We currently react the same on any change to the annotation model: We trigger a recalculation of code minings immediately. However, the annotation model reports additions, changes, and deletions separately. We could delay the recalculation if we got only deletions, and speculate that the persisting errors are already re-added by then. This approach doesn't help much with issue 1). It also bears the same "waiting to solve synchronization" smell as approach c). Both c) and d) assume the jumping originates from the annotation code mining provider, not from code mining itself. I guess that's valid, but didn't test it thoroughly.
*** Bug 558461 has been marked as a duplicate of this bug. ***
Removing for M1 as a quick solution for this week seems hard to reach. Keeping for 4.15 though.
From Forum: https://www.eclipse.org/forums/index.php?t=rview&goto=1819554 Eclipse 4.14 added support to show problem markers inline in text editors ( mentioned in News & Noteworthy). I tried them out for a bit and found that I'd really like to have them for warnings, e.g. when I'm cleaning up code. However, the problem markers are also displayed for errors and this don't seem to play well with the incremental compilation and my development. Generally, errors are displayed while I'm still not finished with the part I'm working on. This is fine for markers on the side or in the problem view but with inline markers, it is very annoying for me. Is there a way to get problem markers inline for warnings only? The options in the GUI don't support "warnings but no errors". I also tried to find a way to switch between "activate inline problem markers" and "deactivate inline markers" but I didn't find a matching hotkey in the keys view.
Maybe we should try to filter out the errors codeminings that are on the line that has cursor if the file is dirty?
As I'm reading the comments, I have the impression that the main issue isn't really the code mining appearing and disappearing per se, but just the line jump that makes the current line that has cursor currently jumping, right? Fixing the line jump might be more easily actionable and more generic.
(In reply to Mickael Istria from comment #8) > As I'm reading the comments, I have the impression that the main issue isn't > really the code mining appearing and disappearing per se, but just the line > jump that makes the current line that has cursor currently jumping, right? > Fixing the line jump might be more easily actionable and more generic. Yes, Like for String s = "Hello"; After that try sysout and ctrl+Space-> Code mining error goes comes and at the end cursor is after "Hello";
(In reply to Sarika Sinha from comment #6) > Is there a way to get problem markers inline for warnings only? You can actually do that, although the UI does not support it. 1. Close your Eclipse 2. Open file in text editor: <workspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.editors.prefs 3. Find the line (it's only added once you changed your code mining settings) showAnnotationAsCodeMiningLevel= 4. After the equals sign, you'll find a number. The number encodes in binary: 1110b | no code minings | code minings for infos | code minings for warnings | code minings for errors However, it's stored in decimal, so you have to convert it. If you want no errors, but warnings and infos as code minings: 0110b = 6d 5. Change the line to showAnnotationAsCodeMiningLevel=6 6. Save the file 7. Start Eclipse
(In reply to Mickael Istria from comment #7) > Maybe we should try to filter out the errors codeminings that are on the > line that has cursor if the file is dirty? I don't think this helps too much, as any time you mess up the syntax a bit more the parser gets confused, and lots of errors will appear below your edited line (for a short period).
(In reply to Niko Stotz from comment #10) > (In reply to Sarika Sinha from comment #6) > > Is there a way to get problem markers inline for warnings only? > > You can actually do that, although the UI does not support it. > User has reported Bug 559319.
In https://git.eclipse.org/r/#/c/158055/, I gave approach d) from comment 3 a shot. I'm not working a lot with Eclipse atm, maybe somebody can try how much this changes in real-world scenarios?
(In reply to Niko Stotz from comment #13) > In https://git.eclipse.org/r/#/c/158055/, I gave approach d) from comment 3 > a shot. > > I'm not working a lot with Eclipse atm, maybe somebody can try how much this > changes in real-world scenarios? Tried this patch, but the Comment #9 behaviour still exists.
Too late for 4.16 now.
While I enjoy the code minings the jumpyness anoys me, too. Here's another idea: add an option to show the code mining *below* the line it refers to instead of above. It still would result in jumps - but just below the line I'm editing, so it might be less annoying.
(In reply to Dirk Steinkamp from comment #16) > While I enjoy the code minings the jumpyness anoys me, too. Can you please provide some detailed steps to reproduce for the cases where you're annoyed by this jumps?
(In reply to Mickael Istria from comment #17) > (In reply to Dirk Steinkamp from comment #16) > > While I enjoy the code minings the jumpyness anoys me, too. > > Can you please provide some detailed steps to reproduce for the cases where > you're annoyed by this jumps? It's all the same as the others already described: - eclipse version 2020-09 - Code minings are enabled (e.g. "show code minings for problem annotations" ==> "errors only") - Go into some java file's method - start typing, e.g. String s = "hello world ==> the line I'm editing moves (jumps) down, and the mining shows up "String literal not properly closed by a double-quote" - complete the statement: String s = "hello world"; ==> the mining disappears and the line moves (jumps) up again But that's not different from what the others already wrote ... is it? My suggestion is just to add an option that allows to display the minings *below* the line they are referring to -- thus the line I'm editing would not visually "jump" around (yet the lines below would).
(In reply to Dirk Steinkamp from comment #18) > But that's not different from what the others already wrote ... is it? No, it's not. But several issues were mentioned in this ticket. I wanted to verify whether yours was already listed or was a new one. I think bug 569550 can be a decent fix here.
(In reply to Mickael Istria from comment #19) > (In reply to Dirk Steinkamp from comment #18) > > But that's not different from what the others already wrote ... is it? > > No, it's not. But several issues were mentioned in this ticket. I wanted to > verify whether yours was already listed or was a new one. > I think bug 569550 can be a decent fix here. ah, okay. thanks. Solution proposed in bug 569550 looks good to me - I'll vote for it, too :-).
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173663
(In reply to Eclipse Genie from comment #21) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/173663 I'm going to move it to a separate bug report in SWT.
With the change in SWT StyledText, things get better: the line that has the caret will not move when code-mining is added, other lines above will move and leave space for the code mining without shifting the current "active" line. The only case where this issue can occur is when editor is at the very top, not scrolled down, top-pixel=top-index=0. In this case, SWT cannot move/scroll the visible area to keep the line position constant, and the line still move. That is still annoying with completion turned on as the line being edited my move down, below the completion dialog. I opened bug 569677 on this topic.
I tried the recend 2021-03M3 and the jumpiness seems to be considerably removed as the currently edited line is "held fixed" :-). Now only everything above the current line moves jumpily up and down. ;-) One more suggestion: one way to maybe even improve the jumpiness of the lines above would be to keep the space of a code mining "reserved and empty" while editing the current line, even if the code mining disappears. This would result in only the code mining being shown or hidden - depending on the state of the currently edited line - providing prompt feedback, yet reducing the jumpiness. Then, when moving the cursor to another line any empty "left-over" empty code mining line could be purged.
