bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#60427: Emacs-29, c++-ts-mode: typing "char" into an empty buffer cau


From: Yuan Fu
Subject: bug#60427: Emacs-29, c++-ts-mode: typing "char" into an empty buffer causes an exception in redisplay.
Date: Fri, 30 Dec 2022 17:02:36 -0800


> On Dec 30, 2022, at 4:24 AM, Alan Mackenzie <acm@muc.de> wrote:
> 
> Hello, Emacs.
> 
> In the emacs-29 branch, with the latest commit being:
> 
> commit 558b59d81b938fc434e62523106360b9704c88e2 (HEAD -> emacs-29, 
> origin/emacs-29, origin/HEAD)
> Author: Yuan Fu <casouri@gmail.com>
> Date:   Thu Dec 29 11:52:06 2022 -0800
> 
>    Add color fontification in css-ts-mode (bug#60405)
> 
> :
> (i) emacs -Q
> (ii) (setq backtrace-on-redisplay-error t)
> (iii) C-x b string.cc <RET>
> (iv) M-x c++-ts-mode <RET>
> (v) Type "char" (without the quote marks).
> 
> This throws an exception in the redisplay code.  The backtrace in the
> *Redisplay-trace* buffer is:
> 
> Error: treesit-query-error ("Node type error at" 195 "Debug the query with 
> `treesit-query-validate'")
>  debug-early-backtrace()
>  debug-early(error (treesit-query-error "Node type error at" 195 "Debug the 
> query with `treesit-query-validate'"))
>  treesit-font-lock-fontify-region(1 5 nil)
>  font-lock-default-fontify-region(1 5 nil)
>  font-lock-fontify-region(1 5)
>  #f(compiled-function (fun) #<bytecode 
> -0x156ee3e72a1d5e83>)(font-lock-fontify-region)
>  jit-lock--run-functions(1 5)
>  jit-lock-fontify-now(1 5)
>  jit-lock-function(1)
>  redisplay_internal\ \(C\ function\)()
> 
> ..  That this insertion causes an exception is clearly a bug.
> 
> But the contents of the backtrace seem to me to be less helpful than they
> might be.  What does the "the" in "the query" refer to?  There is no
> referent yet established.  What does the 195 refer to?  It clearly isn't
> a buffer position, which is what it would mean in lots of other Emacs
> error messages.
> 
> Just as a matter of interest, in c-ts-mode, the above actions run without
> problem.

Thank you! I couldn’t reproduce it on the latest trunk, even though I checked 
that there isn’t any relevant change between that commit and the latest one. I 
made a small modification to treesit.c so now the signal will contain the 
source of the query that caused the error. Could you try again with trunk and 
show me the backtrace? This time it should contain the problematic query.

Yuan




reply via email to

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