search

AdamNiederer / cov

An emacs extension for displaying coverage data on your code
GNU General Public License v3.0
76 stars 16 forks source link

Cov not updating coverage on MacOS #43

Closed thoni56 closed 2 years ago

thoni56 commented 2 years ago

I'm running Emacs for MacOS 27.2 and it seems that Emacs does not notice the updated .gcov files.

If I touch a source file Emacs says "Reverting ..." as it should. But if I modify the .gcov file, this does not trigger an update of the coverage in the fringe. I need to re-visit the file, then it is updated. I don't know if they even use the same mechanism for watching for file changes, so maybe that is a red herring. Or a clue...

thoni56 commented 2 years ago

Ok, maybe this is the reason.

snogge commented 2 years ago

Could be. As far as I can tell from both the stack overflow question and the elisp manual, kqueue should be supported by filenotify.el. But I do not have access to any MacOS machines to test on. Maybe you can check whether your emacs has the kqueue support enabled? I think autorevert uses file polling if no notification support is available, so it might not be an indication of kqueue support. Maybe we should add a way to trigger update manually?

thoni56 commented 2 years ago

Isn't cov-update a way to trigger updates manually?

I think there might be something else going on... I have the following main.c.gcov (left) and the main.c (right) source. Even if I explicitly do cov-update the gcov data is not reflected in the fringe.

image

Touching the gcov-file and then cov-update did not make a difference. I've tried to add a few lines to the end of the .gcov which sometimes seems to make a difference, but I can't see the connection clearly enough to describe a repeatable pattern except that the fringe is update perfectly if I re-visit the file. Otherwise it doesn't update.

What's the mechanism for discovering a change of a gcov file? A pointer in to the elisp code, perhaps?

snogge commented 2 years ago

The only way for cov.el to discover changes in the gcov file is file-notify. cov checks whether file-notify is supported by checking the value of file-notify--library, you can check that variable in your emacs to see whether file-notify was enabled in your build. cov-update will only update the overlays from coverage data already stored in cov-coverages, loading coverage data only if it is not already present. If you first do 

(setq cov-coverages (make-hash-table :test 'equal))

and then cov-udpate, the coverage data should be updated. Of course this will delete loaded coveage data for all files, but any existing overlays will remain in place. This is probably an unintended consequence (bug) from when the file-notify support was added to cov.el.

thoni56 commented 2 years ago

file-notify--library is kqueue both for GUI Emacs and Homebrew Emacs on MacOS.

I've updated everything to the latest version, cov-mode (mine was one release old), Emacs and Monterey. Still no automatic cov-updating, but at least a manual cov-update consistently refreshes the fringe as it is supposed to. So that is some small progress.

I tried to see if file-notify works as advertised on MacOS using

(file-notify-add-watch "/tmp/x" '(change change) 'my-notify-callback)

and then update the content of /tmp/x. That seemed to result in the correct events.

But what I discovered was that if the file is removed a "stopped" event is generated. And of course then no more events were sent. I don't know if this is different from other environments, but if it is, might that be a problem?

thoni56 commented 2 years ago

Nope. inotify has the same behaviour (sending "stopped" event when file is removed)...

thoni56 commented 2 years ago

Aaahh! There is no problem with updating the actual coverage. It is the fringe that is not updated on change in coverage!

Not until I make an edit... If I have a "new" coverage, which has not been shown in the fringe yet, all I have to do is to make a single character press, and the fringe is updated to show the new coverage.

(Of course, your trick from above also makes the fringe update to the new coverage.)

That makes it a bit easier to live with, but still a nuisance.

Perhaps this also makes it easier to figure out what's different with MacOS Emacsen.

snogge commented 2 years ago

Do I understand correctly that this (the delayed update of the fringe) is only a problem on MacOS?

thoni56 commented 2 years ago

Yes, as far as I can see. I'll try to get in touch with maintainers of Emacs for MacOS to see if they have any clues about the fringe problem.

thoni56 commented 2 years ago

Looks like this is not related to cov-mode. It is probably caused by some spurious error that seems to originate from org-mode : Selecting deleted buffer. I think org-mode is probably also hooked into file-notify and the error message prevents cov-mode to do its thing.

This is mostly guesswork from my part based on some googling the error message (indicating that one possible source could be org-mode) and then noticing that if I did not open any org-mode file I couldn't see this happening. Also an experiment on WSL confirmed that I could trigger this error if I first opened my TODO-org-mode file.

So closing. Sorry for the noise.