google / vim-coverage

Apache License 2.0
102 stars 22 forks source link

Mechanism to watch & dynamically reload coverage results #43

Open dbarnett opened 3 years ago

dbarnett commented 3 years ago

After doing :CoverageShow, could you have vim watch whatever .coverage file it loaded results from and immediately notice and reload results if that changes? For example, if you run nosetests --with-coverage outside of vim and that generates new coverage results for the current file, could the plugin immediately discard the stale results and show the fresh ones?

Note we already have #27 to have a manual way to reload coverage, like :CoverageShow!.

dbarnett commented 3 years ago

I don't think this needs to be built-in functionality in the plugin, just want to make the plugin mechanics compatible with a workflow like this, thinking of those slick toolchains that automatically rerun tests when you save changes to a source file.

As a very hacky workaround, you could watch the file from outside vim and inject a coverage#Show call whenever it updates with something like

ls .coverage | entr vim --servername GVIM --remote-expr 'coverage#Show(1)'

but that's very manual and coverage#Show doesn't even correctly update coverage for specific affected file(s). I'd want some cleaner entry point to tell the plugin new coverage results are ready for some files, and then you could pragmatically hook up to that from whatever polling/heuristics/notify strategies might be available.

okkays commented 3 years ago

Are you envisioning something as simple as coverage#UpdateCoverage({file}, {report}), that would:

It seems like then we could work on making it easier for providers to watch/poll for updates (perhaps with a new maktaba#path#Watch or something).

This would leave the tasks of watching coverage data and merging reports to the providers, which I think makes sense, because otherwise we'd have to give the main plugin knowledge of provider data and do a bit of reorganization.

dbarnett commented 3 years ago

Yep, that should basically do the trick! It should probably identify which provider it's providing for.

The code for generating reports from e.g. an lcov file should live in the coverage plugin, I'd think. The plugin could just have an assortment of public helpers available for that, such as a coverage#gcov#ParseReport, or to minimize the back-and-forth logistics it'd also be possible to pass in some higher-level metadata instead of a final generated report, and let the provider take it from there. For example, that could look like

call coverage#UpdateCoverage('gcov', {'lcov_filename': '/some/path/coverage.dat'})

And then the contract of what metadata to pass could vary per provider as needed.

okkays commented 3 years ago

👍 cool, I think we're on the same page then. Since the current provider schema is GetCoverage({filename}) and GetCoverageAsync({filename}), I'll probably go with:

The provider-specific metadata is especially nice for providers that source coverage from RPCs instead of files

dbarnett commented 3 years ago

Perfect, looks good to me!

The provider-specific metadata is especially nice for providers that source coverage from RPCs instead of files

My thoughts exactly! Could take a URL or a blob of already-fetched data, just whatever tends to make sense for the given provider.