From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#74386: Tree-sitter javascript indentation Date: Thu, 12 Dec 2024 21:34:29 -0800 Message-ID: <057D3C98-8503-4C6F-80F1-B54BAFE624BF@gmail.com> References: <2ce8c98e-c399-46f1-a930-04f27a3d56dd@gutov.dev> <389b6090-6ae9-433a-85cc-a2d2eb84751f@gutov.dev> <86r06t82gl.fsf@gnu.org> <4B4B99E7-C4A1-4124-BC85-2AD66EF0871B@gmail.com> <35B61F44-C551-44DB-A334-A893991BC799@gmail.com> <8A7428E6-50EE-4783-82FF-3A62C4756C56@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) 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="2765"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74386@debbugs.gnu.org, Eli Zaretskii , Theodor Thornhill , marius.kjeldahl@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 13 06:37:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tLyMc-0000YN-C4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Dec 2024 06:37:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLyMK-0002E5-Q4; Fri, 13 Dec 2024 00:37:04 -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 1tLyMJ-0002Da-2S for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 00:37:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLyMI-0006gq-Qd for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 00:37:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:Date:In-Reply-To:From:Mime-Version:To:Subject; bh=BBLCEKd6zv4urA9VNb1Lt2TDCoIyu4v26ReFfy2EjUU=; b=qYSpWv4dGpXRWLvhQCxQ3HJeW3UBum3PcAJO7gWNKYYVwu4+yQINsmSBXlh7sbogiOY1Onf2dxFRkE1BZ6AHL+iDFzB79cjYxKDfeK6GlodXn3BVt723tyu7QaI7yKh6OLgMHP17CmHpNwn27gkLG61CBJ/ECInEZOUO/d9em62oCAV8HwRgcPRDHKQ+fGLb9pVjpFHPsO+AhhOopxyk2KxNJa87qF/flsC5qOF4X2FafrpFjYI+Bt8RI59UVk02LcBUOcvIylPssuiwkS8L8UMbBtLfmBvim15Brry68UIra5pDCsMzWsMZkWOeEdI9YO+BZ1tmALuorx4B7rawiw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tLyMI-00009e-Cd for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 00:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Dec 2024 05:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74386 X-GNU-PR-Package: emacs Original-Received: via spool by 74386-submit@debbugs.gnu.org id=B74386.1734068171510 (code B ref 74386); Fri, 13 Dec 2024 05:37:02 +0000 Original-Received: (at 74386) by debbugs.gnu.org; 13 Dec 2024 05:36:11 +0000 Original-Received: from localhost ([127.0.0.1]:41250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLyLR-000086-JK for submit@debbugs.gnu.org; Fri, 13 Dec 2024 00:36:11 -0500 Original-Received: from mail-pf1-f182.google.com ([209.85.210.182]:49399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLyL5-00006z-D7 for 74386@debbugs.gnu.org; Fri, 13 Dec 2024 00:36:08 -0500 Original-Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-728e1799d95so1596535b3a.2 for <74386@debbugs.gnu.org>; Thu, 12 Dec 2024 21:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734068081; x=1734672881; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BBLCEKd6zv4urA9VNb1Lt2TDCoIyu4v26ReFfy2EjUU=; b=P1+C4SQpu6LWFPoQfstWCUBpSuiPqE7VzklLiYgboBfd1OKrj0nplJSAcdIkT1Eq4p G8ITENq9vB0pGNPX8p+4/B2Yqq9ww4hv0HF5QlLFQI9rx6n0ta0uT8JPI5Kwqta28BCq 2tnEiT9tVfB+UrKVqfEjSQdPhgtqnQh4JS7WtWzDsZpNQ63A12tzRf29DUz5lu3RooEP /PDKoiiNEcP3TfUonHMe1XB7XGlLjpKQnfRCR+daSoxTT4KzsZv657pfs2SLdb/0z7hm jCpurfBnd/G+34kDmlNORLt6GfcT8F7Nt6EvbPIIfqRP1GDZtHKBz7QKvdsPycLz1QR4 7fvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734068081; x=1734672881; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BBLCEKd6zv4urA9VNb1Lt2TDCoIyu4v26ReFfy2EjUU=; b=Rs9qrUbZkzaXwR/PdfWAWUOQf+GUvQw9nfig+ThbAs+9c0lfosQhGLvrZbJSVYSNq7 hY4/L4TVR556p3s3QlEu7Aoym5Xpd/HMRaDMtfgiaJ1hVFalPVIkEW/VPa7z4JsIZeNL smmDK8SQJ+ZaMEYiy0Tycuxy7V6GpcR9LGXLdqjIACI8XKDLP7zPs4aW/vzVKxYBH8Zx 0gEgv/hX+LEstDBUphIduAceOBvJiHEbx9pwmAtCcmwQe6yOnfVxUECbTc0vv9hmTjJa ItEPv3rMJL5UgrFd1DkZ42OLlROL2phIQFNrZnXgQwd/0Fcy8W6zhxQWnYCv6U4VVGlc Wvcw== X-Forwarded-Encrypted: i=1; AJvYcCUdFirBBpQYlLk2+whuXHl5atEEPMi1ZBxPfZ2yC41SJsE+2TJTcPtgWMu2QM4iHd/hqCgVYw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzgWvgfE9gG6JDBE9zlDjzeU3EutjxB8fheSC0xrFGYt7+PRfqu czboa4cV4bFM14szCPMgJ9mMoDgEen0gWTPDcA6X38uICI+lQjhI X-Gm-Gg: ASbGncs9pUnAK1/ERnHh+4+gYrl2Mb9Oc0tYhJQX5BuenQAGTezeqoo/47M5MP79+ni wQ1NvBWqgf5p13AEEhWQo8hdAh7GuAkqol73kG0gtNvb0rJvfm1lKAjVJFnkn+AnNdTJw7RzEkS xh0WZ9V1rctBD25QuZhP8gPXuFusDWVstgKdpkJBDlEiMyPSfPD/ND8YBmVj87ecB/Qv2seOw/d 9N4I0by5H9jmHwocT2+6X7+pik09Cc1AOmg5+n83Fihl5PvNb0OJl0urXYCwZrhYyndNxL2su13 4h7x X-Google-Smtp-Source: AGHT+IHtCtWUEQ8GUkzFnfxQOs9BJE3A8zf2qLnb9A6Q6y++KJIYvCYO8PuneVdQbdX1sLZ+CAOrwQ== X-Received: by 2002:a05:6a21:2d8c:b0:1db:e40d:5f89 with SMTP id adf61e73a8af0-1e1dfde7031mr1989097637.28.1734068081392; Thu, 12 Dec 2024 21:34:41 -0800 (PST) Original-Received: from smtpclient.apple ([2601:646:8f81:6120:1591:1a19:416c:1925]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-725d36e66e1sm10349455b3a.178.2024.12.12.21.34.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2024 21:34:40 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3776.700.51) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296956 Archived-At: > On Dec 12, 2024, at 7:34=E2=80=AFPM, Dmitry Gutov = wrote: >=20 > On 12/12/2024 07:28, Yuan Fu wrote: >=20 >>> What would be our next step in this? Replacing all 'parent-bol' = anchors with 'standalone-parent' across most ts modes? >> Speaking of next step, I recently added another handy tool for = languages with C-like syntax: c-ts-common-baseline-indent-rule. I = figured out an indent logic that can work on all C-like languages and = covers a wide range of cases. This one rule can give you all theses = indentation: >=20 > Looks pretty great. I guess it depends on the grammars being to an = extent compatible, right? Yes, but most C-like language should be compatible. The rule relies on = the grammar to put brackets like =E2=80=9C(=E2=80=9C =E2=80=9C[=E2=80=9C = =E2=80=9C{=E2=80=9C as the first child node and last child node of the = contract that contains them, which is what grammars naturally do. (The = only exception I found is the for statement in C.) Beyond that, the rule = takes advantage of how parse tress are usually structured: when the = previous line is a sibling node of the current lines, usually you want = to align the two lines; and when you indent, the indent anchor is = usually the "standalone-parent=E2=80=9D.=20 >=20 >> 1. Statements align to their previous sibling: >> int main() { >> int a =3D 1; >> int b =3D 2; <-- Align to prev line=E2=80=99s sibling. >> } >> 2. Indents one level for blocks: function, if, for, struct, etc. >> int main() { >> return 0; <-- Indent one level. >> { <-- Align to prev line=E2=80=99s sibling. >> return 1; <-- Indent one level. >> } >> } >> 3. Elements in parenthesis and brackets: >> return [1, 2, 3, >> 4, 5, 6]; <-- Align to first sibling. >> return [ >> 1, 2, 3, <-- Indent one level (option 1). >> 4, 5, 6, <-- Align to prev line=E2=80=99s sibling. >> ]; >> return [ >> 1, 2, 3, <-- Align to opening bracket (option 2). >> 4, 5, 6, <-- Align to prev line=E2=80=99s sibling. >> ]; <-- Align to opening bracket. >> for (int i =3D 0; >> i < 10; <-- Align to first sibling. >> i++) { <-- Align to prev line=E2=80=99s sibling. >> continue; >> } >> 4. Statement expressions indent one level when it=E2=80=99s broken = into two >> lines: >> int main() { >> int var >> =3D 1287; <-- Indent one level. >> int var =3D >> 1287; <-- Indent one level. >> } >=20 > Should there be an example with a method call starting on a new line, = line in the arrow literal example (for JS) that we discussed? Yes, once we add that. >=20 >> Then a C-like language=E2=80=99s major mode only need to add special = cases over the baseline indent rule. And if we add the configurable = heuristic for standalone-parent, the baseline indent rules would make = use of it. >=20 > Sounds good. >=20 >> I brought it up because if we=E2=80=99re going to do some renovations = to indent rules, might as well make use of = c-ts-common-baseline-indent-rule, and we probably don=E2=80=99t even = need to replace parent-box with standalone-parent, because the baseline = indent rule would cover most cases. >=20 > I'm now sure how safe that is - my point was that for each of the = languages it'd be great to have somebody motivated go over the main = syntactic cases and see that the behavior is still reasonable. But we = can also make the switch and wait for reports. I agree, sweeping change in unfamiliar packages maintained by other = people is obviously a no-go. I=E2=80=99m thinking of the maintainers = making the change should they see the baseline-indent-rule beneficial. = (Same goes to standalone-parent, I=E2=80=99d much rather the maintainers = take that call even it=E2=80=99s a smaller change.) For immediate next step we can just apply the standalone-parent patch, = and use it in js. And we make baseline-indent rule support the = standalone-parent customization, and let major mode maintainers know of = both. What they want to do is up to them. >=20 >> I=E2=80=99ve already used it to rewrite c-ts-mode indent rules and = it=E2=80=99s been a success; this baseline + override approach has been = very helpful. c-ts-mode still has a lot of indent rules because of = things like preproc directive, etc, but it=E2=80=99s much more = manageable than before. >> I don=E2=80=99t know how much it would help modes that has simpler = indent rules. Go-ts-mode and rust-ts-mode only has a handful of indent = rules, maybe they don=E2=80=99t really need this baseline rule. OTOH Lua = and Ruby has more involved indent rules, maybe they can benefit and = reduce the number of rules they need to define. >=20 > Ruby has different delimiters (do...end or def...end or etc), and the = curlies don't do exactly the same job that they do in C. So I'm not sure = how feasible it is. A half of the function would be a fit, though. Right, so I think it=E2=80=99ll still be more helpful than not. Yuan=