* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
@ 2023-02-01 18:18 Juri Linkov
2023-02-01 18:35 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2023-02-01 18:18 UTC (permalink / raw)
To: 61215
>> when there is at least one long line near the end of
>> a diff-mode buffer, then sometimes the buffer gets truncated,
>> 'diff-hunk-file-names' returns nil on diff headings,
>> and there are a lot of such errors in the Messages buffer:
>>
>> Error during redisplay: (jit-lock-function 1) signaled (args-out-of-range #<buffer *vc-diff*> 1118 1370)
>
> We can and should fix this and other problems, but only if they are
> reported. Would you please file a bug report for any such problem you
> find?
This is a new bug report created from bug#56682.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
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
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-01 18:35 UTC (permalink / raw)
To: Juri Linkov; +Cc: 61215
> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 01 Feb 2023 20:18:09 +0200
>
> >> when there is at least one long line near the end of
> >> a diff-mode buffer, then sometimes the buffer gets truncated,
> >> 'diff-hunk-file-names' returns nil on diff headings,
> >> and there are a lot of such errors in the Messages buffer:
> >>
> >> Error during redisplay: (jit-lock-function 1) signaled (args-out-of-range #<buffer *vc-diff*> 1118 1370)
> >
> > We can and should fix this and other problems, but only if they are
> > reported. Would you please file a bug report for any such problem you
> > find?
>
> This is a new bug report created from bug#56682.
Thanks. Can you post a recipe for reproducing that, preferably
starting from "emacs -Q"?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-01 18:35 ` Eli Zaretskii
@ 2023-02-02 17:16 ` Juri Linkov
2023-02-02 20:41 ` Eli Zaretskii
2023-03-30 23:22 ` Gregory Heytings
0 siblings, 2 replies; 21+ messages in thread
From: Juri Linkov @ 2023-02-02 17:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61215
>> >> when there is at least one long line near the end of
>> >> a diff-mode buffer, then sometimes the buffer gets truncated,
>> >> 'diff-hunk-file-names' returns nil on diff headings,
>> >> and there are a lot of such errors in the Messages buffer:
>> >>
>> >> Error during redisplay: (jit-lock-function 1) signaled (args-out-of-range #<buffer *vc-diff*> 1118 1370)
>> >
>> > We can and should fix this and other problems, but only if they are
>> > reported. Would you please file a bug report for any such problem you
>> > find?
>>
>> This is a new bug report created from bug#56682.
>
> Thanks. Can you post a recipe for reproducing that, preferably
> starting from "emacs -Q"?
0. emacs -Q
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*
And *Redisplay_trace* contains:
Error: args-out-of-range (#<buffer *vc-diff*> 2000 251555)
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x177cfe2073ae86a5>))
debug-early-backtrace()
debug-early(error (args-out-of-range #<buffer *vc-diff*> 2000 251555))
buffer-substring-no-properties(2000 251555)
diff-syntax-fontify-hunk(2000 251555 nil)
diff-syntax-fontify(2000 251555)
#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>(2000 251555)
diff--iterate-hunks(10000 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>)
diff--font-lock-syntax(10000)
font-lock-fontify-keywords-region(1527 10000 nil)
font-lock-default-fontify-region(1527 3027 nil)
font-lock-fontify-region(1527 3027)
#f(compiled-function (fun) #<bytecode -0x156e6c38c061f903>)(font-lock-fontify-region)
run-hook-wrapped(#f(compiled-function (fun) #<bytecode -0x156e6c38c061f903>) font-lock-fontify-region)
jit-lock--run-functions(1527 3027)
jit-lock-fontify-now(1527 3027)
jit-lock-function(1527)
redisplay_internal\ \(C\ function\)()
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-02 17:16 ` Juri Linkov
@ 2023-02-02 20:41 ` Eli Zaretskii
2023-02-03 7:53 ` Juri Linkov
2023-03-30 23:22 ` Gregory Heytings
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-02 20:41 UTC (permalink / raw)
To: Juri Linkov; +Cc: 61215
> From: Juri Linkov <juri@linkov.net>
> Cc: 61215@debbugs.gnu.org
> Date: Thu, 02 Feb 2023 19:16:34 +0200
>
> > Thanks. Can you post a recipe for reproducing that, preferably
> > starting from "emacs -Q"?
>
> 0. emacs -Q
> 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? If so, does the patch below help?
diff --git a/lisp/vc/diff-mode.el b/lisp/vc/diff-mode.el
index eb01ded..9bc742a 100644
--- a/lisp/vc/diff-mode.el
+++ b/lisp/vc/diff-mode.el
@@ -2762,7 +2762,8 @@ 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 (max beg (point-min))
+ (min end (point-max))))
;; 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-02 20:41 ` Eli Zaretskii
@ 2023-02-03 7:53 ` Juri Linkov
2023-02-03 11:59 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2023-02-03 7:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61215
>> 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.
> 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)
font-lock-fontify-keywords-region(1527 10000 nil)
font-lock-default-fontify-region(1527 3027 nil)
font-lock-fontify-region(1527 3027)
#f(compiled-function (fun) #<bytecode -0x156e2446868bfa03>)(font-lock-fontify-region)
run-hook-wrapped(#f(compiled-function (fun) #<bytecode -0x156e2446868bfa03>) font-lock-fontify-region)
jit-lock--run-functions(1527 3027)
jit-lock-fontify-now(1527 3027)
jit-lock-function(1527)
redisplay_internal\ \(C\ function\)()
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-03 7:53 ` Juri Linkov
@ 2023-02-03 11:59 ` Eli Zaretskii
2023-02-05 18:28 ` Juri Linkov
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-03 11:59 UTC (permalink / raw)
To: Juri Linkov; +Cc: 61215
> 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-03 11:59 ` Eli Zaretskii
@ 2023-02-05 18:28 ` Juri Linkov
2023-02-05 18:38 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2023-02-05 18:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61215
> 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))))
Now a new error:
Debugger entered--Lisp error: (error "Unknown diff hunk type")
signal(error ("Unknown diff hunk type"))
error("Unknown diff hunk type")
diff-hunk-text("" t nil)
diff-syntax-fontify-hunk(2000 250992 nil)
diff-syntax-fontify(2000 250992)
#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>(2000 250992)
diff--iterate-hunks(10000 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>)
diff--font-lock-syntax(10000)
font-lock-fontify-keywords-region(1527 10000 nil)
font-lock-default-fontify-region(1527 3027 nil)
font-lock-fontify-region(1527 3027)
#f(compiled-function (fun) #<bytecode -0x156e32bfeabd7fc3>)(font-lock-fontify-region)
run-hook-wrapped(#f(compiled-function (fun) #<bytecode -0x156e32bfeabd7fc3>) font-lock-fontify-region)
jit-lock--run-functions(1527 3027)
jit-lock-fontify-now(1527 3027)
jit-lock-function(1527)
redisplay_internal\ \(C\ function\)()
If you think the problem is in diff-syntax-fontify-hunk,
then I could try to find a working workaround local to diff-mode.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-05 18:28 ` Juri Linkov
@ 2023-02-05 18:38 ` Eli Zaretskii
2023-02-06 17:15 ` Juri Linkov
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-05 18:38 UTC (permalink / raw)
To: Juri Linkov; +Cc: 61215
> From: Juri Linkov <juri@linkov.net>
> Cc: 61215@debbugs.gnu.org
> Date: Sun, 05 Feb 2023 20:28:24 +0200
>
> > 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))))
>
> Now a new error:
>
> Debugger entered--Lisp error: (error "Unknown diff hunk type")
> signal(error ("Unknown diff hunk type"))
> error("Unknown diff hunk type")
> diff-hunk-text("" t nil)
> diff-syntax-fontify-hunk(2000 250992 nil)
> diff-syntax-fontify(2000 250992)
> #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>(2000 250992)
> diff--iterate-hunks(10000 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_39>)
> diff--font-lock-syntax(10000)
> font-lock-fontify-keywords-region(1527 10000 nil)
> font-lock-default-fontify-region(1527 3027 nil)
> font-lock-fontify-region(1527 3027)
> #f(compiled-function (fun) #<bytecode -0x156e32bfeabd7fc3>)(font-lock-fontify-region)
> run-hook-wrapped(#f(compiled-function (fun) #<bytecode -0x156e32bfeabd7fc3>) font-lock-fontify-region)
> jit-lock--run-functions(1527 3027)
> jit-lock-fontify-now(1527 3027)
> jit-lock-function(1527)
> redisplay_internal\ \(C\ function\)()
>
> If you think the problem is in diff-syntax-fontify-hunk,
> then I could try to find a working workaround local to diff-mode.
Yes, now this is something for diff-mode to solve: it shouldn't assume
that it will always be able to go to the beginning and the end of a
hunk, because narrowing could interfere with that. Diff-mode should
have some fallback plan for these cases.
Let me know whether you want me to install the last patch I proposed,
or you will do so as part of fixing all of these issues in diff-mode
together.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-05 18:38 ` Eli Zaretskii
@ 2023-02-06 17:15 ` Juri Linkov
2023-02-06 18:10 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2023-02-06 17:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61215
>> If you think the problem is in diff-syntax-fontify-hunk,
>> then I could try to find a working workaround local to diff-mode.
>
> Yes, now this is something for diff-mode to solve: it shouldn't assume
> that it will always be able to go to the beginning and the end of a
> hunk, because narrowing could interfere with that. Diff-mode should
> have some fallback plan for these cases.
After debugging I discovered that the problem is not caused by font-lock
in diff-mode. The problem is in easy-mmode-define-navigation.
diff-mode uses it to navigate diff hunks. It supports such a feature
that when the user narrowed the diff buffer, it puts narrowing back
after moving to the next hunk. But this fails when the diff buffer
is narrowed automatically by long-line-optimizations. If there is
no way to distinguish whether the narrowing is automatic by long-lines
or manual by the user, this patch fixes the problem. It works without
errors, and even highlights first 250000 characters of the long line:
diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index 5721470ad0d..d9176061434 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -782,7 +782,10 @@ easy-mmode-define-navigation
(when-narrowed
(lambda (body)
(if (null narrowfun) body
- `(let ((was-narrowed (prog1 (buffer-narrowed-p) (widen))))
+ `(let ((was-narrowed
+ (prog1 (unless (long-line-optimizations-p)
+ (buffer-narrowed-p))
+ (widen))))
,body
(when was-narrowed (funcall #',narrowfun)))))))
(unless name (setq name base-name))
^ permalink raw reply related [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
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
0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-06 18:10 UTC (permalink / raw)
To: Juri Linkov, Gregory Heytings; +Cc: 61215
> From: Juri Linkov <juri@linkov.net>
> Cc: 61215@debbugs.gnu.org
> Date: Mon, 06 Feb 2023 19:15:49 +0200
>
> >> If you think the problem is in diff-syntax-fontify-hunk,
> >> then I could try to find a working workaround local to diff-mode.
> >
> > Yes, now this is something for diff-mode to solve: it shouldn't assume
> > that it will always be able to go to the beginning and the end of a
> > hunk, because narrowing could interfere with that. Diff-mode should
> > have some fallback plan for these cases.
>
> After debugging I discovered that the problem is not caused by font-lock
> in diff-mode. The problem is in easy-mmode-define-navigation.
> diff-mode uses it to navigate diff hunks. It supports such a feature
> that when the user narrowed the diff buffer, it puts narrowing back
> after moving to the next hunk. But this fails when the diff buffer
> is narrowed automatically by long-line-optimizations. If there is
> no way to distinguish whether the narrowing is automatic by long-lines
> or manual by the user, this patch fixes the problem. It works without
> errors, and even highlights first 250000 characters of the long line:
Thanks.
Maybe Gregory (CC'ed) can help here and tell whether there's a better
solution.
> diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
> index 5721470ad0d..d9176061434 100644
> --- a/lisp/emacs-lisp/easy-mmode.el
> +++ b/lisp/emacs-lisp/easy-mmode.el
> @@ -782,7 +782,10 @@ easy-mmode-define-navigation
> (when-narrowed
> (lambda (body)
> (if (null narrowfun) body
> - `(let ((was-narrowed (prog1 (buffer-narrowed-p) (widen))))
> + `(let ((was-narrowed
> + (prog1 (unless (long-line-optimizations-p)
> + (buffer-narrowed-p))
> + (widen))))
> ,body
> (when was-narrowed (funcall #',narrowfun)))))))
> (unless name (setq name base-name))
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-06 18:10 ` Eli Zaretskii
@ 2023-02-06 18:11 ` Gregory Heytings
2023-02-27 18:28 ` Juri Linkov
1 sibling, 0 replies; 21+ messages in thread
From: Gregory Heytings @ 2023-02-06 18:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61215, Juri Linkov
>
> Maybe Gregory (CC'ed) can help here and tell whether there's a better
> solution.
>
I'll have a look in a few hours.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
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
1 sibling, 2 replies; 21+ messages in thread
From: Juri Linkov @ 2023-02-27 18:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gregory Heytings, 61215
>> After debugging I discovered that the problem is not caused by font-lock
>> in diff-mode. The problem is in easy-mmode-define-navigation.
>> diff-mode uses it to navigate diff hunks. It supports such a feature
>> that when the user narrowed the diff buffer, it puts narrowing back
>> after moving to the next hunk. But this fails when the diff buffer
>> is narrowed automatically by long-line-optimizations. If there is
>> no way to distinguish whether the narrowing is automatic by long-lines
>> or manual by the user, this patch fixes the problem. It works without
>> errors, and even highlights first 250000 characters of the long line:
>
> Thanks.
>
> Maybe Gregory (CC'ed) can help here and tell whether there's a better
> solution.
It seems there is no better solution?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-27 18:28 ` Juri Linkov
@ 2023-02-27 19:07 ` Eli Zaretskii
2023-02-27 19:23 ` Gregory Heytings
1 sibling, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2023-02-27 19:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: gregory, 61215
> From: Juri Linkov <juri@linkov.net>
> Cc: Gregory Heytings <gregory@heytings.org>, 61215@debbugs.gnu.org
> Date: Mon, 27 Feb 2023 20:28:33 +0200
>
> >> After debugging I discovered that the problem is not caused by font-lock
> >> in diff-mode. The problem is in easy-mmode-define-navigation.
> >> diff-mode uses it to navigate diff hunks. It supports such a feature
> >> that when the user narrowed the diff buffer, it puts narrowing back
> >> after moving to the next hunk. But this fails when the diff buffer
> >> is narrowed automatically by long-line-optimizations. If there is
> >> no way to distinguish whether the narrowing is automatic by long-lines
> >> or manual by the user, this patch fixes the problem. It works without
> >> errors, and even highlights first 250000 characters of the long line:
> >
> > Thanks.
> >
> > Maybe Gregory (CC'ed) can help here and tell whether there's a better
> > solution.
>
> It seems there is no better solution?
I think you should be able to use the new facilities to distinguish
between user narrowing and that due to long-line-optimizations.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
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
1 sibling, 1 reply; 21+ messages in thread
From: Gregory Heytings @ 2023-02-27 19:23 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 61215
>>> After debugging I discovered that the problem is not caused by
>>> font-lock in diff-mode. The problem is in
>>> easy-mmode-define-navigation. diff-mode uses it to navigate diff
>>> hunks. It supports such a feature that when the user narrowed the
>>> diff buffer, it puts narrowing back after moving to the next hunk.
>>> But this fails when the diff buffer is narrowed automatically by
>>> long-line-optimizations. If there is no way to distinguish whether
>>> the narrowing is automatic by long-lines or manual by the user, this
>>> patch fixes the problem. It works without errors, and even highlights
>>> first 250000 characters of the long line:
>>
>> Thanks.
>>
>> Maybe Gregory (CC'ed) can help here and tell whether there's a better
>> solution.
>
> It seems there is no better solution?
>
I still have to look at this, it's on my (short time) TODO list.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-27 19:23 ` Gregory Heytings
@ 2023-02-27 19:25 ` Gregory Heytings
0 siblings, 0 replies; 21+ messages in thread
From: Gregory Heytings @ 2023-02-27 19:25 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 61215
>>>> After debugging I discovered that the problem is not caused by
>>>> font-lock in diff-mode. The problem is in
>>>> easy-mmode-define-navigation. diff-mode uses it to navigate diff
>>>> hunks. It supports such a feature that when the user narrowed the
>>>> diff buffer, it puts narrowing back after moving to the next hunk.
>>>> But this fails when the diff buffer is narrowed automatically by
>>>> long-line-optimizations. If there is no way to distinguish whether
>>>> the narrowing is automatic by long-lines or manual by the user, this
>>>> patch fixes the problem. It works without errors, and even
>>>> highlights first 250000 characters of the long line:
>>>
>>> Thanks.
>>>
>>> Maybe Gregory (CC'ed) can help here and tell whether there's a better
>>> solution.
>>
>> It seems there is no better solution?
>
> I still have to look at this, it's on my (short time) TODO list.
>
I meant "short term", of course.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-02-02 17:16 ` Juri Linkov
2023-02-02 20:41 ` Eli Zaretskii
@ 2023-03-30 23:22 ` Gregory Heytings
2023-03-31 7:10 ` Juri Linkov
1 sibling, 1 reply; 21+ messages in thread
From: Gregory Heytings @ 2023-03-30 23:22 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 61215
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
>
> 0. emacs -Q
> 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*
>
Sorry for the (very!) late reply.
I tried to reproduce that issue with Emacs 29 (at 59f66ea302). I used the
"a.xml" file from bug#61514, which can be recreated with the following
short Python script:
#!/usr/bin/python3
f = open("a.xml", "w")
f.write('<id name="')
for n in range(1, 4096):
f.write("n" * 1024)
f.write('">\n')
I did, in the Emacs repository:
echo README >> README
echo CONTRIBUTE >> CONTRIBUTE
echo INSTALL >> INSTALL
git add a.xml
git commit -a -m commit
./src/emacs -Q --eval '(setq debug-on-error t backtrace-on-redisplay-error t)'
C-x v l
d
At that point there are no errors, and the a.xml hunk is correctly
fontified. Now if I do:
q
d
then the errors you mention above appear (and the a.xml hunk is not
correctly fontified anymore). If I manually kill the *vc-diff* buffer,
they disappear again. Is this also what you see?
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-03-30 23:22 ` Gregory Heytings
@ 2023-03-31 7:10 ` Juri Linkov
2023-03-31 7:30 ` Juri Linkov
2023-03-31 7:40 ` Gregory Heytings
0 siblings, 2 replies; 21+ messages in thread
From: Juri Linkov @ 2023-03-31 7:10 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, 61215
>> 1. (setq debug-on-error t backtrace-on-redisplay-error 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*
>
> I did, in the Emacs repository:
>
> echo README >> README
> echo CONTRIBUTE >> CONTRIBUTE
> echo INSTALL >> INSTALL
Actually, these files can't expose the problem.
I suggest to use a mode with complex font-lock rules
for syntax highlighting. I tested with a few of 1-char edits
in a few places inside an .el file.
> git add a.xml
The diff will output the file name a.xml at the beginning, but
better to output it after the file with changes. The complete
diff output should look like this: first a few diff hunks
each with 1-line change from an .el file with syntax fontification.
Then at the end of the screen the huge file added in the same commit.
> git commit -a -m commit
> ./src/emacs -Q --eval '(setq debug-on-error t backtrace-on-redisplay-error t)'
> C-x v l
> d
Not sure if this shows diffs only from one file.
More reliable would be to use 'C-x v L d'
to show a multi-file commit.
> At that point there are no errors, and the a.xml hunk is correctly
> fontified. Now if I do:
>
> q
> d
>
> then the errors you mention above appear (and the a.xml hunk is not
> correctly fontified anymore). If I manually kill the *vc-diff* buffer,
> they disappear again. Is this also what you see?
Hmm, I tried again, and can't reproduce it in emacs-29.
But in master there are still the same errors.
How this is possible when emacs-29 is merged to master?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-03-31 7:10 ` Juri Linkov
@ 2023-03-31 7:30 ` Juri Linkov
2023-04-01 0:22 ` Gregory Heytings
2023-03-31 7:40 ` Gregory Heytings
1 sibling, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2023-03-31 7:30 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, 61215
>>> 1. (setq debug-on-error t backtrace-on-redisplay-error 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*
>>
>> I did, in the Emacs repository:
>>
>> echo README >> README
>> echo CONTRIBUTE >> CONTRIBUTE
>> echo INSTALL >> INSTALL
>
> Actually, these files can't expose the problem.
> I suggest to use a mode with complex font-lock rules
> for syntax highlighting. I tested with a few of 1-char edits
> in a few places inside an .el file.
>
>> git add a.xml
>
> The diff will output the file name a.xml at the beginning, but
> better to output it after the file with changes. The complete
> diff output should look like this: first a few diff hunks
> each with 1-line change from an .el file with syntax fontification.
> Then at the end of the screen the huge file added in the same commit.
>
>> git commit -a -m commit
>> ./src/emacs -Q --eval '(setq debug-on-error t backtrace-on-redisplay-error t)'
>> C-x v l
>> d
>
> Not sure if this shows diffs only from one file.
> More reliable would be to use 'C-x v L d'
> to show a multi-file commit.
>
>> At that point there are no errors, and the a.xml hunk is correctly
>> fontified. Now if I do:
>>
>> q
>> d
>>
>> then the errors you mention above appear (and the a.xml hunk is not
>> correctly fontified anymore). If I manually kill the *vc-diff* buffer,
>> they disappear again. Is this also what you see?
>
> Hmm, I tried again, and can't reproduce it in emacs-29.
> But in master there are still the same errors.
> How this is possible when emacs-29 is merged to master?
After boostrap errors appear in emacs-29 too.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-03-31 7:30 ` Juri Linkov
@ 2023-04-01 0:22 ` Gregory Heytings
2023-04-01 18:19 ` Juri Linkov
0 siblings, 1 reply; 21+ messages in thread
From: Gregory Heytings @ 2023-04-01 0:22 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 61215
I just spent a couple of hours on this bug, and so far the only thing I
can say for sure is that alas the patch you suggested does not work
reliably: at least with the recipe I posted upthread the bug is still
present. I don't yet know how to actually fix it, though :(
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-04-01 0:22 ` Gregory Heytings
@ 2023-04-01 18:19 ` Juri Linkov
0 siblings, 0 replies; 21+ messages in thread
From: Juri Linkov @ 2023-04-01 18:19 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, 61215
> I just spent a couple of hours on this bug, and so far the only thing I can
> say for sure is that alas the patch you suggested does not work reliably:
> at least with the recipe I posted upthread the bug is still present.
> I don't yet know how to actually fix it, though :(
Did you do a full bootstrap after applying the patch?
It changes the macro, so at least diff-mode.el (that uses
this macro) needs to be recompiled afterwards.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#61215: 29.0.60; font-lock broken in diff-mode with long lines
2023-03-31 7:10 ` Juri Linkov
2023-03-31 7:30 ` Juri Linkov
@ 2023-03-31 7:40 ` Gregory Heytings
1 sibling, 0 replies; 21+ messages in thread
From: Gregory Heytings @ 2023-03-31 7:40 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, 61215
>
> Actually, these files can't expose the problem. I suggest to use a mode
> with complex font-lock rules for syntax highlighting. I tested with a
> few of 1-char edits in a few places inside an .el file.
>
Okay, so I tried again with:
sed -i 's/(signal /(signal /' lisp/subr.el lisp/simple.el
(Note the two spaces after "signal".)
>> git add a.xml
>
> The diff will output the file name a.xml at the beginning, but better to
> output it after the file with changes. The complete diff output should
> look like this: first a few diff hunks each with 1-line change from an
> .el file with syntax fontification. Then at the end of the screen the
> huge file added in the same commit.
>
With my previous recipe the added file was added at the end, but for some
reason after the command above it does not. I renamed the a.xml file into
z.xml, and now it does again.
>> git commit -a -m commit
>> ./src/emacs -Q --eval '(setq debug-on-error t backtrace-on-redisplay-error t)'
>> C-x v l
>> d
>
> Not sure if this shows diffs only from one file. More reliable would be
> to use 'C-x v L d' to show a multi-file commit.
>
Okay, with the modifications you indicated above, I can now reproduce the
bug, with both C-x v l d and C-x v L RET d.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2023-04-01 18:19 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).