GNU bug report logs - #23823
25.0.95; Reset between highlight buffer/file comparisons

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23823 in the body.
You can then email your comments to 23823 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.95; Reset between highlight buffer/file comparisons
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.



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

Message #8 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: 23823 <at> debbugs.gnu.org
Cc: Tino Calancha <f92capac <at> gmail.com>
Subject: Re: bug#23823: Acknowledgement (25.0.95; Reset between highlight
 buffer/file comparisons)
Date: Wed, 22 Jun 2016 19:22:07 +0900 (JST)

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

Message #11 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95;
 Reset between highlight buffer/file comparisons
Date: Wed, 22 Jun 2016 18:16:10 +0300

> From: Tino Calancha <f92capac <at> 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.

Message #14 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95; Reset between highlight buffer/file
 comparisons
Date: Thu, 23 Jun 2016 09:46:27 +0900

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?

Message #17 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95; Reset between highlight buffer/file
 comparisons
Date: Thu, 23 Jun 2016 18:24:17 +0300

> Cc: 23823 <at> debbugs.gnu.org
> From: Tino Calancha <f92capac <at> 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?

Message #20 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95; Reset between highlight buffer/file
 comparisons
Date: Fri, 24 Jun 2016 13:36:17 +0900 (JST)

On Thu, 23 Jun 2016, Eli Zaretskii wrote:

>> Cc: 23823 <at> debbugs.gnu.org
>> From: Tino Calancha <f92capac <at> 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.

Message #23 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: f92capac <at> gmail.com, 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95; Reset between highlight buffer/file
 comparisons
Date: Fri, 24 Jun 2016 10:07:11 +0300

> From: Tino Calancha <f92capac <at> gmail.com>
> Date: Fri, 24 Jun 2016 13:36:17 +0900 (JST)
> cc: Tino Calancha <f92capac <at> gmail.com>, 23823 <at> 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?

Message #26 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, 23823 <at> debbugs.gnu.org
Subject: Re: bug#23823: 25.0.95; Reset between highlight buffer/file
 comparisons
Date: Fri, 24 Jun 2016 22:13:25 +0900 (JST)

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

Message #29 received at 23823 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 23823 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#23823: 25.0.95;
 Reset between highlight buffer/file comparisons
Date: Tue, 25 Jun 2019 14:25:47 +0200

Tino Calancha <f92capac <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.