Will flydiff work after committing changes from terminal?

[wanghaiqiangk]

Any changes are correctly updated in the buffer immediately if flydiff is enabled. So I think it works at this point.

But I notice that if I commit those changes, instead of using built-in vc or magit, but via git cli from terminal, which is how I get used to doing all reversion stuffs, the buffer won't be updated and those indicators in fringe are still there.

I inspected using vc and the buffer then is updated on the fly. So is this behavior a desired result that only revision operations performed inside Emacs will trigger diff-hl-update to update buffer on time?

[dgutov]

Hi! This actually seems to work fine for me.

Do you have some non-default settings maybe? Try writing a step-by-step reproduction scenario.

[wanghaiqiangk]

My settings

(use-package diff-hl
  :config
  (global-diff-hl-mode)
  (diff-hl-flydiff-mode)
  (if (not (display-graphic-p))
      (diff-hl-margin-mode t)))

Instead of writing a textual description, a gif may give a better demonstration.

So, after saving and committing, the indicators are still there until I run vc-diff, or revert-buffer thingy

[dgutov]

I can see it now. Is that a real nuisance? Do you know if similar editors have this behavior?

Something like VS Code aside, which likely plugs into inotify, which I'm not sure we can do. Not easily, at least.

The alternative would be running the equivalent of git status on a timer, to see if it changed, and update whenever that happens. Which feels a little wasteful (I don't know) when you can just make an edit and revert to see the updated fringe. But I get the comfort of always seeing up-to-date indicators. Another common problem (which git status wouldn't solve), is having the file updated after git checkout. But having global-auto-revert-mode enabled should take care of that.

[dgutov]

Hi again!

I've though about this some more, and there are several ways you can have some improved behavior. The first one is simply having that git diff basically run in full whenever Emacs is idle, to update the selected buffer. The patch will look like this:

diff --git a/diff-hl-flydiff.el b/diff-hl-flydiff.el
index e366eec..56be107 100644
--- a/diff-hl-flydiff.el
+++ b/diff-hl-flydiff.el
@@ -36,6 +36,13 @@
   "The idle delay in seconds before highlighting is updated."
   :type 'number)
 
+(defcustom diff-hl-flydiff-always-check t
+  "Non-nil to always run the full status check of the current file.
+
+This will make it always pick up changes in HEAD even when commit is made
+outside of Emacs (e.g. in terminal) before any changes to buffers are made."
+  :type 'boolean)
+
 (defvar diff-hl-flydiff-modified-tick nil)
 (defvar diff-hl-flydiff-timer nil)
 (make-variable-buffer-local 'diff-hl-flydiff-modified-tick)
@@ -47,14 +54,16 @@
 (defun diff-hl-flydiff-update ()
   (unless (or
            (not diff-hl-mode)
-           (eq diff-hl-flydiff-modified-tick (buffer-chars-modified-tick))
+           (unless diff-hl-flydiff-always-check
+             (eq diff-hl-flydiff-modified-tick (buffer-chars-modified-tick)))
            (not buffer-file-name)
            (file-remote-p default-directory)
            (not (file-exists-p buffer-file-name)))
     (diff-hl-update)))
 
 (defun diff-hl-flydiff/modified-p (_state)
-  (buffer-modified-p))
+  (or diff-hl-flydiff-always-check
+      (buffer-modified-p)))
 
 ;;;###autoload
 (define-minor-mode diff-hl-flydiff-mode

Please go ahead and test it when you have the time. The downside is it will produce somewhat wasteful work, and in larger repositories git diff can take a fair amount of time (up to 200ms in my testing). Whether it will translate in visible stutters sometimes or not, depends on the size of the projects and the speed of the machine.

Another approach would be to use after-focus-change-function. Then, if you switch to a different window (terminal) and then back, diff-hl-flydiff could notice that and update all the buffers in visible windows. The main downside is that not all scenarios will be covered: e.g. if you have a tiling WM and want to have Emacs and the terminal side-by-side, make a commit in the terminal and see the contents updated in Emacs more-or-less synchronously, this won't happen. But it will happen when you bring the focus to Emacs again, so maybe it can be a good compromise.

Let me know if you're still around and interesting in trying out the patches -- I will do one for the second option as well.