Open blueyed opened 6 years ago
Yes, :CoverageShow!
sounds reasonable.
May also want to automatically expire the cache after some time or other criteria.
It could happen based on the provider, e.g. coveragepy would look at the timestamp of the .coverage file. Should there be a provider callback to return the timestamp for the information of a given file? (for when you might have multiple sources)
Couldn't the provider maintain that state internally?
I think the caching happens before the provider is called?! Or do you mean the caching should be done by the provider then, and it is responsible for providing the current data always?
Good point. We pbb do want to change the interface so the provider handles more of the caching considerations. Either way, the current provider interface wouldn't support expiring the cache intelligently.
Ok, some plan:
s:RenderFromCache
into s:CoverageShow
, i.e. call coverage#ShowCoverage
there, i.e. move s:CoverageShow
also into coverage#ShowCoverage
coverage#CacheAndShow
, or make it call coverage#ShowCoverage
if B/C is important
…Trying this now (and before) however makes me really feel like this could be a quest, where the correct answer is "just re-write this from scratch".. :( (sorry that this sounds rude, but given the unusual deps for this plugin and the wacky test runner, it is probably really not worth it trying to fix in from the inside - what do you think?)
Redesigning the interface would be fine. I don't think we need to worry too much about backwards compatibility and I don't think anyone's too invested in the current design. You can just propose whatever structure makes sense to you and we'll go from there.
It does not seem to be possible currently to update already loaded coverage information currently, is it?
Maybe related to #19 ?!
I've thought about adding bang support to
CoverageShow
, so thatCoverageShow!
would refresh the cache.What do you think?