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.devel Subject: Re: Remove js--treesit-backward-up-list or fix it Date: Sat, 29 Oct 2022 12:07:19 -0700 Message-ID: <092C50FE-FCA3-43A2-B296-A3D61C88F2E3@gmail.com> References: <8B978AF7-B1CA-4C8A-9E89-84D0DEC7884C@gmail.com> <87h6znxkr0.fsf@thornhill.no> <0849BE6B-B5B4-47E0-B4EA-F93F6947C2B7@gmail.com> <87h6zmscqj.fsf@thornhill.no> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) 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="4124"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 29 21:08:06 2022 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 1oorBe-0000pW-5Y for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Oct 2022 21:08:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oorB0-0005Hm-A6; Sat, 29 Oct 2022 15:07:26 -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 1oorAy-0005BV-HZ for emacs-devel@gnu.org; Sat, 29 Oct 2022 15:07:24 -0400 Original-Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oorAx-0007pt-08 for emacs-devel@gnu.org; Sat, 29 Oct 2022 15:07:24 -0400 Original-Received: by mail-pl1-x629.google.com with SMTP id c2so7542906plz.11 for ; Sat, 29 Oct 2022 12:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=4Mf6JhxXvYVd8qFugQoWvQ9s5wYa0g+mUYGMhHiJekM=; b=bxf8n02Ja4hV6unfTRuqXsMi04yFSwIn1Fjrs21X//HTGKt35t7vgZZpR2mKy3d3pm +ly+C/EuQateu6VEVPIXFMKLyr2Uz/9bXzJbCenjUWdqvuoXNG+0n3dKLW8OPdI5hx9X d0sA8+5FMfVZBw4LfhZb45Clq8pceNIYKzGdgiU395DILINP25HAe0DW1aohTjH0RDzn UvgQ2LbUVLdxZk8M+vIT7UuPAI9e/EtElD/ZCZTN/cCvR7YeNqcQmNq99TCMXOFSVSd9 nOqUhW2RXOQVnbtDBwobJYNzTluvY1Aa0QB1M2srOMiyh+I48NEoFmx8ouNgoGdjr5Aw MQdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=4Mf6JhxXvYVd8qFugQoWvQ9s5wYa0g+mUYGMhHiJekM=; b=6yJU5iGZ9iOpm/awJ3EcyWFXL9lWDq5njNauPcBXnWyU7UKFP2A0KZNgqyKZfBknEq OQyal4vJnmnypz6Ua7kDeK7bCG5sEjwo6M0q0m0R622WHPwGXVB6le/XUZKujZzOxX0e AsV33AfVQU0ygaLkbp8bvtHDYJEHJHzs7+fajMraR/4PduYdPmy6JGhNE2PNaR7q9S2F y0watIA9rnrMNJ2n5/sKm6EPBxJ7gjsQlAWhDJsRAQiL7PvZdPwXfcKh5miaR6jM1DkB AAEay44BWRuDZVuq2UX/ostwiB1nt48seM+pBYSiAYWcHllTRaSEbc2/JmKKUpfYFD4r aSgg== X-Gm-Message-State: ACrzQf2+Fgbp4hku1C5+ND+/K/dYSxR4ELh4WBUG0o3dpCANFTTFzRai /12kG494C/H7HrIn3wwWegs= X-Google-Smtp-Source: AMsMyM5PoVaNsjwxFNyBKcdGmLVvw2UyEHW1BS0p4Heh0LULuha8rvBkoEmFzzcLHgsqGCoK6MorEg== X-Received: by 2002:a17:902:ce0f:b0:187:640:42f with SMTP id k15-20020a170902ce0f00b001870640042fmr4344254plg.115.1667070441395; Sat, 29 Oct 2022 12:07:21 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id w145-20020a627b97000000b005632f6490aasm1509570pfc.77.2022.10.29.12.07.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2022 12:07:21 -0700 (PDT) In-Reply-To: <87h6zmscqj.fsf@thornhill.no> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=casouri@gmail.com; helo=mail-pl1-x629.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: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298776 Archived-At: > On Oct 29, 2022, at 11:31 AM, Theodor Thornhill = wrote: >=20 >=20 > (added back in emacs-devel) >=20 > Hi! >=20 >>>=20 >>> ``` >>> const fooClient =3D new Foo(() =3D> ({ >>> | // <---- point is there =20 >>> }));=20 >>> ``` >>> Which is not what we want. If we can keep that correct behavior in = any >>> case I say we remove the hack. We could make an anchor helper named >>> something like 'parent-then-bol', but because there is no node here, = we >>> cannot find the parent. >>>=20 >>> What do you think? >=20 >>=20 >> I added a rule that fixes it. Actually, when there is no node at >> point, parent is set to the smaller node that spans point, kind of >> like the immediate =E2=80=9Cparent=E2=80=9D of that point. I=E2=80=99ve= added some explanation >> in the manual. >>=20 >=20 > Yes, It's probably a remnant from when the semantics were a bit > different between the treesit-node-on and treesit-node-at. I see it = was > never there in ts-mode ;-) That was actually deliberate semantic (which I forgot to document), I = broke it when introducing the new semantic for treesit-node-at... >=20 >>>=20 >>> However, there are some problems with the newest revisions. During >>> }) >>> .catch((r) =3D> { >>> if (r.status < 200 || r.status >=3D 300) { >>> console.log(r); >>> } >>> }); >>> }; >>> ``` >>=20 >> Yes, sorry. I was naive with my implementation. Now it should be = fixed. >>=20 >=20 > Absolutely! Great work! >=20 > However... Try creating a js-mode buffer and type: >=20 > ``` > const foo =3D foo(() =3D> {}); > ``` >=20 > Because of all the stuff we set before we init tree sitter we get a > super unwanted behavior of the cursor jumping back to indentation for > every () {} etc. This is because of these settings, which are IMO = pretty > bad defaults: > ``` > (setq-local electric-indent-chars > (append "{}():;," electric-indent-chars)) ;FIXME: js2-mode = adds "[]*". > (setq-local electric-layout-rules > '((?\; . after) (?\{ . after) (?\} . before))) > ``` >=20 > This could just be something forgotten in the indent implementation, = but > in my book this is yet another example for why we shouldn't init like > this ;-) I don=E2=80=99t have anything intelligent to say about the init process = (except that we definitely need a way for js2-mode to turn off = tree-sitter setup made by js-mode even if it is enabled by the user), = but I fixed the indent problem you observed :-) Yuan