From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Filippo Argiolas Newsgroups: gmane.emacs.devel Subject: Re: How does c-ts-mode, tree-sitter indentation, and preprocessor directives work? Date: Thu, 28 Nov 2024 19:30:52 +0100 Message-ID: References: <86plmferwu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30514"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , =?utf-8?Q?Bj=C3=B6rn?= Lindqvist , Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 28 19:31:53 2024 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 1tGjIv-0007la-CV for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Nov 2024 19:31:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGjI7-0004Ev-6u; Thu, 28 Nov 2024 13:31:03 -0500 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 1tGjI4-0004DC-Fe for emacs-devel@gnu.org; Thu, 28 Nov 2024 13:31:00 -0500 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tGjI2-0000g8-S5; Thu, 28 Nov 2024 13:31:00 -0500 Original-Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-434a0fd9778so10121775e9.0; Thu, 28 Nov 2024 10:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732818656; x=1733423456; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=xnDiCA4l783VH+JtOPgRSiUV48tJa2h+WvrqWWCHveA=; b=Qsy3jNC0jCR6C4shRI0JdRGJKEz6d8YPAkSQ7JLZbn+DtjmKQWm1NrC43S+ds3lOv5 AMtDHAvZgaC6MQluAxBKPBynh4sSO8Hd0wwc5I5tJg/CkT/2T5UIDti2mN2Xx9RtuUbj 6IdY+Oy0O60T4z0M2gENbALXSfwFnrYE1Fq9QJ5ZBUKQa/b1dReJdkKAL8CIHwfLC3uG xDQQmEMstghMBzcplEZ9adqzndaJUXlyGx1MHitakFpNojk7Qq3K4bGau/Ol6Bls/Vvl wQ4GxcVcpOtK3h/lqTg/paYh7oZ3wXStUJDDQt3rdPPgJJ6zFrNw+s+UI+a4LCSBP+QW aG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732818656; x=1733423456; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xnDiCA4l783VH+JtOPgRSiUV48tJa2h+WvrqWWCHveA=; b=YKakcGgVL25jht2/clF7EE7XrYnCBFjxQNQYhbTm+hPOC1hTRfi5+Tru4nrtgUgTMu DasMoemkb185dT3nfzvWjsCajLFPHYAPM5q5OBUfP+rH3y30EDG7WWuylIwBPYEK9nRq E4NY3QjH8TPNkJEbLI4OY5bq3PsmE2yXEN9RurJJZyhYju799yYC+tlaMZjU90ybfuXq FwXW3qf/OKl/fAHJiqAKEOG2ZeE+pPhXRLaR9COdbwvKcjG3uaT8TKzb3/p9JQYisOkM N2AAwbiEKMiCP5R5BAfDZfjHMEpgqWgiU4RmzRujK940ixk8nd92ju0HwWfQRHB8Zi5Q 6Kow== X-Gm-Message-State: AOJu0Yz4+3UwH17HzCYzAinZqE7teqZlseDRTDqwcQpmTk2Izy4cJpjx XknMwmv9xiTYULh36RvUszLHZ4Zr52GbslLddVroaaVkIkFysA7/9+keQvYJ X-Gm-Gg: ASbGncuXfBmL7WYWr3XW3sY6DLIw1veelca1pRmMGsSfnaOlACD90zC7szHOYWuo5Kn G5HzTadgBWjBJA/UwT7oXwXJsSBJ/zKe/ICzzxiIwN3Mnv+Md0kpHcBx4FjH0NZnBvrvJLyl6AJ v99+R3bzEXGAJgcWce7iZAkGPmUB+sLXH+/JbQ5bus94edGUmkN91MXv69hnZxICqyinVPcCbVj g14mY1oWZJZYjAQNd9bjBiTBb/Smu3d6/junZIBv37DsOekhwCityqTcow= X-Google-Smtp-Source: AGHT+IHxOwWWDJDyc4HqW67z8hsG0cRxzduwSpKrL0fPn1wcFiaR5s00yP2iYQV39aCkogNseej2+A== X-Received: by 2002:a05:600c:5489:b0:434:a1d3:a306 with SMTP id 5b1f17b1804b1-434a9dbbd25mr71984685e9.5.1732818655500; Thu, 28 Nov 2024 10:30:55 -0800 (PST) Original-Received: from mba ([151.81.191.240]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434b0f32589sm29724855e9.28.2024.11.28.10.30.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Nov 2024 10:30:54 -0800 (PST) In-Reply-To: <86plmferwu.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=filippo.argiolas@gmail.com; helo=mail-wm1-x334.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:325828 Archived-At: Eli Zaretskii writes: >> From: Bj=C3=B6rn Lindqvist >> Date: Thu, 28 Nov 2024 00:27:17 +0100 >>=20 >> I've been trying to get c-ts-mode to indent like I want, but I'm >> running into problems related to preprocessor directives. > > Preprocessor directives are difficult because the tree-sitter C/C++ > grammars include only partial support for them. > >> For >> example, consider a type definition nested in two #ifdefs: >>=20 >> #ifdef X >> #ifdef Y >> typedef int foo; >> #endif >> #endif >>=20 >> Since both the parent and grand parent of the type_definition is a >> preproc_ifdef no rule matches. > > But if you go back (up) the parent-child hierarchy, you will > eventually find a node which is not a preproc_SOMETHING, and can go > from there, no? > I believe we might have a bug here, as far as I can tell it does not match ((n-p-gp nil "preproc" "translation_unit") column-0 0) Because both parent and grand parent are preproc. So it matches one of the `c-ts-mode--standalone-parent-skip-preproc' rules right after. After skipping preproc nodes parent is translation_unit and indents an offs= et from there. Guess this step could be made smarter to check for translation_unit and the rule above could be removed? >> Another issue is that I want my >> preprocessor directives kept at column 0, which unfortunately screws >> up all rules that refer to the parent. E.g.: >>=20 >> ((parent-is "if_statement") standalone-parent 4) >>=20 >> Doesn't work for >>=20 >> int main() { >> if (true) >> #ifdef A >> prutt(); >> #else >> fis(); >> #endif >> } >>=20 >> The rule I'd like to express is "take the indent of the closest >> *indenting* parent and add one indent". That rule would match whether >> that parent is a "while_statement", "if_statement", "for_statement", >> etc. You can't express such rules with tree-sitter, can you? > > Not sure, but Yuan will know. This can be worked around as Yuan showed, but isn't it a grammar bug? problem is with the #ifdef function and if statement become siblings, witho= ut preproc they have a child-parent relation. In my experience c-ts-mode is a bit fragile with preprocessor statements, probably because the grammar itself is fragile (see e.g. [1]) and the problem is an hard one. Yuan, do you think c-ts-mode could some way benefit from LSP knowledge about inactive preprocessor branches? Idea is that we would at least have a good syntax tree in the active branches while allowing some errors in the inactive ones. Filippo 1. https://github.com/tree-sitter/tree-sitter-c/issues/108