From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2) Date: Tue, 9 Aug 2022 20:22:00 -0400 Message-ID: References: <83o7wuva9o.fsf@gnu.org> <83mtceupbx.fsf@gnu.org> <83lerxvfnu.fsf@gnu.org> <838rnxvdcq.fsf@gnu.org> <83r11ptksn.fsf@gnu.org> <83a68dti6w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000059cb9305e5d80a4f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22460"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 10 02:22:57 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 1oLZUt-0005d9-QH for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Aug 2022 02:22:55 +0200 Original-Received: from localhost ([::1]:58146 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLZUs-0004re-Cn for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 20:22:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLZUH-0004BD-3X for emacs-devel@gnu.org; Tue, 09 Aug 2022 20:22:17 -0400 Original-Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]:34481) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLZUF-0000qY-Fr; Tue, 09 Aug 2022 20:22:16 -0400 Original-Received: by mail-pg1-x52f.google.com with SMTP id 12so12882950pga.1; Tue, 09 Aug 2022 17:22:14 -0700 (PDT) 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; bh=t91o5eI+KeJ2QZMHUAXecUJ2fe1uLVpfH3o3yYurWeI=; b=CyI5kUy8bKzzlnM++ecWS/2esMgqnykAi5JvptHcSWBseZByJCGCam+MrDsRzr6LYI QjjGog3rAYQW3K72FOAXOx75aUHzXQSzBgH+CvZF1RwppjtMjsF/jEsHJE0OlNq2fOPf A8x+2QfcLEJ3pe8QCLGj9GptUIGjkGLAvHn23uftWOREZgCFlf34vVLIFq4VIwYeMTUK uzbfY94FWXPUx7vJdHCSApyJwHjjZXcKhzrRMvS24M8dhj3GWTg+trvr6+rG3xvVRAyB fcYYv1nxwDhmAQ1vf5T0zZBBQprLC8c3OO5g+daumxk3TD8bbIPHo8JggYni1uU2HTFr dcXg== 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; bh=t91o5eI+KeJ2QZMHUAXecUJ2fe1uLVpfH3o3yYurWeI=; b=bj63pNJQLGfvluL7iomlx5ouaTm0YaSa9ybnXr30gCo9AmBkYudFDMTrUUCMmvVZRK vrdwcejDsFb+kYxTFYHEEpjnYTqFFNJgfdZRdIFqVd6XEDebJmrwvuEn+WXJHYiQqW+m BauSpTdgyVNa9ANilFcrzuPyg3wC9Ulam94CbZWBTUta+akAaM5Bmf0KULjLpzGSCmH0 1a8dh5/TpYKQhKk8jjKNM0BgHKRPi+2l3+UFRpaqAW9Qq24oAd59Er+rc0r6n3yDNxCV 07SA3mrhYobewBSpgg+mplHTaDdlsbRji0Uc3eQ9k4SNCF5Y6o64DUTo/v2BXq7e08yY 08Sw== X-Gm-Message-State: ACgBeo32ypzo19tEo3Bc83afED6l7w/FZVpKCV7tx+Tw47WEucMSmPBU Wz7LcLKAheJ/6RGAnNqklr0GZCiGQTOxMtVke8ZKa6Lv X-Google-Smtp-Source: AA6agR6L6M7I47GsGGKhG3WFI0l/9gwAn+N+mZCmBvIDNTclohI4QmCht+MPzIA+FhE7E/GGxLFgKl/Hqze7ePxDU7g= X-Received: by 2002:aa7:86d4:0:b0:52e:fe71:77df with SMTP id h20-20020aa786d4000000b0052efe7177dfmr15390626pfo.35.1660090932904; Tue, 09 Aug 2022 17:22:12 -0700 (PDT) In-Reply-To: <83a68dti6w.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::52f; envelope-from=owinebar@gmail.com; helo=mail-pg1-x52f.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, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:293337 Archived-At: --00000000000059cb9305e5d80a4f Content-Type: text/plain; charset="UTF-8" On Tue, Aug 9, 2022, 1:58 PM Eli Zaretskii wrote: > > Date: Tue, 9 Aug 2022 17:43:31 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > But I don't like your proposed solution, which you've mentioned several > > times, namely to make level 3 more like level 2. I.e., to deliberately > > reduce its accuracy in the name of speed. > > Then I guess CC Mode will remain slow, until maybe tree-sitter > integration will fix it. Sadly. > I have a related question. I have this programming mode derived from CC mode. The formal syntax is on the one hand much simpler than anything like C++, but I find trying to capture the constructs by the regular expression rules employed by font lock very difficult to get right. I have a re-entrant LALR grammar for this language that I intend to use with Semantic to get proper handling of all constructs. That's one of the main reasons I wanted to be sure to get as efficient a baseline system as possible (and can now proceed with). I'm curious, though, as to why Semantic/CEDET seems to have been superceded by external solutions like tree-sitter or LSP-based (non-emacs) servers. One of the draws of Emacs for me is the "batteries included" nature of it having Emacs Lisp built in. Is there a downside to using Semantic as the basis for improving my derived mode that's non-obvious? Would producing a threaded code parser instead of a straight table driven parser be a better approach with the native compilation option now available? I also use this mode to fontify a REPL session for this language, which has pretty awful performance when producing tracing output that hits 1-5 hundred K lines in a buffer, which is why this narrowing discussion interests me, even though the buffers in question don't have particularly long lines. It just chews up memory if I try to jump from the end of the buffer to the beginning. Or at least it did in v24.3. Thanks, Lynn --00000000000059cb9305e5d80a4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 9, 2022, 1:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 9 Aug 2022 17:43:31 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> But I don't like your proposed solution, which you've mentione= d several
> times, namely to make level 3 more like level 2.=C2=A0 I.e., to delibe= rately
> reduce its accuracy in the name of speed.

Then I guess CC Mode will remain slow, until maybe tree-sitter
integration will fix it.=C2=A0 Sadly.

I have a related question.=C2=A0 I ha= ve this programming mode derived from CC mode.=C2=A0 The formal syntax is o= n the one hand much simpler than anything like C++, but I find trying to ca= pture the constructs by the regular expression rules employed by font lock = very difficult to get right.
I have a re-entrant LAL= R grammar for this language that I intend to use with Semantic to get prope= r handling of all constructs.=C2=A0 That's one of the main reasons I wa= nted to be sure to get as efficient a baseline system=C2=A0as possible (and= can now proceed with).

= I'm curious, though, as to why Semantic/CEDET seems to have been superc= eded by external solutions like tree-sitter or LSP-based (non-emacs) server= s.=C2=A0 One of the draws of Emacs for me is the "batteries included&q= uot; nature of it having Emacs Lisp built in.=C2=A0 Is there a downside to = using Semantic as the basis for improving my derived mode that's non-ob= vious?=C2=A0 Would producing a threaded code parser instead of a straight t= able driven parser be a better approach with the native compilation option = now available?

I also us= e this mode to fontify a REPL session for this language, which has pretty a= wful performance when producing tracing output that hits 1-5 hundred K line= s in a buffer, which is why this narrowing discussion interests me, even th= ough the buffers in question don't have particularly long lines.=C2=A0 = It just chews up memory if I try to jump from the end of the buffer to the = beginning. Or at least it did in v24.3.

Thanks,
Lynn
=




--00000000000059cb9305e5d80a4f--