[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 <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?