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

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

[Tino Calancha]

./emacs -r -Q -eval '(progn (with-temp-file "/tmp/foo" (insert "foo")) 
(switch-to-buffer "bar") (insert "boo"))'
M-: (highlight-compare-with-file "/tmp/foo") RET
C-b C-b DEL f
M-: M-p RET
;; Now current buffer content equals /tmp/foo content
;; but foo is still displayed with face highlight-changes.



In GNU Emacs 25.0.95.2 (x86_64-pc-linux-gnu, GTK+ Version 3.20.6)
Repository revision: 829733104db073f8abd67765eae162e7360281fa

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Following patch fixed it calling
(and highlight-changes-mode (hilit-chg-clear))
each time
(highlight-changes-mode 1)
is called.
It would be better if such reset were performed inside one hook.
Any idea to do this better?


From 18251da925f8f8c6cca50b2a4f56235534c0a479 Mon Sep 17 00:00:00 2001
From: Tino Calancha <f92capac@gmail.com>
Date: Wed, 22 Jun 2016 18:29:13 +0900
Subject: [PATCH] Reset between highlight comparisons

* lisp/hilit-chg.el (highlight-markup-buffers)
(highlight-changes-mode-turn-on): Call hilit-chg-clear before
performing a new comparison (Bug#23823).
---
  lisp/hilit-chg.el | 6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/lisp/hilit-chg.el b/lisp/hilit-chg.el
index 8f042b6..f6eae52 100644
--- a/lisp/hilit-chg.el
+++ b/lisp/hilit-chg.el
@@ -804,8 +804,12 @@ highlight-markup-buffers
        (or file-b
  	  (setq temp-b (setq file-b (ediff-make-temp-file buf-b nil))))
        (set-buffer buf-a)
+      (when highlight-changes-mode
+        (hilit-chg-clear))
        (highlight-changes-mode 1)
        (or markup-a-only (with-current-buffer buf-b
+                          (when highlight-changes-mode
+                            (hilit-chg-clear))
  			  (highlight-changes-mode 1)))
        (setq change-info (hilit-chg-get-diff-info buf-a file-a buf-b 
file-b))

@@ -993,6 +997,8 @@ highlight-changes-mode-turn-on
  	     (and
  	      (not (string-match "^[ *]" (buffer-name)))
  	      (buffer-file-name))))
+          (when highlight-changes-mode
+            (hilit-chg-clear))
  	  (highlight-changes-mode 1))
  	))

-- 
2.8.1

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

[Tino Calancha]

>Following patch fixed it calling
>(and highlight-changes-mode (hilit-chg-clear))
>each time
>(highlight-changes-mode 1)
>is called.

Sorry, the patch use:
(when highlight-changes-mode
   (hilit-chg-clear))

instead of:
(and highlight-changes-mode (hilit-chg-clear))

It doesn't affect my comment: it would be better if such calls
to 'hilit-chg-clear were handle automatically, instead of repeated
'by hand' each time.

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

[Eli Zaretskii]

> From: Tino Calancha <f92capac@gmail.com>
> Date: Wed, 22 Jun 2016 19:11:27 +0900 (JST)
> 
> ./emacs -r -Q -eval '(progn (with-temp-file "/tmp/foo" (insert "foo")) 
> (switch-to-buffer "bar") (insert "boo"))'
> M-: (highlight-compare-with-file "/tmp/foo") RET
> C-b C-b DEL f
> M-: M-p RET
> ;; Now current buffer content equals /tmp/foo content
> ;; but foo is still displayed with face highlight-changes.

What I see is 'f' in a "deleted" face.  Which seems reasonable to me.

Whether a change that countermands another change should count as a
change is a philosophical question that AFAIK doesn't have a
one-fits-all answer.

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

[Tino Calancha]

On 06/23/2016 12:16 AM, Eli Zaretskii wrote:
> What I see is 'f' in a "deleted" face.  Which seems reasonable to me.
>
> Whether a change that countermands another change should count as a
> change is a philosophical question that AFAIK doesn't have a
> one-fits-all answer.
The way i understand my example is as follows:

1) An user compare current buffer (buf-a) with file-b.
;; buf-a content: boo
;; file-b content: foo
;; they are different: new faces shown their differences.

2) The user update buf-a and perform a new comparison with file-b.
;; buf-a content: foo
;; file-b content: foo
;; same content, but is not obvious because the result of the
;; previous comparison is not removed.

My point is: why don't we perform a fresh comparison in 2?

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

[Eli Zaretskii]

> Cc: 23823@debbugs.gnu.org
> From: Tino Calancha <f92capac@gmail.com>
> Date: Thu, 23 Jun 2016 09:46:27 +0900
> 
> 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'.  Why does it make sense to forget all
that information?

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

[Tino Calancha]

On Thu, 23 Jun 2016, Eli Zaretskii wrote:

>> Cc: 23823@debbugs.gnu.org
>> From: Tino Calancha <f92capac@gmail.com>
>> Date: Thu, 23 Jun 2016 09:46:27 +0900
>>
>> 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.

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.

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

[Eli Zaretskii]

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

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

[Tino Calancha]

On Fri, 24 Jun 2016, Eli Zaretskii wrote:

> 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.

You convinced me: there is no need to reset those highlighted differences.
If the user want to do that he/she could toggle eaasily the mode before 
calling the func.  Adding a prefix argument to reset may cause accidentaly
lost all the tracked differences.


The comentary of this lib helps to understand the design intentions.
For example when it says:
;; You can "age" different sets of changes by using
;; `highlight-changes-rotate-faces'.

Each time the buffer is saved, the new differences get a different face.

Following example shows the point:

emacs -Q -eval "(progn (with-temp-file \"/tmp/foo\" (insert \"Hi i am foo\n\")) (find-file \"/tmp/foo\") (highlight-changes-mode 1) (add-hook 'write-file-functions 'highlight-changes-rotate-faces nil t))"
M-: (progn (goto-char (point-max)) (insert "Hi foo, i am bar.\n") (highlight-compare-with-file "/tmp/foo")) RET y y
M-: (progn (goto-char (point-max)) (insert "Nice to meet you foo.\n") (highlight-compare-with-file "/tmp/foo")) RET y y
M-: (progn (goto-char (point-max)) (insert "Nice to meet you too, bar.\n") (highlight-compare-with-file "/tmp/foo")) RET y y

;; If we reset the buffer on each func call we will loose all this
;; psicodelic color structure :-S

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

[Lars Ingebrigtsen]

Tino Calancha <f92capac@gmail.com> writes:

> You convinced me: there is no need to reset those highlighted
> differences.  If the user want to do that he/she could toggle eaasily
> the mode before calling the func.  Adding a prefix argument to reset
> may cause accidentaly lost all the tracked differences.

If I understood this correctly, it was decided that the proposed change
wasn't desirable, so I'm closing this bug report.  Please reopen if I
misunderstood.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no