Add support for coveralls format (as produced by undercover.el)

[xendk]

This isn't as much a PR as a request for comments as this isn't really done.

I've hacked in support for the format that undercover.el generates. It wasn't too hard as multiple parsers was mostly thought in from the start. But a more defined interface wouldn't hurt.

I want to do parsing of clover too, as that seems to be widely used, but as it's a XML format, it might be better off in a separate package.

Both the coveralls format and the clover format contains coverage data for multiple files, so a way of loading the coverage once and reuse the data across files would be nice, but that requires a bit of re-architecting .

@snogge has some nice fixes in https://github.com/snogge/cov/tree/overlays that would be nice too.

[AdamNiederer]

Hey, thanks for the PR!

The interface between different parsers is pretty ad-hoc right now, but it should be workable for the near-term future. Caching the data sounds like a nice idea, though.

We might be able to use https://github.com/AdamNiederer/elquery to massage clover's output into something usable. I designed that library with HTML in mind, but its parser is just a wrapper around libxml. It probably either works out of the box or with very minor tweaking (which I can do).

I'll test snogge's commits and merge 'em in if they pass tests locally. It looks like the Travis failures are the fault of time since the last build, rather than your/his diffs.

[xendk]

The interface between different parsers is pretty ad-hoc right now, but it should be workable for the near-term future.

Yeah. I'll change the interface to having the parser return a filename -> coverage list, but keep it simple.

Caching the data sounds like a nice idea, though.

Indeed. But I think watching the coverage file for changes and automatically reloading would be more interesting at first.

We might be able to use https://github.com/AdamNiederer/elquery to massage clover's output

I'll take a look at it. I mostly need to loop over some elements, but whatever gets me there the quickest.

It looks like the Travis failures are the fault of time since the last build

My personal experience is that I need to refresh https://github.com/flycheck/emacs-travis/blob/master/.travis.yml once in a while. Think I'll set up a weekly build on my projects to catch these failures before the next time I add a feature to a project.

[snogge]

The travis failures were due to changes in the travis service and compatibility with emacs-travis.mk. I did a fix for that but it is outdated by now. Basically I think you need to update .travis.yml according to the instructions in flycheck/emacs-travis

[xendk]

Oh yeah, I broke the tests, as I renamed cov--parse. I'll fix them, and I might as well implement the parser-returns-file->coverage-lists thing while I'm at it.

[xendk]

There.

I've also added undercover, so if you run env UNDERCOVER_FORCE=true cask exec ert-runner, you can enable cov-mode for cov.el.

I've also added a test case for 'cov--coveralls-parse`.

[xendk]

So, it's in a somewhat merge-able state right now @AdamNiederer. There's more I would like to do, but maybe you'd rather have them as separate pull requests?

Implement a coverage storage to cache coverage so multiple buffers that use the same coverage file can share it rather than re-parsing the same file.

Watching the file used coverage files and re-parsing them when changed and update the relevant buffers.

flycheck is somewhat unhappy about cov.el. Mostly documentation strings that doesn't quite follow the conventions. I'd like to clean that up.

The coveralls parser only looks in the same directory for the coverage file, so if one has .el files in subdirs, cov-mode won't see coverage for those files. Probably also means having to deal with coverage files in a sub-directory that still references files relative to the project root.

The clover parser.

[AdamNiederer]

This looks good! I'll pull it in now and work on bumping Travis and integrating snogge's cleanups.