Diff could also show the changes within lines

Diff could also show the changes within lines

[Tom]

When doing diffs it often occurs to me the diff output could be
more readable if it showed the actual changes within lines.

Something like this (I mean the concept, the actual implemenation shown
may not be the best output which can be achieved), so you don't have to
search for the changes within the line:

http://stackoverflow.com/questions/1265949/multiple-changes-in-one-line-with-diff-
tool/1266114#1266114

It doesn't even necessarily need support from the external diff tool,
because diffs are usually not huge, so the highlighting of the changes
could be done in lisp by parsing the diff output.

Has anyone tried improving diff like this? Is there a package which does 
this?

RE: Diff could also show the changes within lines

[Drew Adams]

> Has anyone tried improving diff like this? Is there a package 
> which does this?

ediff

E.g. `M-x ediff-buffers'

Re: Diff could also show the changes within lines

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:

> 
> > Has anyone tried improving diff like this? Is there a package 
> > which does this?
> 
> ediff
> 
> E.g. `M-x ediff-buffers'
> 

Okay, but I mean output from git/mercurial/etc. when I get
a file history from emacs, or diff between versions, etc.

These commands invoke diff, and I like the single buffer diff
output, I don't need ediff showing diffs in two windows, etc.
that's why I think improving the regular diff output could 
be useful.

RE: Diff could also show the changes within lines

[Doug Lewan]

Tom,

If you're working with software that VC supports (RCS, CVS, there are external packages for others too), then you can also do M-x ediff-revision.

,Doug

> -----Original Message-----
> From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org
> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org] On
> Behalf Of Drew Adams
> Sent: Friday, 2012 October 05 10:40
> To: 'Tom'; help-gnu-emacs@gnu.org
> Subject: RE: Diff could also show the changes within lines
> 
> > Has anyone tried improving diff like this? Is there a package
> > which does this?
> 
> ediff
> 
> E.g. `M-x ediff-buffers'
> 

Re: Diff could also show the changes within lines

[chandan r]

Tom <adatgyujto@gmail.com> writes:

> When doing diffs it often occurs to me the diff output could be
> more readable if it showed the actual changes within lines.
>
> Something like this (I mean the concept, the actual implemenation shown
> may not be the best output which can be achieved), so you don't have to
> search for the changes within the line:
>
> http://stackoverflow.com/questions/1265949/multiple-changes-in-one-line-with-diff-
> tool/1266114#1266114
>
> It doesn't even necessarily need support from the external diff tool,
> because diffs are usually not huge, so the highlighting of the changes
> could be done in lisp by parsing the diff output.
>
> Has anyone tried improving diff like this? Is there a package which does 
> this?

Add the following to your Emacs init file:

(add-hook 'diff-mode-hook
	  (lambda () (diff-auto-refine-mode 1)))

Re: Diff could also show the changes within lines

[Tom]

chandan r <chandanrmail <at> gmail.com> writes:
> 
> Add the following to your Emacs init file:
> 
> (add-hook 'diff-mode-hook
> 	  (lambda () (diff-auto-refine-mode 1)))
> 

Wow, I'm impressed. Builtin Emacs features can still surprise me after
all these years. Thanks.

Re: Diff could also show the changes within lines

[Tom]

Tom <adatgyujto <at> gmail.com> writes:

> 
> chandan r <chandanrmail <at> gmail.com> writes:
> > 
> > Add the following to your Emacs init file:
> > 
> > (add-hook 'diff-mode-hook
> > 	  (lambda () (diff-auto-refine-mode 1)))
> > 
> 
> Wow, I'm impressed. Builtin Emacs features can still surprise me after
> all these years. Thanks.
> 
> 

Looks like it does not work with DVC diff, so it needs to be disabled for
that:

  (unless (or (eq this-command 'dvc-diff)
              (eq this-command 'dvc-generic-refresh))
    (diff-auto-refine-mode 1))

Re: Diff could also show the changes within lines

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
>     (diff-auto-refine-mode 1)
> 

Turns out it only refines one hunk (the current) and the others only
if you use hunk navigation commands (diff-auto-refine-mode does this which 
is on by default in Emacs 24). So to refine all hunks automatically,
do this in the diff hook:

  (save-excursion
    (goto-char (point-min))
    (while (not (eobp))
      (diff-hunk-next))))

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hello Tom, Stefan and all,

Tom wrote:
> Tom <adatgyujto <at> gmail.com> writes:
>>
>>     (diff-auto-refine-mode 1)
>
> Turns out it only refines one hunk (the current) and the others only if you
> use hunk navigation commands (diff-auto-refine-mode does this which is on by
> default in Emacs 24). So to refine all hunks automatically, do this in the
> diff hook:
>
>   (save-excursion
>     (goto-char (point-min))
>     (while (not (eobp))
>       (diff-hunk-next))))

I'd like to get that feature as well. However, the above code causes me
2 problems:

- only the last hunk is getting refined, both in VC dir's buffer, or when
  reading (with Gnus) an email with a patch file in it;

- occasionally, an error message "no hunk found" when reading an email with a
  patch file in it.

I patched your code to try and avoid those problems, by:

- adding a condition-case nil... error construct
- using save-excursion
- using an explicit goto-char min
- ...

Here is my current code:

--8<---------------cut here---------------start------------->8---
  ;; enable Diff Auto Refine mode (highlight the changes with better
  ;; granularity)
  (add-hook 'diff-mode-hook
            (lambda ()
              ;; refine all hunks automatically
              (when (>= (diff-end-of-hunk) 1)
                ;; avoid "No hunk found" error
                (goto-char (point-min))
                (while (not (eobp))
                  (diff-hunk-next)))
              (goto-char (point-min))))
--8<---------------cut here---------------end--------------->8---

... but that does not help...

I still have the two above mentioned problems...

Any idea?

Best regards,
  Seb

--
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:

> 
> I'd like to get that feature as well. However, the above code causes me
> 2 problems:
> 
> - only the last hunk is getting refined, both in VC dir's buffer, or when
>   reading (with Gnus) an email with a patch file in it;
>

Currently I use this code added to the diff mode hook:

(defun my-refine-all-diff-hunks ()
  (interactive)
  (condition-case nil      
      (save-excursion
        (goto-char (point-min))
        (while (not (eobp))
          (diff-hunk-next)))
    (error nil)))


It works well for me, it highlights the changes in all hunks
automatically. I use it only for diffing before checkin.

But. It works only because the VC mercurial implementation calls
the backend synchronously. In case of DVC it doesn't work for
me, because DVC calls the backend asynchronously, so when the diff
hook is run the output is not there yet and I did not find a hook
which is called when the async diff command is finished

You may want to check how the diff output is produced in your use
cases. If it is done asynchronously then the diff hook is not a 
suitable place to call the highlighting code from.

Re: Diff could also show the changes within lines

[Oleksandr Gavenko]

On 2012-11-10, Tom wrote:

> Currently I use this code added to the diff mode hook:
>
> (defun my-refine-all-diff-hunks ()
>   (interactive)
>   (condition-case nil
>       (save-excursion
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)))
>     (error nil)))
>
> It works well for me, it highlights the changes in all hunks
> automatically. I use it only for diffing before checkin.

I found that with code (more precisely 'diff-refine-hunk') hung up Emacs on
large chunks (10-20 KiB).

So I just use "C-c C-b" instead when I need refine-hunk.

-- 
Best regards!

Re: Diff could also show the changes within lines

[Tom]

Oleksandr Gavenko <gavenkoa <at> gmail.com> writes:

> 
> I found that with code (more precisely 'diff-refine-hunk') hung up Emacs on
> large chunks (10-20 KiB).
> 
> So I just use "C-c C-b" instead when I need refine-hunk.
> 

I should have added that I have an additional check in my
diff hook, which calls the automatic highlighting of hunks
only if the diff is below a certain size, so I have
automatic highlighting for the majority of my diffs which
are small and for the big ones I toggle the highlight manually
if needed.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hi Tom,

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>> I'd like to get that feature as well. However, the above code causes me
>> 2 problems:
>> 
>> - only the last hunk is getting refined, both in VC dir's buffer, or when
>>   reading (with Gnus) an email with a patch file in it;
>
> Currently I use this code added to the diff mode hook:
>
> (defun my-refine-all-diff-hunks ()
>   (interactive)
>   (condition-case nil      
>       (save-excursion
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)))
>     (error nil)))
>
> It works well for me, it highlights the changes in all hunks automatically.
> I use it only for diffing before checkin.
>
> But. It works only because the VC mercurial implementation calls the backend
> synchronously. In case of DVC it doesn't work for me, because DVC calls the
> backend asynchronously, so when the diff hook is run the output is not there
> yet and I did not find a hook which is called when the async diff command is
> finished
>
> You may want to check how the diff output is produced in your use cases. If
> it is done asynchronously then the diff hook is not a suitable place to call
> the highlighting code from.

I'm not sure how to check for that, but I could reduce all my `.emacs' file to
an example file which shows the problem on the current development snapshot of
the future Emacs 24.3 (from 2012-10-22):

--8<---------------cut here---------------start------------->8---
;;; emacs-minimal.el

(setenv "LC_ALL" "C")

;; enable Diff Auto Refine mode (highlight the changes with better
;; granularity)
(defun my/diff-refine-all-hunks ()
  (interactive)
  (condition-case nil
      (save-excursion
        (goto-char (point-min))
        (while (not (eobp))
          (diff-hunk-next)))
    (error nil)))

(add-hook 'diff-mode-hook
          'my/diff-refine-all-hunks)

(message "%s" (emacs-version))
(sit-for 1)
--8<---------------cut here---------------end--------------->8---

You can see, in the screencast on http://screencast.com/t/JOlsyWHh, that:

- the cursor goes to the end of the diff

- only the last diff is refined (see the string " for Diff" which should be
  highlighted in the first hunk)

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:

> 
> You can see, in the screencast on http://screencast.com/t/JOlsyWHh, that:
> 
> - the cursor goes to the end of the diff
> 
> - only the last diff is refined (see the string " for Diff" which should be
>   highlighted in the first hunk)
> 

Try it manually. Go to the diff buffer and call M-x my/diff-refine-all-hunks
there.

Does it highlight all the hunks then? 

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hi Tom,

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>
>> 
>> You can see, in the screencast on http://screencast.com/t/JOlsyWHh, that:
>> 
>> - the cursor goes to the end of the diff
>> 
>> - only the last diff is refined (see the string " for Diff" which should be
>>   highlighted in the first hunk)
>
> Try it manually. Go to the diff buffer and call M-x my/diff-refine-all-hunks
> there.
>
> Does it highlight all the hunks then? 

No, it doesn't, as you can see on http://screencast.com/t/5NHwKwF7c9h.

What does that mean, then -- excepting that it looks coherent with what is put
in the hook?

Best regards,
Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:
> >
> > Does it highlight all the hunks then? 
> 
> No, it doesn't, as you can see on http://screencast.com/t/5NHwKwF7c9h.
> 
> What does that mean, then -- excepting that it looks coherent with what is put
> in the hook?
> 

The diff highlighting function simply calls a builtin feature repeatedly:

        (goto-char (point-min))
        (while (not (eobp))
          (diff-hunk-next)))


diff-hunk-next is bound to TAB, so you can try going to the diff
buffer, go to the beginning of the buffer and start pressing TAB.

Every TAB press should jump to the next hunk and highlight the 
diffs within lines in that hunk. It is done by default.

Here's the relevant code from diff-mode.el:

;; Define diff-{hunk,file}-{prev,next}
(easy-mmode-define-navigation
 diff-hunk diff-hunk-header-re "hunk" diff-end-of-hunk diff-restrict-view
 (if diff-auto-refine-mode
     (condition-case-unless-debug nil (diff-refine-hunk) (error nil))))


The last two lines show that if diff-auto-refine-mode is t
(which is by default) then it should do the highlighting.
If it doesn't the you may want to ask the emacs developers about it.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hi Tom,

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>>> Does it highlight all the hunks then?
>>
>> No, it doesn't, as you can see on http://screencast.com/t/5NHwKwF7c9h.
>>
>> What does that mean, then -- excepting that it looks coherent with what is put
>> in the hook?
>
> The diff highlighting function simply calls a builtin feature repeatedly:
>
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)))
>
> diff-hunk-next is bound to TAB, so you can try going to the diff buffer, go
> to the beginning of the buffer and start pressing TAB.
>
> Every TAB press should jump to the next hunk and highlight the diffs within
> lines in that hunk. It is done by default.

Going to the beginning of the diff buffer and hitting TAB, does indeed moves
over every hunk, in turn, and refines the differences at the same time.

> Here's the relevant code from diff-mode.el:
>
> ;; Define diff-{hunk,file}-{prev,next}
> (easy-mmode-define-navigation
>  diff-hunk diff-hunk-header-re "hunk" diff-end-of-hunk diff-restrict-view
>  (if diff-auto-refine-mode
>      (condition-case-unless-debug nil (diff-refine-hunk) (error nil))))
>
> The last two lines show that if diff-auto-refine-mode is t (which is by
> default) then it should do the highlighting. If it doesn't the you may want
> to ask the emacs developers about it.

The variable diff-auto-refine-mode is as well t on my side. But... that does
not help.

BTW, how do you explain that your cursor is not at the end of the buffer, in
your case, after the refine process?

Best regards,
Seb

--
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:
> 
> Going to the beginning of the diff buffer and hitting TAB, does indeed moves
> over every hunk, in turn, and refines the differences at the same time.
> 

My function does the same, so I can't explain why it
does not work for you when you call it from M-x. 

I guess you also use Emacs 24, so it's not about an old emacs version
behaving differently.

> 
> BTW, how do you explain that your cursor is not at the end of the buffer, in
> your case, after the refine process?
> 

I use save-excursion in the function which puts the cursor back to 
where it was before the function was called.

I don't know why it is at the end of the buffer for you. There are
some emacs gurus on this list. Hopefully some of them will chime in 
and helps you to solve this mistery, because I'm out of ideas.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>>
>> Going to the beginning of the diff buffer and hitting TAB, does indeed
>> moves over every hunk, in turn, and refines the differences at the same
>> time.
>
> My function does the same, so I can't explain why it does not work for you
> when you call it from M-x.

That's very weird, indeed.

> I guess you also use Emacs 24, so it's not about an old emacs version
> behaving differently.

Yep, sort of future Emacs 24.3, that is:

GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC

>> BTW, how do you explain that your cursor is not at the end of the buffer,
>> in your case, after the refine process?
>
> I use save-excursion in the function which puts the cursor back to where it
> was before the function was called.

I had overlooked it. Of course.

> I don't know why it is at the end of the buffer for you. There are some
> emacs gurus on this list. Hopefully some of them will chime in and helps you
> to solve this mistery, because I'm out of ideas.

Thanks for your help so far...

Last thing: can you post your complete chunk of code regarding this? I mean
with your additional check which calls the automatic highlighting of hunks
only if the diff is below a certain size? Thanks a lot...

Best regards,
  Seb

--
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:

> 
> Last thing: can you post your complete chunk of code regarding this? I mean
> with your additional check which calls the automatic highlighting of hunks
> only if the diff is below a certain size? Thanks a lot...

It's quite straightforward:


(add-hook 'diff-mode-hook 'my-diff-stuff)


(defun my-diff-stuff ()
  (unless (or (eq this-command 'dvc-diff) ; does not work with DVC
              (eq this-command 'dvc-generic-refresh)
              (> (buffer-size) 20000))
    (my-refine-all-diff-hunks)))


(defun my-refine-all-diff-hunks ()
  (interactive)
  (condition-case nil      
      (save-excursion
        (goto-char (point-min))
        (while (not (eobp))
          (diff-hunk-next)))
    (error nil)))

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>
>> Last thing: can you post your complete chunk of code regarding this? I mean
>> with your additional check which calls the automatic highlighting of hunks
>> only if the diff is below a certain size? Thanks a lot...
>
> It's quite straightforward:
>
> (add-hook 'diff-mode-hook 'my-diff-stuff)
>
> (defun my-diff-stuff ()
>   (unless (or (eq this-command 'dvc-diff) ; does not work with DVC
>               (eq this-command 'dvc-generic-refresh)
>               (> (buffer-size) 20000))
>     (my-refine-all-diff-hunks)))
>
> (defun my-refine-all-diff-hunks ()
>   (interactive)
>   (condition-case nil      
>       (save-excursion
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)))
>     (error nil)))

FYI, have a look at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12894.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:
> 
> FYI, have a look at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12894.
> 

That explains it. I'm on Emacs 24.1 and it does not have this
scheduling code, so that's why it works for me. I didn't think
they changed this recently.

Anyway, you can try calling diff-refine-hunk explicitly after
diff-hunk-next then:

  (condition-case nil      
      (save-excursion
        (goto-char (point-min))
        (while (not (eobp))
          (diff-hunk-next)
          (diff-refine-hunk)))
    (error nil)))

I can't try it, because I use 24.1, but it may work.

Re: Diff could also show the changes within lines

[Stefan Monnier]

> That explains it. I'm on Emacs 24.1 and it does not have this
> scheduling code, so that's why it works for me. I didn't think
> they changed this recently.

> Anyway, you can try calling diff-refine-hunk explicitly after
> diff-hunk-next then:

>   (condition-case nil      
>       (save-excursion
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)
>           (diff-refine-hunk)))
>     (error nil)))

> I can't try it, because I use 24.1, but it may work.

If you let-bind diff-auto-refine-mode to nil in the above code, not only
you'll be able to test it on Emacs-24.1 (and earlier), but you'll avoid
refining the hunks redundantly when diff-hunk-next does it.


        Stefan

Re: Diff could also show the changes within lines

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> If you let-bind diff-auto-refine-mode to nil in the above code, not only
> you'll be able to test it on Emacs-24.1 (and earlier), but you'll avoid
> refining the hunks redundantly when diff-hunk-next does it.

Good suggestion. Thank you.

What I did not get in the new diff-mode implementation is why it
uses run-at-time instead of run-with-idle-timer?

run-at-time is for specifying a timer which runs at a specific time
while run-with-idle-timer runs it when emacs becomes idle. Isn't
using run-with-idle-timer is more appropriate (makes the code clearer)
in this case?

And why the code uses 0.0 instead of just 0? Is there a difference?

Re: Diff could also show the changes within lines

[Stefan Monnier]

>> If you let-bind diff-auto-refine-mode to nil in the above code, not only
>> you'll be able to test it on Emacs-24.1 (and earlier), but you'll avoid
>> refining the hunks redundantly when diff-hunk-next does it.
> Good suggestion. Thank you.
> What I did not get in the new diff-mode implementation is why it
> uses run-at-time instead of run-with-idle-timer?
> run-at-time is for specifying a timer which runs at a specific time
> while run-with-idle-timer runs it when emacs becomes idle.  Isn't
> using run-with-idle-timer is more appropriate (makes the code clearer)
> in this case?

run-at-time timers don't run while Elisp is running either, they only
run when Elisp is being interrupted (e.g. during redisplay, or while
running process filters).  So the difference is pretty slim (more
specifically, there's only a difference in the case where diff-hunk-next
is run from code which later calls something like sit-for or redisplay).

> And why the code uses 0.0 instead of just 0?

I can't remember.

> Is there a difference?

No, no difference.


        Stefan

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hi Tom,

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>> FYI, have a look at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12894.
>
> That explains it. I'm on Emacs 24.1 and it does not have this
> scheduling code, so that's why it works for me. I didn't think
> they changed this recently.
>
> Anyway, you can try calling diff-refine-hunk explicitly after
> diff-hunk-next then:
>
>   (condition-case nil
>       (save-excursion
>         (goto-char (point-min))
>         (while (not (eobp))
>           (diff-hunk-next)
>           (diff-refine-hunk)))
>     (error nil)))
>
> I can't try it, because I use 24.1, but it may work.

I wasn't sure how to adapt the code. Thanks for trying...

And the results of the jury are:
- it works for the refining of *all* hunks
- it does not work wrt the position of the cursor, that is it's at the end of
  the buffer...

Thanks for solving already half of the problem!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:

> 
> And the results of the jury are:
> - it works for the refining of *all* hunks

Cool. I think the last hunk is actually processed twice, once when
you call the refine function explicitly and once when the timer mentioned
in the bug report explanation kicks in. But it's not a big deal, probably
does not add a noticable delay.

> - it does not work wrt the position of the cursor, that is it's at the end of
>   the buffer...
> 

I have no idea what causes this. You can try adding a (goto-char (point-min))
call to the end of the refine all function or if it does not work then you
can try using a null timer for this, so it is called after the command is
finished, and hopefully after that code is finished which moves the cursor:

(run-at-time 0.0 nil (lambda () (goto-char (point-min))))

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Tom,

Tom wrote:
> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>> 
>> And the results of the jury are:
>> - it works for the refining of *all* hunks
>
> Cool. I think the last hunk is actually processed twice, once when you call
> the refine function explicitly and once when the timer mentioned in the bug
> report explanation kicks in. But it's not a big deal, probably does not add
> a noticable delay.
>
>> - it does not work wrt the position of the cursor, that is it's at the end
>>   of the buffer...
>
> I have no idea what causes this. You can try adding a (goto-char
> (point-min)) call to the end of the refine all function

Did not work.

> or if it does not work then you can try using a null timer for this, so it
> is called after the command is finished, and hopefully after that code is
> finished which moves the cursor:
>
> (run-at-time 0.0 nil (lambda () (goto-char (point-min))))

Like this?

--8<---------------cut here---------------start------------->8---
  (defun my/diff-refine-all-hunks ()
    (interactive)
    (condition-case nil
        (save-excursion
          (goto-char (point-min))
          (while (not (eobp))
            (diff-hunk-next)
            (diff-refine-hunk)))
      (error nil))
    (run-at-time 0.0 nil (lambda () (goto-char (point-min)))))
--8<---------------cut here---------------end--------------->8---

Yep!  This does work perfectly: all hunks refined, and pointer at beginning of
buffer...

Thanks a lot for your more than precious help!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:

> 
> Yep!  This does work perfectly: all hunks refined, and pointer at beginning of
> buffer...
> 
> Thanks a lot for your more than precious help!
> 

No problem. I'll also need it when I upgrade emacs, so I helped
my future self as well. :)


BTW, highlighting within the lines is helpful in most of the cases, but
sometimes when the diff is very convoluted it can get in the way. To remedy
this I added a key (f7) which when pressed in the diff buffer toggles
the in-line highlight on and off.

I put it here in case someone else also finds it useful:



(add-hook 'diff-mode-hook 'my-diff-stuff)

(setq my-diff-refine-change-color "yellow1")

(defun my-toggle-diff-refine-change-color()
  (interactive)
  (if (face-background 'diff-refine-change)
      (set-face-background 'diff-refine-change nil)
    (set-face-background 'diff-refine-change my-diff-refine-change-color)))


(defun my-diff-stuff ()
  (set-face-background 'diff-refine-change my-diff-refine-change-color)
  (local-set-key (kbd "<f7>") 'my-toggle-diff-refine-change-color)

  (unless (or (eq this-command 'dvc-diff)
              (eq this-command 'dvc-generic-refresh)
              (> (buffer-size) 20000))
    (my-refine-all-diff-hunks)))

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hi Tom,

"Sebastien Vauban" wrote:
> Tom wrote:
>> Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>>>
>>> And the results of the jury are:
>
>   (defun my/diff-refine-all-hunks ()
>     (interactive)
>     (condition-case nil
>         (save-excursion
>           (goto-char (point-min))
>           (while (not (eobp))
>             (diff-hunk-next)
>             (diff-refine-hunk)))
>       (error nil))
>     (run-at-time 0.0 nil (lambda () (goto-char (point-min)))))
>
> Yep!  This does work perfectly: all hunks refined, and pointer at beginning of
> buffer...
>
> Thanks a lot for your more than precious help!

After a couple of days using this, I've observed a very tricky collateral
damage in Gnus...

Let's assume I have received 5 mails:

--8<---------------cut here---------------start------------->8---
*   18 Sun 14:25   0.2k Foo  Mail #1 Hello
    18 Sun 14:25   0.4M Bar  Mail #2 How are you?
    18 Sun 17:58   6.9k Baz  Mail #3 [diff] Fix bug
    18 Sun 18:06   4.1k Baz  Mail #4 [diff] Fix doc
    18 Sun 18:27   3.1k Baz  Mail #5 I've done it
--8<---------------cut here---------------end--------------->8---

* = position of the cursor

... and I want first to read the 3rd one. I position the cursor on that one...

--8<---------------cut here---------------start------------->8---
    18 Sun 14:25   0.2k Foo  Mail #1 Hello
    18 Sun 14:25   0.4M Bar  Mail #2 How are you?
*   18 Sun 17:58   6.9k Baz  Mail #3 [diff] Fix bug
    18 Sun 18:06   4.1k Baz  Mail #4 [diff] Fix doc
    18 Sun 18:27   3.1k Baz  Mail #5 I've done it
--8<---------------cut here---------------end--------------->8---

... press RET, get a new buffer created on the mid-right pane, and read it.

--8<---------------cut here---------------start------------->8---
*   18 Sun 14:25   0.2k Foo  Mail #1 Hello           |
    18 Sun 14:25   0.4M Bar  Mail #2 How are you?    |
    18 Sun 17:58   6.9k Baz  Mail #3 [diff] Fix bug  | (contents of 3rd email)
    18 Sun 18:06   4.1k Baz  Mail #4 [diff] Fix doc  |
    18 Sun 18:27   3.1k Baz  Mail #5 I've done it    |
--8<---------------cut here---------------end--------------->8---

Then, as I always do, I simply press "n" to read the "next one" (4th)... but
Gnus displays me the 1st one!

Why?  Because the cursor has been positioned on the first line of my *summary*
buffer (on the left), after displaying the contents of the "Fix bug" email (on
the right).

Why?  Because diff-mode is called (as that email contains a diff), and some
some effect -- which I don't understand -- is that *the cursor is repositioned
onto the first line of the summary buffer* (while the code is supposed to be
executed in the other window, the one with the *contents* of the mail).

So, here, to reproduce the problem, I have to:

- have emails with diffs in them (otherwise, diff-mode won't be called)

- skip reading the first email (so that, clicking "n" does open the "next"
  unread email... from the current cursor position, which is wrong here...)

I know describing a dynamic behavior is not obvious per email. So, did you
understand the description of the problem, at least?

Do you understand why this is occurring, or have some helpful ideas?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Tom]

Sebastien Vauban <wxhgmqzgwmuf@...> writes:
>
>  Why?  Because diff-mode is called (as that email contains a
> diff), and some some effect -- which I don't understand -- is
> that *the cursor is repositioned onto the first line of the
> summary buffer* (while the code is supposed to be executed in
> the other window, the one with the *contents* of the mail).

I don't use Gnus, but from your decription it seem this line

(run-at-time 0.0 nil (lambda () (goto-char (point-min)))))

causes the problem. It is executed after the current command is
finished and I guess Gnus puts back the cursor to the summary
buffer, so this delayed (goto-char (point-min)) is executed
there.

An obvious fix is to execute the delayed goto-char only if 
the cursor is in a diff buffer after the command, that is
don't do it in the Gnus summary buffer:

(run-at-time 0.0 nil (lambda ()
                       (if (eq major-mode 'diff-mode)
                           (goto-char (point-min)))))

Re: Diff could also show the changes within lines

[Stefan Monnier]

> Looks like it does not work with DVC diff, so it needs to be disabled for
> that:

If you describe the problem, maybe it can be fixed instead.


        Stefan

Re: Diff could also show the changes within lines

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > Looks like it does not work with DVC diff, so it needs to be disabled for
> > that:
> 
> If you describe the problem, maybe it can be fixed instead.
> 

It seems dvc-diff calls the diff hooks early, when the diff
buffer is still empty (I guess it's because it starts an external async
process to get the diff ouput), so diff refine cannot find the diff
headers in the buffer.

Diff could also show the changes within lines

[Sebastien Vauban]

Hello,

This code, obtained after several iterations in October 2012 [1], did work
for some time.

Though, I can't get it working anymore with GNU Emacs 24.3.50.1
(i686-pc-mingw32) of 2013-10-19.

--8<---------------cut here---------------start------------->8---
  ;; mode for viewing/editing context diffs
  (with-eval-after-load "diff-mode"

    ;; highlight the changes with better granularity
    (defun my-diff-make-fine-diffs ()
      (interactive)
      (let (diff-auto-refine-mode)      ; avoid refining the hunks redundantly ...
        (condition-case nil
            (save-excursion
              (goto-char (point-min))
              (while (not (eobp))
                (diff-hunk-next)
                (diff-refine-hunk)))    ; ... when this does it.
          (error nil))
        (run-at-time 0.0 nil
                     (lambda ()
                       (if (eq major-mode 'diff-mode)
                           ;; put back the cursor only if still in a Diff buffer
                           ;; after the delay
                           (goto-char (point-min)))))))

    (defun my-diff-make-fine-diffs-if-necessary ()
      "Auto-refine only the small regions."
      (unless (> (buffer-size) 20000)
        (my-diff-make-fine-diffs)))

    ;; enable Diff Auto-Refine mode
    (add-hook 'diff-mode-hook
              'my-diff-make-fine-diffs-if-necessary))
--8<---------------cut here---------------end--------------->8---

Now, while it's still being called, and still going in the `while' loop,
it does not refine any hunk anymore...

Any idea on what could go wrong?

Best regards,
  Seb

[1] See https://groups.google.com/forum/#!msg/gnu.emacs.help/-PFoXXV_RLY/W-J0rS5BZ00J

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> Now, while it's still being called, and still going in the `while' loop,
> it does not refine any hunk anymore...

Did you try to edebug (this looks like a good exercise in debugging!)?

Michael.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hello Michael,

Michael Heerdegen wrote:
> "Sebastien Vauban" writes:
>
>> Now, while it's still being called, and still going in the `while' loop,
>> it does not refine any hunk anymore...
>
> Did you try to edebug (this looks like a good exercise in debugging!)?

No, you're right. Let's first try to solve this by myself. I'll come
back with more info at the point I'm stuck with.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hello Michael,

Michael Heerdegen wrote:
> "Sebastien Vauban" writes:
>
>> Now, while it's still being called, and still going in the `while' loop,
>> it does not refine any hunk anymore...
>
> Did you try to edebug (this looks like a good exercise in debugging!)?

I did, in a minimal Emacs configuration:

--8<---------------cut here---------------start------------->8---
(load-theme 'leuven t)

;; mode for viewing/editing context diffs
(with-eval-after-load "diff-mode"

  (defun my-diff-make-fine-diffs ()
    "Enable Diff Auto Refine mode."
    (interactive)
    (message ">>> BEGIN <<<")
    (let (diff-auto-refine-mode)
      (condition-case nil
          (save-excursion
            (goto-char (point-min))
            (while (not (eobp))
              (diff-hunk-next)
              (diff-refine-hunk)
              (message ">> I've refined the next hunk... <<")))
        (error nil))
      (run-at-time 0.0 nil
                   (lambda ()
                     (if (eq major-mode 'diff-mode)
                         ;; put back the cursor only if still in a Diff buffer
                         ;; after the delay
                         (goto-char (point-min))))))
    (message ">>> END <<<"))

  (defun my--diff-make-fine-diffs-if-necessary ()
    "Auto-refine only the regions of 14,000 bytes or less."
    ;; check for auto-refine limit
    (unless (> (buffer-size) 14000)
      (my-diff-make-fine-diffs)))

  (add-hook 'diff-mode-hook
            'my--diff-make-fine-diffs-if-necessary))
--8<---------------cut here---------------end--------------->8---

Weirdly enough, it does not work when done automatically, well when done
interactively...

In *all* cases, I see (in the *Messages* buffer):

--8<---------------cut here---------------start------------->8---
>>> BEGIN <<<
>> I've refined the next hunk... << [2 times]
>>> END <<<
--8<---------------cut here---------------end--------------->8---

... so, even when done by the hook, I see those messages, as if the
refining was done, but it's not visible in the Diff buffer, as you can
see on http://screencast.com/t/e7et4xeO.

When Edebugging, or when going to the *vc-diff* buffer and calling M-x
my-diff-make-fine-diffs, the same messages appear in the *Messages*
buffer, but the buffer is well colored differently, as you can see on
http://screencast.com/t/K2VdxlF2fMld.

So, I don't understand anything anymore... and don't know how to
proceed to further debug this...

Side (though important) question: when Edebugging, as soon as I step
through the function, the *vc-diff* buffer disappears from my
sight.  I always have to switch to it, and check what changed, to see
what's going on.  Is there a way to make the buffer (on which the code
is applied) stay visible during the stepping session?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> I did, in a minimal Emacs configuration:
>
> (load-theme 'leuven t)
>
> ;; mode for viewing/editing context diffs
> (with-eval-after-load "diff-mode"
>
>   (defun my-diff-make-fine-diffs ()
>     "Enable Diff Auto Refine mode."
>     (interactive)
>     (message ">>> BEGIN <<<")
>     (let (diff-auto-refine-mode)
>       (condition-case nil
>           (save-excursion
>             (goto-char (point-min))
>             (while (not (eobp))
>               (diff-hunk-next)
>               (diff-refine-hunk)
>               (message ">> I've refined the next hunk... <<")))
>         (error nil))
>       (run-at-time 0.0 nil
>                    (lambda ()
>                      (if (eq major-mode 'diff-mode)
>                          ;; put back the cursor only if still in a Diff buffer
>                          ;; after the delay
>                          (goto-char (point-min))))))
>     (message ">>> END <<<"))
>
>   (defun my--diff-make-fine-diffs-if-necessary ()
>     "Auto-refine only the regions of 14,000 bytes or less."
>     ;; check for auto-refine limit
>     (unless (> (buffer-size) 14000)
>       (my-diff-make-fine-diffs)))
>
>   (add-hook 'diff-mode-hook
>             'my--diff-make-fine-diffs-if-necessary))
>
> Weirdly enough, it does not work when done automatically, well when done
> interactively...
>
> In *all* cases, I see (in the *Messages* buffer):
>
> >>> BEGIN <<<
> >> I've refined the next hunk... << [2 times]
> >>> END <<<
>
> ... so, even when done by the hook, I see those messages, as if the
> refining was done, but it's not visible in the Diff buffer, as you can
> see on http://screencast.com/t/e7et4xeO.
>
> When Edebugging, or when going to the *vc-diff* buffer and calling M-x
> my-diff-make-fine-diffs, the same messages appear in the *Messages*
> buffer, but the buffer is well colored differently, as you can see on
> http://screencast.com/t/K2VdxlF2fMld.

My guess is that diff-mode-hook is not a good place to push your
function to.  Maybe it is called too early, and the effect is somehow
reverted later.  You may try something like

(advice-add
 'vc-diff :after
 (lambda (&rest _)
   (my--diff-make-fine-diffs-if-necessary)))

I wonder if that work's.

> So, I don't understand anything anymore... and don't know how to
> proceed to further debug this...

Have you already tried to (debug-on-entry 'my-diff-make-fine-diffs)?  I
wonder how the buffer looks like after `my-diff-make-fine-diffs' is
done.  You may try to find out what is going on later.

> Side (though important) question: when Edebugging, as soon as I step
> through the function, the *vc-diff* buffer disappears from my
> sight.  I always have to switch to it, and check what changed, to see
> what's going on.  Is there a way to make the buffer (on which the code
> is applied) stay visible during the stepping session?

I think it is best to display it just in a different frame after
starting edebug.  Yes, it is very aggressive in capturing frames.


Regards,

Michael.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hello Michael,

Michael Heerdegen wrote:
> "Sebastien Vauban" writes:
>
>> Weirdly enough, [my-diff-make-fine-diffs] does not work when done
>> automatically, well when done interactively...
>>
>> In *all* cases, I see (in the *Messages* buffer):
>>
>> >>> BEGIN <<<
>> >> I've refined the next hunk... << [2 times]
>> >>> END <<<
>>
>> ... so, even when done by the hook, I see those messages, as if the
>> refining was done, but it's not visible in the Diff buffer, as you can
>> see on http://screencast.com/t/e7et4xeO.
>>
>> When Edebugging, or when going to the *vc-diff* buffer and calling M-x
>> my-diff-make-fine-diffs, the same messages appear in the *Messages*
>> buffer, but the buffer is well colored differently, as you can see on
>> http://screencast.com/t/K2VdxlF2fMld.
>
> My guess is that diff-mode-hook is not a good place to push your
> function to.  Maybe it is called too early, and the effect is somehow
> reverted later.  You may try something like
>
> (advice-add
>  'vc-diff :after
>  (lambda (&rest _)
>    (my--diff-make-fine-diffs-if-necessary)))
>
> I wonder if that work's.

Well, that does work!  Thanks a lot... That's something very
handy... (that everybody should have IMO)...

>> So, I don't understand anything anymore... and don't know how to
>> proceed to further debug this...
>
> Have you already tried to (debug-on-entry 'my-diff-make-fine-diffs)?  I
> wonder how the buffer looks like after `my-diff-make-fine-diffs' is
> done.  You may try to find out what is going on later.
>
>> Side (though important) question: when Edebugging, as soon as I step
>> through the function, the *vc-diff* buffer disappears from my
>> sight.  I always have to switch to it, and check what changed, to see
>> what's going on.  Is there a way to make the buffer (on which the code
>> is applied) stay visible during the stepping session?
>
> I think it is best to display it just in a different frame after
> starting edebug.  Yes, it is very aggressive in capturing frames.

s/frames/windows?

Thanks for the tip. I'll try next time (I never use frames).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Sebastien Vauban]

"Sebastien Vauban" wrote:
> Michael Heerdegen wrote:
>> "Sebastien Vauban" writes:
>>
>>> Weirdly enough, [my-diff-make-fine-diffs] does not work when done
>>> automatically, well when done interactively...
>>
>> My guess is that diff-mode-hook is not a good place to push your
>> function to.  Maybe it is called too early, and the effect is somehow
>> reverted later.  You may try something like
>>
>> (advice-add
>>  'vc-diff :after
>>  (lambda (&rest _)
>>    (my--diff-make-fine-diffs-if-necessary)))
>>
>> I wonder if that work's.
>
> Well, that does work!  Thanks a lot... That's something very
> handy... (that everybody should have IMO)...

I now tried to get that as well in Gnus emails. I often receive emails
with Diffs inside them, and they're correctly highlighted (thanks to
some Gnus black magic):

--8<---------------cut here---------------start------------->8---
    ;; regexp matching diff groups
    (setq mm-uu-diff-groups-regexp ".*")
--8<---------------cut here---------------end--------------->8---

Though, with your above suggestion, those mails aren't auto-refined...

I tried adding the following:

--8<---------------cut here---------------start------------->8---
    (add-hook 'gnus-article-mode-hook
              'my--diff-make-fine-diffs-if-necessary)
--8<---------------cut here---------------end--------------->8---

but it doesn't help.

Any other excellent idea?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Sebastien Vauban]

"Sebastien Vauban" wrote:
> "Sebastien Vauban" wrote:
>> Michael Heerdegen wrote:
>>> "Sebastien Vauban" writes:
>>>
>>>> Weirdly enough, [my-diff-make-fine-diffs] does not work when done
>>>> automatically, well when done interactively...
>>>
>>> My guess is that diff-mode-hook is not a good place to push your
>>> function to.  Maybe it is called too early, and the effect is somehow
>>> reverted later.  You may try something like
>>>
>>> (advice-add
>>>  'vc-diff :after
>>>  (lambda (&rest _)
>>>    (my--diff-make-fine-diffs-if-necessary)))
>>>
>>> I wonder if that work's.
>>
>> Well, that does work!  Thanks a lot... That's something very
>> handy... (that everybody should have IMO)...
>
> I now tried to get that as well in Gnus emails. I often receive emails
> with Diffs inside them, and they're correctly highlighted (thanks to
> some Gnus black magic):
>
>     ;; regexp matching diff groups
>     (setq mm-uu-diff-groups-regexp ".*")
>
> Though, with your above suggestion, those mails aren't auto-refined...
>
> I tried adding the following:
>
>     (add-hook 'gnus-article-mode-hook
>               'my--diff-make-fine-diffs-if-necessary)
>
> but it doesn't help.

Needless to say (but it's better to be stated ;-)): the auto-refine of
Diffs in emails works when calling my--diff-make-fine-diffs-if-necessary
interactively...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> Needless to say (but it's better to be stated ;-)): the auto-refine of
> Diffs in emails works when calling my--diff-make-fine-diffs-if-necessary
> interactively...

That's good.  Then try adding it to `gnus-article-prepare-hook'.

Michael.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Michael Heerdegen wrote:
> "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>
>> Needless to say (but it's better to be stated ;-)): the auto-refine of
>> Diffs in emails works when calling my--diff-make-fine-diffs-if-necessary
>> interactively...
>
> That's good.  Then try adding it to `gnus-article-prepare-hook'.

I was full of "excitement" but, nope, it isn't that one... That does not
help.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> > That's good.  Then try adding it to `gnus-article-prepare-hook'.
>
> I was full of "excitement" but, nope, it isn't that one... That does not
> help.

Mmh, I'm no Gnus expert, I hoped that would do it.  Maybe you can find a
better place when reading the sources?  Maybe an after advice for
`gnus-summary-show-article' works.  Again, just guessing.

In any case, the ugly solution of using an idle timer should always
work.  Not very cool, but also not worse than doing it manually.

Michael.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Michael Heerdegen wrote:
> Sebastien Vauban writes:
>
>> > That's good.  Then try adding it to `gnus-article-prepare-hook'.
>>
>> I was full of "excitement" but, nope, it isn't that one... That does
>> not help.
>
> Mmh, I'm no Gnus expert, I hoped that would do it.  Maybe you can find
> a better place when reading the sources?  Maybe an after advice for
> `gnus-summary-show-article' works.  Again, just guessing.

This:

--8<---------------cut here---------------start------------->8---
    (advice-add
     'gnus-summary-show-article :after
     (lambda (&rest _)
       (my--diff-make-fine-diffs-if-necessary)))
--8<---------------cut here---------------end--------------->8---

did not work either.

> In any case, the ugly solution of using an idle timer should always
> work.  Not very cool, but also not worse than doing it manually.

If you're talking of things such as:

--8<---------------cut here---------------start------------->8---
    (add-hook 'gnus-article-prepare-hook
              (lambda ()
                (run-at-time 0.0 nil 'my--diff-make-fine-diffs-if-necessary)))

    (add-hook 'gnus-article-mode-hook
              (lambda ()
                (run-at-time 0.0 nil 'my--diff-make-fine-diffs-if-necessary)))
--8<---------------cut here---------------end--------------->8---

I've tried them both with no success either...

One question I've for the last 2 cases is "where is point?" when those
functions are run?  If they're in the summary buffer, no luck for me, or
will it be moved to the buffer where the hook is supposed to be applied?

Thanks for your help!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> > In any case, the ugly solution of using an idle timer should always
> > work.  Not very cool, but also not worse than doing it manually.
>
> If you're talking of things such as:
>
>     (add-hook 'gnus-article-prepare-hook
>               (lambda ()
>                 (run-at-time 0.0 nil 'my--diff-make-fine-diffs-if-necessary)))
>
>     (add-hook 'gnus-article-mode-hook
>               (lambda ()
>                 (run-at-time 0.0 nil 'my--diff-make-fine-diffs-if-necessary)))
>
> I've tried them both with no success either...
>
> One question I've for the last 2 cases is "where is point?" when those
> functions are run?  If they're in the summary buffer, no luck for me, or
> will it be moved to the buffer where the hook is supposed to be applied?

You mean "which buffer is current?" (every buffer has a `point').  It's
easy: when the timer fires, there's no change of current buffer - there
is no environment restored or so.  The given function is called with the
given args - that's all.  Whatever buffer may be current then.

I would wrap your call in `gnus-with-article-buffer', and also use an
idle timer (`run-with-idle-timer').  If
`my--diff-make-fine-diffs-if-necessary' really works when called
explicitly, it should also work when called by the timer with the right
buffer current after Gnus has finished preparing the buffer.

Regards,

Michael.

Re: Diff could also show the changes within lines

[Stefan Monnier]

> I now tried to get that as well in Gnus emails. I often receive emails
> with Diffs inside them, and they're correctly highlighted (thanks to
> some Gnus black magic):

I'd welcome a patch which makes diff-mode always perform
refined highlighting.  This means that it should be called
from font-lock-keywords.


        Stefan

Re: Diff could also show the changes within lines

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd welcome a patch which makes diff-mode always perform refined
> highlighting.  This means that it should be called from
> font-lock-keywords.

Sebastian, want to make an appropriate bug report?

Regards,

Michael.

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> > I think it is best to display it just in a different frame after
> > starting edebug.  Yes, it is very aggressive in capturing frames.
>
> s/frames/windows?

I meant the windows of the frame(s)  ;-)

Michael.

Re: Diff could also show the changes within lines

[Michael Heerdegen]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> > I think it is best to display it just in a different frame after
> > starting edebug.  Yes, it is very aggressive in capturing frames.
>
> s/frames/windows?

I meant the windows of the frame(s)  ;-)

Michael.

Re: Diff could also show the changes within lines

[Michael Heerdegen]

Hi Sebastien,

> > I think it is best to display it just in a different frame after
> > starting edebug.  Yes, it is very aggressive in capturing frames.
>
> s/frames/windows?

I meant the windows of the frame(s)  ;-)

Michael.

Re: Diff could also show the changes within lines

[Sebastien Vauban]

Hello,

Michael Heerdegen wrote:
> My guess is that diff-mode-hook is not a good place to push your
> function to.  Maybe it is called too early, and the effect is somehow
> reverted later.  You may try something like
>
> (advice-add
>  'vc-diff :after
>  (lambda (&rest _)
>    (my--diff-make-fine-diffs-if-necessary)))
>
> I wonder if that work's.

That worked, as you already know.

However, as the above code does not seem to run on slightly older Emacs
versions, I tried to convert it to:

--8<---------------cut here---------------start------------->8---
  (defadvice vc-diff (after leuven-vc-diff activate)
    "Push the auto-refine function after `vc-diff'."
    (my--diff-make-fine-diffs-if-necessary)))
--8<---------------cut here---------------end--------------->8---

... which does not work.

What am I missing?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Diff could also show the changes within lines

[Michael Heerdegen]

Sebastien Vauban <sva-news@mygooglest.com>
writes:

>   (defadvice vc-diff (after leuven-vc-diff activate)
>     "Push the auto-refine function after `vc-diff'."
>     (my--diff-make-fine-diffs-if-necessary)))
>
> ... which does not work.

No, that's a correct rewrite with defadvice.  Dunno why it doesn't work,
probably diff.el is different in your older version.  You can just try
to find a better place to execute your function, e.g. by stepping
through the code with a debugger.  I could do nothing else, because I
don't use this functionality and don't know the code.

Can't you use ediff, btw?

Michael.