[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#23823: 25.0.95; Reset between highlight buffer/file comparisons
Date: Fri, 24 Jun 2016 10:07:11 +0300

> From: Tino Calancha <address@hidden>
> Date: Fri, 24 Jun 2016 13:36:17 +0900 (JST)
> cc: Tino Calancha <address@hidden>, address@hidden
> >> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]