deathaxe
commented
6 years ago I absolutely agree with your last statement.
All information are assigned to the main GitGutterCommand of a view, which is the reason for all commands to be proxied to it. Accessing those data directly might be a bad idea as the structure might change in the future.
There are some thoughts about using the EventListener as a kind of server to provide those information on a per event base and expose them to the rest of the components (clients). This would allow an API for external plugins, too. But it's kind of far away from implementation and would cause some significant changes.
Most parts of the data processing would need to be moved from the GitGutterCommand over to the EventListener, which already handles a dictionary of all open views.
This would end up in some kind of DiffProvider which can be exposed as an API.
This would definitely need some time to be designed and tested.
EDIT: If you just need to query the changed lines you could call:
view.get_regions("git_gutter_inserted")
view.get_regions("git_gutter_deleted_top")
view.get_regions("git_gutter_deleted_bottom")
view.get_regions("git_gutter_deleted_changed")
Description
This may well be possible already, but poking around I couldn't quite see how. I'd love it there were a way to leverage git gutter's knowledge of which lines in a file have been edited in another plugin. Some way of determining a set of lines that have been added/removed/modified so that I can use that to drive a simple comment association UI. (I want to try and specify what lines a comment refers to and then highlight that comment when any of the lines it covers have been modified)
It doesn't make sense to me to have a host of different plugins all running the same git commands, so being able to leverage GitGutters existing knowledge seems like a better option.