Re: Syntactic fontification of diff hunks

[Juri Linkov <juri@linkov.net>]

>> > I suppose some integration will be needed before this works in Magit, too?

If Magit doesn't use diff-mode, then yes, the code should be duplicated
in Magit.

>> > Also, it looks like it’s going to be somewhere between slightly and
>> > horribly inaccurate depending on where the hunk starts (e.g. in the
>> > middle of a string literal or comment)?
>>
>> Which probably thwarts the whole project.
>
> Not necessarily; I think it might be good enough for a major part of
> real-life use cases. Also, if the diff comes from an interactive tool,
> the user can probably just increase context size a few times so as to
> shift the balance towards “slightly inaccurate”.

Such as e.g. using --function-context for git will provide enough context.

>> Theoretically if being behind
>> the end or start of a string could be fetched from source files -
>
> That condition is undecidable based on the hunk text alone.
>
> An implementation that has access to at least one of the source files
> could just fontify that whole file and extract fontification from that
> using hunk line offsets (assuming they are accurate). This probably
> covers Ediff, vc, and Magit, but not reading standalone patches.

I see that gitlab and github highlight syntax on server using whole
files, then send highlighted html chunks to browser.  The same way we
can easily get whole files from git by their sha from the index in diff
headers, or get files by relative paths when using diff on regular files.

But when reading standalone patches e.g. in Gnus, then indeed there is
a potential problem, but in practice when I looked at large patches,
there was only small amount of such problematic places, that fortunately
are narrowed to only one diff hunk, unlike failures in font-lock of some
programming language modes (most often I remember such cases in cperl mode)
where an incorrectly recognized quote breaks fontification to the end of
the whole file.

> There is also the theoretical issue of syntax being changed by the
> patch — e.g. introducing an unbalanced multiline string or comment
> opener or closer on a separate line.
>
>      (defun foo ()
>     +  "
>        (bar baz)
>     +  "
>        (quux xyzzy))
>
> The middle line here has (punctuation identifier identifier
> punctuation) syntax according to the “before” file, but (string)
> according to “after”.

I think “after” should have priority over “before” in context because the
main goal of reading patches is to see how code will look after changes,
so in this case ‘(bar baz)’ should be highlighted as a string.