Mechanism to watch & dynamically reload coverage results

[dbarnett]

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]

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]

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

• Update s:cache for the file with the new report
• Silently un-place and re-place any signs for the report, if has_key(s:visible, file)

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]

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]

👍 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:

• For providers, optional:

provider.UpdateCoverage({metadata})
provider.UpdateCoverageAsync({metadata})

• For the main plugin, to delegate to the provider and update cache/signs:

coverage#UpdateCoverage({provider_name}, {metadata})

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

[dbarnett]

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.