From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: c-ts-mode Date: Thu, 07 Sep 2023 20:10:09 +0300 Message-ID: <83y1hhykni.fsf@gnu.org> References: <5F73CB5D-DB00-439F-AD7C-7E209EC83A35@gmail.com> <83jzt2z5mk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21913"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, spacibba@aol.com, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 07 19:10:55 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qeIWs-0005UY-Hm for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Sep 2023 19:10:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeIWO-0003RV-3Y; Thu, 07 Sep 2023 13:10:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeIWM-0003RN-FS for emacs-devel@gnu.org; Thu, 07 Sep 2023 13:10:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeIWM-0003jc-5y; Thu, 07 Sep 2023 13:10:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=smagWQSIdU8sXGve8uLTk/Nu36wz+GWqJQ+1Ab3xMrs=; b=VSFAq3s8zBlZlUmoVSH2 2Y4Luhh5lVWqGnObaZHpqrgNOVZ7mTcwAuQ5zGSD5WFBlfPqFsj5qjkCzl7YlGTuHaQn0nfWihmgK xO5ZJUkRHCmmCIGKtW14jloR7Xp3aoE+RDQN6tmMEdrPSwWpKXxsEiFoMn7KeBDPRlYs+DYTCnSC/ 6YnXdupv6a7ozlIXL/8AVIbnG/r+1Z64VsZ+p+9i+43mdzcwliga2SpvVp3OQbIeCIFMgp4c4eM9f 5SCLGQtyuYLBv/CvyjVbSpAY0zUBZnE93OsmtTqzZijXMyrUKnuacz9j2y6TmxQ6AVRptRTFwqaIJ 123/7H0g3RU5ug==; In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 7 Sep 2023 16:58:29 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310270 Archived-At: > From: João Távora > 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 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(# sexp t) > #f(compiled-function (node) # 0x197a9d284470c5e2>)(#) > treesit-node-top-level(# > #f(compiled-function (node) #) 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.