unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 61215@debbugs.gnu.org
Subject: bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
Date: Fri, 03 Feb 2023 13:59:57 +0200	[thread overview]
Message-ID: <83pmarufgi.fsf@gnu.org> (raw)
In-Reply-To: <86bkmbfalm.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 03 Feb 2023 09:53:57 +0200)

> From: Juri Linkov <juri@linkov.net>
> Cc: 61215@debbugs.gnu.org
> Date: Fri, 03 Feb 2023 09:53:57 +0200
> 
> >> 1. Set debug-on-error and backtrace-on-redisplay-error to t
> >> 2. Create a commit with some diff hunks in a prog mode at the beginning,
> >>    and a single-line 1MB file added at the end;
> >> 3. From *vc-change-log* type `d' on that commit that opens *vc-diff* buffer
> >> 4. Scroll the *vc-diff* buffer
> >>
> >> It displays an error in the *Warning* buffer:
> >>
> >>   ⛔ Warning (error): Error in a redisplay Lisp hook.  See buffer *Redisplay_trace*
> >
> > Can you reproduce this easily?
> 
> Once you create such a commit, it's easy to reproduce this on it.

The recipe is quite complicated, doesn't include a file with the long
line that you used, and describes several steps in incomplete and
vague manner.  So it isn't so easy to reproduce for me, not really.
I'd probably need several attempts until I succeed, and the fact that
I need to create a repository just for this doesn't help (diff-mode is
not just for VCS diffs, right?)

If you can add the missing details and the file, it might be easier.

> > If so, does the patch below help?
> 
> Unfortunately, no.  Still such a backtrace:
> 
> Error: args-out-of-range (#<buffer *vc-diff*> 2000 1906)
>   mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x12357049b0517812>))
>   debug-early-backtrace()
>   debug-early(error (args-out-of-range #<buffer *vc-diff*> 2000 1906))
>   buffer-substring-no-properties(2000 1906)
>   (let* ((hunk (buffer-substring-no-properties (max beg (point-min)) (min end (point-max)))) ...
>   diff-syntax-fontify-hunk(2000 250945 nil)
>   diff-syntax-fontify(2000 250945)
>   #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>(2000 250945)
>   diff--iterate-hunks(10000 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>)
>   diff--font-lock-syntax(10000)

This probably means diff-mode relies on the buffer being widened.
Which is a bad idea for font-lock functions.

Anyway, how about the below?

diff --git a/lisp/vc/diff-mode.el b/lisp/vc/diff-mode.el
index eb01ded..62db362 100644
--- a/lisp/vc/diff-mode.el
+++ b/lisp/vc/diff-mode.el
@@ -2762,7 +2762,10 @@ diff-syntax-fontify-hunk
   "Highlight source language syntax in diff hunk between BEG and END.
 When OLD is non-nil, highlight the hunk from the old source."
   (goto-char beg)
-  (let* ((hunk (buffer-substring-no-properties beg end))
+  (let* ((hunk (buffer-substring-no-properties (min (max beg (point-min))
+                                                    (point-max))
+                                               (max (min end (point-max))
+                                                    (point-min))))
          ;; Trim a trailing newline to find hunk in diff-syntax-fontify-props
          ;; in diffs that have no newline at end of diff file.
          (text (string-trim-right





  reply	other threads:[~2023-02-03 11:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 18:18 bug#61215: 29.0.60; font-lock broken in diff-mode with long lines Juri Linkov
2023-02-01 18:35 ` Eli Zaretskii
2023-02-02 17:16   ` Juri Linkov
2023-02-02 20:41     ` Eli Zaretskii
2023-02-03  7:53       ` Juri Linkov
2023-02-03 11:59         ` Eli Zaretskii [this message]
2023-02-05 18:28           ` Juri Linkov
2023-02-05 18:38             ` Eli Zaretskii
2023-02-06 17:15               ` Juri Linkov
2023-02-06 18:10                 ` Eli Zaretskii
2023-02-06 18:11                   ` Gregory Heytings
2023-02-27 18:28                   ` Juri Linkov
2023-02-27 19:07                     ` Eli Zaretskii
2023-02-27 19:23                     ` Gregory Heytings
2023-02-27 19:25                       ` Gregory Heytings
2023-03-30 23:22     ` Gregory Heytings
2023-03-31  7:10       ` Juri Linkov
2023-03-31  7:30         ` Juri Linkov
2023-04-01  0:22           ` Gregory Heytings
2023-04-01 18:19             ` Juri Linkov
2023-03-31  7:40         ` Gregory Heytings

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pmarufgi.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=61215@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).