tracking gutter icon locations reliably
I'm writing a plugin that displays gutter icons + some UI in Java files, with data that gets fetched periodically from
a service. The service gives me line numbers and the message to display, and it is not aware of local
changes to the files.
My question(s): What is the best way to display gutter icons on a per-line basis, and still have it update
reliably with editor changes? Is there a way to transpose line numbers across VCS commits?
Massively Redundant Context: My current implementation:
-
I have a model for messages. There is a `Fetcher` class that periodically pings my service
to get the latest messages. If there is new data (or existing data has changed), the fetcher notifies
the other components.
-
I use a `LineMarkerProvider`. Inside `collectSlowLineMarkers`, I associate messages with the
closest (and smallest) possible PsiElement. I keep additional state to make sure that I never
do this more than once for a given message (to avoid flickering / multiple icons showing up
during changes to the Psi tree).
Overall, this works reasonably well, but there's a few problems that I would like to address:
- Big changes to a Psi tree cause all gutter icons for that file to disappear (presumably because
the PsiElements I've associated my LineMarkerInfo instances no longer exist). I'm not sure
how to detect this (or avoid the problem in the first place).
- If a file has been changed, and new messages arrive from the server, then new messages will
end up in the wrong location (because the service is unaware of local file changes). Ideally,
within reason, I should translate the line number across local VCS changes before finding
a PsiElement.
Thought on either 1. or 2. would be very welcome :)
请先登录再写评论。
You can store unique values as UserData (putUserData) on any psi element, That data will survive a PSI tree merge assuming rhe PsiElement does. That might help with your disappearing nodes problem. The same rule can apply to the file as a whole. You can give it a unique identifier, and have your query service return this identifier so that it tells you whilch version of the file it refers to