[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recent diff-mode changes feel slow with TRAMP

From: Juri Linkov
Subject: Re: Recent diff-mode changes feel slow with TRAMP
Date: Sat, 19 Jan 2019 23:07:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

> OK. Yes. Setting diff-font-lock-syntax to nil makes it fast again.
> Thanks a lot for pointing me to that.
> The docs for diff-font-lock-syntax say that 'hunk-only is the fastest
> setting here, but that's not true, right? Isn't nil the fastest one?

`hunk-only' is the fastest non-nil option.

> For my use cases, I don't think I want this enabled at all, TRAMP or
> not. Combined with refinement, this makes the diffs more difficult to
> interpret, at least to me. And even without TRAMP, this makes it slower.
> Do we really want both refinement and this font-locking enabled by
> default?

Modern version control systems like GitHub and GitLab enable both by default.

> There's also a visual issue with auto-refinement. If I load a patch file
> with 'emacs -Q -rv' (no user settings, but reverse video), it looks like
> this:
>   http://notes.secretsauce.net/emacsdiff.png
> Note that the bright green refined face makes the leading + invisible.
> There's an identical problem with the bright red making the leading -
> invisible.

It's easy to improve auto-refinement to not put highlighting on diff
indicators like it's already implemented in line-based diff-font-lock-syntax.

BTW, there is another issue that could be improved in auto-refinement:
when changes are only in whitespace it highlights nothing because it's
word-based.  I think in this case it could fall back to the default mode
that doesn't ignore differences in whitespace, thus highlighting whitespace.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]