Closed thoni56 closed 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?
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.
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?
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.
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?
Nope. inotify
has the same behaviour (sending "stopped" event when file is removed)...
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.
Do I understand correctly that this (the delayed update of the fringe) is only a problem on MacOS?
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.
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.
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...