From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_Paulo_Labegalini_de_Carvalho?= Newsgroups: gmane.emacs.devel Subject: Re: Code navigation for sh-mode with Tree-sitter Date: Mon, 5 Dec 2022 08:24:37 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bba71c05ef164964" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39014"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 05 16:25:37 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 1p2DLd-0009vD-6g for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Dec 2022 16:25:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2DL2-0004xi-Qc; Mon, 05 Dec 2022 10:25:00 -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 1p2DKw-0004xE-QS for emacs-devel@gnu.org; Mon, 05 Dec 2022 10:24:55 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p2DKu-0000wC-Aw for emacs-devel@gnu.org; Mon, 05 Dec 2022 10:24:53 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id z92so16304969ede.1 for ; Mon, 05 Dec 2022 07:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=D+Ijf942MX8BPTJ2s6O2QaRykrZA46qkYrKW1TfkTzI=; b=K59rUDsPZr096x/vz/ltFBaeyWF8T7hrBiLBUnmrGlm4NYmG3aTr6uoWEoxfZKmPgP xDureD79E7mZY30K8HsCZniDdAF0li6wITOYPjzoq4aM/qAjCOtV36Oe6s5APkXuU79Y UEYe3fbH+BPdAtEiEc8Ju0u5SDdX/RPo2QlEDhX0fAyBkwwKv3YpidalDlt8J7E1nue+ IQpQRTwGPKoW9B1CmcBnGxFlRrhgDePByuAWhmo7Ucobe81mUdkP3mtcI8qtRxL2Lkd0 D8FWT8uye9Jb2y8En7/SbMEpCFeHuEl9TjKBffdqbAfsC4ixsWo5dVLcLSuy1eUJtMox eA8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D+Ijf942MX8BPTJ2s6O2QaRykrZA46qkYrKW1TfkTzI=; b=dM7TmOPmOucrRiphWKlmLFq3YOCw3WTKKwmUScfo8H+7BNf6oVFbnyAEzcm92jKBdS cSqfEZZXxbszRHdxfCYEOEg4P/GeA8HNzrUEs4OTt8UzeDRfxDCag0D0+8GBQEtGxo+e fVRJpSIs50p7vBStCjaTyUTMNhhACAQTJkc3o68kb/pfhVkrRxzkO+Zhsbo18bGu//Nd KC/5fY7x6ls+tVIuP7gVH3PEhqKG9jE9LQGb+fqL37pIbEb2AaBULTfrQAPgk9dVtRvN JHcnXZ8Hb2xNT4zPKja5XVFatutSoUFnPortUMAtQDQ230UXr9ClVezeW2AebSutFEpb xlcw== X-Gm-Message-State: ANoB5plk/ra/QwlsPIie4Pv73zov8h0toBulGRRCurAcPXZjqjWdtN7d 16Y2DSbI/KOG04+QozHCDXldZ701a5xKmxmSrxaoym5Y X-Google-Smtp-Source: AA0mqf59ztQGYJkwj53X5sTaDm+fIna5/S8PpwxOhGQKtnRqX29fJS+R4H8EHhVKH5hm4sEKQIriA4uN00Kzv+1MtQ8= X-Received: by 2002:a05:6402:1145:b0:46a:d5ee:d150 with SMTP id g5-20020a056402114500b0046ad5eed150mr38713935edw.312.1670253888905; Mon, 05 Dec 2022 07:24:48 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=jaopaulolc@gmail.com; helo=mail-ed1-x533.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, HTML_MESSAGE=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:300932 Archived-At: --000000000000bba71c05ef164964 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 3, 2022 at 2:46 PM Alan Mackenzie wrote: > Yes. beginning-of-defun and end-of-defun are broken, and have been for > a long time. They cannot, in general, work, for the reason you've just > noted. > Thanks for confirming this, Alan. For a moment I thought that I was making one of those elisp newbie mistakes. > The problem has been raised on emacs-devel before, without the problem > getting solved. CC Mode, for example, works around the problem by > binding c-beginning-of-defun and c-end-of-defun directly to C-M-a and > C-M-e, bypassing the offending code. > I think for now I will use the same workaround. > The tactic of using beginning-of-defun-raw is only valid in certain > circumstances, and is an inappropriate inefficiency in modes such as > the one you're writing, where it is just as easy to go directly to an > end of defun as a beginning of defun. > > > What I think is happening is that, when `end-of-defun' calls > > `beginning-of-defun-raw' it brings point to the beginning of a top-leve= l > > function, so the subsequent call to `end-of-defun' moves point to the > start > > location, does it make it seems as the point did not move. > > Yes. I suggest you submit a bug report for this bug. > I will put some time into this and see if I can come up with a patch before flagging it as a bug. > To work properly, beginning/end-of-defun need to know whether the > starting point is inside a defun or between defuns. Your patch includes > a macro which determines this (as CC Mode includes a function which > determines this). Possibly, a proper bug fix might include a function > supplied by the major mode for this analysis. > Indeed. I am not sure if that would be as easy as without tree-sitter, but such a function is definitely handy and easy to implement thanks to Yuan's efforts to bring tree-sitter to core. --=20 Jo=C3=A3o Paulo L. de Carvalho Ph.D Computer Science | IC-UNICAMP | Campinas , SP - Brazil Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canad= a joao.carvalho@ic.unicamp.br joao.carvalho@ualberta.ca --000000000000bba71c05ef164964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 3, 2022 at 2:46 PM Alan M= ackenzie <acm@muc.de> wrote:
Yes.=C2=A0 beginning-o= f-defun and end-of-defun are broken, and have been for
a long time.=C2=A0 They cannot, in general, work, for the reason you've= just
noted.

Thanks for confirming this, Alan= . For a moment I thought that I was making one of those elisp newbie mistak= es.
=C2=A0
The problem has been raised on emacs-devel before, without the problem
getting solved.=C2=A0 CC Mode, for example, works around the problem by
binding c-beginning-of-defun and c-end-of-defun directly to C-M-a and
C-M-e, bypassing the offending code.

I think for n= ow I will use the same workaround.
=C2=A0
The tactic of using beginning-of-defun-raw is only valid in certain
circumstances, and is an inappropriate inefficiency in modes such as
the one you're writing, where it is just as easy to go directly to an end of defun as a beginning of defun.

> What I think is happening is that, when `end-of-defun' calls
> `beginning-of-defun-raw' it brings point to the beginning of a top= -level
> function, so the subsequent call to `end-of-defun' moves point to = the start
> location, does it make it seems as the point did not move.

Yes.=C2=A0 I suggest you submit a bug report for this bug.
=

I will put some time into this and see if I can come up= with a patch before flagging it as a bug.
=C2=A0
To work properly, beginning/end-of-defun need to know whether the
starting point is inside a defun or between defuns.=C2=A0 Your patch includ= es
a macro which determines this (as CC Mode includes a function which
determines this).=C2=A0 Possibly, a proper bug fix might include a function=
supplied by the major mode for this analysis.

Inde= ed. I am not sure if that would be as easy as without tree-sitter, but such= a function is definitely handy and easy to implement thanks to Yuan's = efforts to bring tree-sitter to core.=C2=A0

-= -
Jo=C3=A3o Paulo L. de Carvalho
Ph.D Computer Science= | =C2=A0IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fello= w | University of Alberta | Edmonton, AB - Canada
--000000000000bba71c05ef164964--