From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: tree-sitter: conceptional problem solvable at Emacs' level? Date: Sat, 11 Feb 2023 10:53:41 +0300 Message-ID: <347b09886f7393560296428b86f59c367195929f.camel@yandex.ru> References: <87zg9n45ig.fsf@yahoo.com> <0DDF6978-D75A-4137-9D93-6200908675B6@gmail.com> <837cwplxni.fsf@gnu.org> <83zg9lkagi.fsf@gnu.org> <87ttzt0wtv.fsf@yahoo.com> <357e68eacfb7931fae08704ebfcbe1178a08fd69.camel@yandex.ru> <0768E0D7-6D58-40AC-A1D4-784C27CE0D7F@thornhill.no> 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="27893"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.46.3 Cc: Holger Schurig To: Theodor Thornhill , emacs-devel@gnu.org, Po Lu , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 11 08:54:45 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 1pQkib-00076w-DC for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Feb 2023 08:54:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQkhn-00066t-8X; Sat, 11 Feb 2023 02:53:55 -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 1pQkhj-00066j-5K for emacs-devel@gnu.org; Sat, 11 Feb 2023 02:53:51 -0500 Original-Received: from forward502c.mail.yandex.net ([2a02:6b8:c03:500:1:45:d181:d502]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQkhg-0004Qk-G5; Sat, 11 Feb 2023 02:53:50 -0500 Original-Received: from myt6-265321db07ea.qloud-c.yandex.net (myt6-265321db07ea.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2626:0:640:2653:21db]) by forward502c.mail.yandex.net (Yandex) with ESMTP id 5AAA05E893; Sat, 11 Feb 2023 10:53:42 +0300 (MSK) Original-Received: by myt6-265321db07ea.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id fraGjCJZPGk1-mxvV3Id4; Sat, 11 Feb 2023 10:53:41 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1676102022; bh=4sZgoOHM4stqcN8Qaw1h/os+15b41ZiPtbOM8CBwnqs=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=HbM2zB6uoPvGBLq9iVKmLxMuEEw/kImf5VW+3QoEaqU54E8vq1vR+Scr0hnipTHq+ FpIxVC88mLV2q7YNjTMnQWDwAgyVK7aB8Jt5Gs78cE2B/STeGGzU03EwJMhutR0cIC 3CppyUzu2+9bNPopWHpT2DGEedobo6UB43NTEkuo= Authentication-Results: myt6-265321db07ea.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: Received-SPF: pass client-ip=2a02:6b8:c03:500:1:45:d181:d502; envelope-from=hi-angel@yandex.ru; helo=forward502c.mail.yandex.net 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, 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:303126 Archived-At: On Sat, 2023-02-11 at 10:11 +0300, Konstantin Kharlamov wrote: > On Sat, 2023-02-11 at 07:51 +0100, Theodor Thornhill wrote: > >=20 > >=20 > > On 11 February 2023 07:36:26 CET, Konstantin Kharlamov > > wrote: > > > On Sat, 2023-02-11 at 09:25 +0300, Konstantin Kharlamov wrote: > > > > On Sat, 2023-02-11 at 10:17 +0800, Po Lu wrote: > > > > > Eli Zaretskii writes: > > > > >=20 > > > > > > However, I meant the IDEs which are using tree-sitter and suppo= rt > > > > > > developing C/C++ programs.=C2=A0 I believe some do. > > > > >=20 > > > > > I think most of those have similar problems supporting macros. > > > > > Who knows their names? I may be able to ask some of their users. > > > >=20 > > > > From my experience on and off work, there are just two IDEs (as in,= not > > > > editors) > > > > used most widely for C++ code: QtCreator and Visual Studio. The fir= st > > > > you > > > > discussed, the second is proprietary. > > > >=20 > > > > Then again, people most often code in C++ and C with text editors, = in > > > > that > > > > case > > > > popular choices from my experience: Sublime Text and VS Code. These= two > > > > have > > > > don't use tree-sitter either. > > >=20 > > > I installed Sublime Text on my Archlinux and tested with the C++ code= OP > > > posted. > > >=20 > > > What I see is that ST does seem confused about indentation, while try= ing > > > to > > > make > > > a newline right after `slots:` line. > > >=20 > > > However, if you try to make a newline after the `void someSlot() {};` > > > line, > > > it > > > will use the indentation used on the previous line. > > >=20 > > > The default cc-mode in Emacs works similarly. The cc-ts-mode on the o= ther > > > hand > > > doesn't make use of the previous indentation, and I think it should. = It > > > would > > > resolve that problem and others, because in my experience it happens = very > > > often > > > in C and C++ code that you want some custom indentation level, so you= just > > > make > > > one and you expect the editor to keep it while creating more new line= s. > > >=20 > >=20 > > That last statement sounds easily solvable. Can you send me a short exa= mple > > describing exactly what you want in a code snippet and I'll add it. > >=20 > > Thanks, > > Theo >=20 > Thank you! The example is below, but please wait a bit just to make sure > there's no opposition from other people, because I don't know if it works= like > this on purpose, or not. >=20 > Given this C++ code with weird class members indentation: >=20 > =C2=A0=C2=A0=C2=A0 class Foo { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int a; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bool b; > =C2=A0=C2=A0=C2=A0 }; >=20 > Now, suppose you put a caret after `bool b;` text and press Enter to make= a > new > line (all tests are done with `emacs -Q`). The behaviour: >=20 > * cc-mode and Sublime Text: creates a newline with the indentation exactl= y as > on > the previous one. > * cc-ts-mode: re-indents the `bool b;` line, then creates a new one with = a > custom indentation that is different from one on the `int a;` line. >=20 > The cc-mode and Sublime Text behaviour seems like less annoying to me, be= cause > if I wanted to reindent the prev. line, most likely I'd did it by pressin= g an > indentation hotkey (e.g. `=3D` in Evil mode I use). FTR, re-using indentation from prev. line seems to has been the default in = all Emacs modes, and one that proved to be useful. To support that here are mor= e examples.=C2=A0 While writing C, depending on a circumstances the pre-existing code might h= ave indentation of function args like this: foo(arg1, arg2); Or like this: foo( foo1, foo2); You might want to add another argument to the call, but you don't want to r= e- indent everything. So when you press Enter, you expect the new line to have prev. indentation. Another example from elisp-mode: I have this snippet in my Evil config: (use-package evil ;; [=E2=80=A6] :bind (:map evil-insert-state-map ;; after having insert-state keymap wiped out make [escape] switch= back ;; to normal state ([escape] . 'evil-normal-state) :map evil-normal-state-map ("C-u" . 'evil-scroll-up) ("k" . 'evil-previous-visual-line) ("j" . 'evil-next-visual-line) ;; [=E2=80=A6] :map evil-visual-state-map ("k" . 'evil-previous-visual-line) ("j" . 'evil-next-visual-line) :map isearch-mode-map ;; allow for "up/down" history scrolling in / search ("" . 'isearch-ring-advance) ("" . 'isearch-ring-retreat) ) ) If I were to re-indent everything, the indentation in `:bind` body would be different. But I want to keep it the way it is now, and due to elisp-mode r= e- using prev. line indentation, whenever I create a new line, it will always = have the indentation I wanted.