The coding work for the Second Phase has been done (with the last of the Pull Requests waiting to be merged). Expect a blog post regarding the same in the next week. This post is regarding the research work and prototyping that needs to be done before the next phase and also explaining those ugly gray boxes in my GitHub contribution history.
Currently, the plugin runs and emits results in JSON which is being parsed. After this comes the main part of interpreting the parsed data to annotate inside the IDE.
In this previous blog posts, I wrote about the method which can be used to highlight information and create tooltips inside the IDE. Behold
HighlightersUtil.setHighlightersToEditor(). But while prototyping the plugin, I realized this method works fine but the problem with it is that the highlights disappear once a document is changed. Let’s say, all the warnings and errors are highlighted in the document you’re working on. One of the inspection says there is a typo in a word. You quickly fix it but guess what, all the other highlights disappear. That is something we definitely don’t want. The highlights need to stay until that user manually clears them or a new analysis is run on the file. Apart from this even if the highlights stay, their positions go absolutely haywire if the document is modified. This is because the highlights are tied to the absolute offsets inside the document. If the highlights were tied to the actual elements that could be easily solved.
To solve the above problem (partly), we can use a
RangeHighlighter in conjunction with
RangeHighlighter as the name suggests highlights a particular range inside the document. And the best part? The highlight is tied to the actual elements so that even if the elements are shifted, the highlight still sticks to them.
However, this only solves the
color highlighting part. Highlights without any text information are pretty much useless. So currently I’m going through their documentation, other similar plugins, Stack Overflow, Gitter channel, wherever I think I would find a solution to this problem.
There is another method I could go with, that is creating a
LocalInspectionTool. But as you might’ve guessed this API is automated, that is it automatically kicks whenever the document is changed. We don’t want that. I even stumbled upon a similar problem which someone else faced (and solved) here. The Only problem is that the code seems a bit old and doesn’t work as expected. Moreover, the official documentation states that
Annotator is more flexible as compared to
LocalInspectionTool, hence going with the former makes sense.
Anyways, I’m still going through the documentation and continuously finding other alternatives that could be used to solve this issue. It’s only a matter of time before I get ahold of that solution!