bug#23823: 25.0.95; Reset between highlight buffer/file comparisons

[Eli Zaretskii <eliz@gnu.org>]

> From: Tino Calancha <f92capac@gmail.com>
> Date: Fri, 24 Jun 2016 13:36:17 +0900 (JST)
> cc: Tino Calancha <f92capac@gmail.com>, 23823@debbugs.gnu.org
> 
> >> My point is: why don't we perform a fresh comparison in 2?
> >
> > Because the first time you call highlight-compare-with-file, it turns
> > on the highlight-changes-mode, which begins to mark changes, including
> > the replacement of 'b' with 'f'.
> Yeah, that sounds nice to me: the user is still somehow in the context 
> of the first func. call.
> 
> 
> > Why does it make sense to forget all  that information?
> Because the user called the function again: this may start a new context, 
> i.e., reset the minor mode in that buffer.

But the function's doc string clearly makes that expected behavior:

  If the current buffer is visiting the file being compared against, it
  also will have its differences highlighted.

The only way I can interpret that "also" part is that the changes
against the file are highlighted _in_addition_ to the changes tracked
by the mode.  Your scenario just happens to produce a clash between
these two sets of differences, and the result could be ambiguous.  But
what we get in fact doesn't seem unreasonable to me.

> I imagine buf-a becaming a mess of colors with all those changes around. 
> At some point the user may want to compare again the current status of 
> buf-a with file-b.

Well, then maybe a prefix argument to that effect could provide this
as an optional behavior?