bug#64063: smerge-mode highlight gets stuck if buffer autoreverted "delicately"

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 03:16 +0300, Konstantin Kharlamov wrote:
> On Thu, 2023-06-01 at 13:35 +0200, Daniel Martín wrote:
> > > So, my question is, what "on change" hooks smerge-mode uses to detect that
> > > a
> > > change to the buffer has been made to check whether conflict markers are
> > > still
> > > in place? I tried searching for the word "hook" over the smerge-mode.el
> > > but
> > > didn't find anything relevant.
> > 
> > If font-lock is enabled, smerge-mode uses it to fontify the conflicting
> > regions.  See smerge-font-lock-keywords.  So perhaps the regular
> > font-lock debugging techniques might help you investigate this issue in
> > more detail.
> 
> So, I think the problem is that the highlight that gets stuck does not use
> font-lock,
> or at least not through means of `smerge-font-lock-keywords`. Whatever is
> defined in
> `smerge-font-lock-keywords` gets unhighlighted correctly. But the part that
> gets
> stuck instead is an overlay.
> 
> So I presume besides font-lock-mode there's some other highlight management
> ongoing,
> the one that decides whether to put/remove overlays over some text.

Okay, I think I figured it out. The hook upon which stuff gets highlighted is
`find-file-hook`. It calls vc, vc calls smerge, which checks if there's any
conflict markers; then finally `(smerge-refine)` gets called which adds the
problematic overlay.

I'm not quite sure though what is the correct fix in this case. The problem
appears when autorevert-mode is enabled, so one way may be always adding a hook
to `after-revert-hook` that clears up the overlays.

But there *may* be some other way. I notice that if I remove a conflict marker
manually, this makes the overlay disappear. I don't know what exactly causes
that to happen, but the answer to this may hide another possibility to fix the
bug. If anybody has the knowledge I will be glad to hear C: