Re: Syntactic fontification of diff hunks

[Juri Linkov]

> I see another potential issue. In your patch above, the whole hunk is
> fontified as a whole, with all its context lines, deleted lines, and
> added lines. A change on the line that opens a multiline string will
> disrupt syntax until the end of hunk:
>
>      (def foo ()
>     -  "Lorem ipsum
>     +  "Cthulhu fhtagn
>        dolor sit amet")
>
> A more robust approach would be to fontify separately the “after”
> version by taking context + added lines and “before” by taking context
> + deleted lines. Then use fontification from “before” for deleted
> lines, and from “after” for context and added lines.

Yes, this is easy to do.  Also there is one significant difference
between diff refinement overlays and diff syntax overlays: while for
multiline refinement it's probably ok to put a refined overlay over the
diff indicator symbols (such as + or - on at the beginning of the line)
when refinement is highlighted using background colors and indicator with
foreground color, but for multiline syntax elements (e.g. multiline
strings) their foreground colors will overwrite foreground colors of
diff indicators.  A solution would be to split multiline syntax overlays
and put them separately on each diff line.

But the real problem is with git diffs.  I tried to reuse the same code
that visits a diff hunk in the corresponding file (this code could be used
to visit the file, fontify it and copy fontification back to the diff buffer),
but bumped into a deficiency:

1. try to open some git log with vc-print-log in a *vc-change-log* buffer;
2. open a diff using ‘d’ (log-view-diff) or ‘D’ (log-view-diff-changeset);
3. try to navigate to the corresponding place in the file with ‘C-c C-c’
   (diff-goto-source)

It visits the current file version and most of the time errs with
“Hunk text not found”.

It seems the most sensible would be to checkout the corresponding file
revision like does ‘f’ (log-view-find-revision) from *vc-change-log*
(BTW, I wonder why it creates a file with the name “filename~commit-sha~”
instead of “filename~treefile-sha~”), but unlike ‘f’ better not to save it,
but just to create a file buffer and navigate to the changed place.

Another question: shouldn't diff-goto-source be context-sensitive?
Currently it visits the old file when invoked with the prefix arg.
Maybe better also allow it to visit the old file when invoked
on old lines beginning with ‘-’ or ‘<’?