[Top][All Lists]

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

Re: c-ts-mode

From: Eli Zaretskii
Subject: Re: c-ts-mode
Date: Thu, 07 Sep 2023 20:10:09 +0300

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 7 Sep 2023 16:58:29 +0100
> Cc: casouri@gmail.com, spacibba@aol.com, emacs-devel@gnu.org
> On Thu, Sep 7, 2023 at 10:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > Some of the styles are already supported.  The rest should also be
> > possible (at least most of them), but someone will have to write the
> > code.  It is not a simple matter of "importing", since CC Mode
> > implements these features based on infrastructure that either doesn't
> > exist or makes no sense in treesit-supported modes.
> Thanks for clarifying.  My current cc-mode user style is very
> simple (I think) it inherits from the 'gnu' style and adds
> minimal things.
> (c-add-style "user"
>              '("gnu"
>                (c-special-indent-hook)
>                (c-offsets-alist
>                 (substatement-open . 0)
>                 (namespace-open . -2)
>                 (innamespace . -2)
>                 (extern-lang-open . -2)
>                 (inextern-lang . -2))))
> Basically I'd just like to keep code inside top-level
> C++ namespaces and extern blocks unindented.
> As to substatement-open I don't even know what
> the purpose is anymore.
> I see that c++-ts-mode already has a gnu user style, so
> I would just need to add my preferences.  Is there a manual
> entry somewhere for learning how to do this?

I think c-ts-mode--indent-styles needs to be refactored toallow fine
control on the indentation parameters that are currently hard-coded
for each supported style.  They will need to have different names,
because tree-sitter doesn't use the CC Mode terminology for the
syntactical constructs.  Also, there seem to be many more parameters
than in CC Mode.

> Also, if I may go on a tangent:  Is the forward-sexp-function
> for c++-ts-mode currently undergoing work on master?  It
> doesn't seem to work and all C-M-foo navigation is broken as
> a result.
> Debugger entered--Lisp error: (treesit-invalid-predicate nil)
>   treesit-node-match-p(#<treesit-node ";" in 41-42> sexp t)
>   #f(compiled-function (node) #<bytecode
> 0x197a9d284470c5e2>)(#<treesit-node ";" in 41-42>)
>   treesit-node-top-level(#<treesit-node ";" in 41-42>
> #f(compiled-function (node) #<bytecode 0x197a9d284470c5e2>) t)
>   treesit--things-around(47 sexp)
>   treesit--navigate-thing(47 1 end sexp restricted)
>   treesit-end-of-thing(sexp 1 restricted)
>   treesit-forward-sexp(1)

First, please submit a bug report about this with all the details.

And second, I don't seem to be able to reproduce this, assuming that
by C-M-foo you meant C-M-f and C-M-b.  Maybe this needs some
particular source file to reproduce?  (I tried with one C file and one
C++ file.)

> Setting the variable to nil brings me to more familar
> and satisfactory terrain where, and I suppose the non-treesit
> syntax table is being used for that.  Is there any big
> advantage in switching to treesitter's forward-sexp-function?

Yes, see treesit-defun-tactic.

reply via email to

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