From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2) Date: Tue, 16 Aug 2022 21:56:15 -0400 Message-ID: <8a5502a4-febc-4794-be4c-a5018fe80114@gmail.com> 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> <874jykzvx9.fsf@yahoo.com> <017dcda1-cbff-8afa-0c70-a32224c89b8c@siege-engine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14893"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Cc: Po Lu , Eli Zaretskii , Alan Mackenzie , emacs-devel To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 03:58:21 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 1oO8K5-0003jI-5T for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 03:58:21 +0200 Original-Received: from localhost ([::1]:39118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO8K4-0007TY-96 for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 21:58:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO8IC-0005pi-7U for emacs-devel@gnu.org; Tue, 16 Aug 2022 21:56:24 -0400 Original-Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]:36617) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oO8IA-0008WQ-9P; Tue, 16 Aug 2022 21:56:23 -0400 Original-Received: by mail-qv1-xf33.google.com with SMTP id y11so9192899qvn.3; Tue, 16 Aug 2022 18:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=oZn0KLOBGYsZOTjsmgyg8wSvQ8PwIT9NZAmumRL4P3A=; b=jOzl2B34jjNnO9KjGaALMjiglJtEivofy4JpmsaN2hFvDe4tAdPTokqBl9GrYat+EM +FerJV2r67SSJPVMyl4XzUuxjycDco/EqXR4sXsIVJ3bwPTNIVOCh0/J9qgIUT/zOT41 PMN+12IsTJcZ1uHxY9QrKaZn9yU+aCPvEeWggo9MGOG6RZzmr5XXabnZnQMb64IAAMdF SH2MeEWOZfjETOlNYwVr4/HXndbTxEbvgSnuPSeICgyXlrhFVuwyjps4NTtpYvVOnFtD I1dqsa1qaBB6PEJz04tiuTaz1w3QbWMnyBfz8rxCeTgXGOL80cq2W7EHCeIH1loYP6ZY 73Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=oZn0KLOBGYsZOTjsmgyg8wSvQ8PwIT9NZAmumRL4P3A=; b=fgsTjQtjIB90u2vG5DqXGcrpJQGo6+ZAl7sImL8ukBs8qw9Zet+ZFLJqtrXrGobh9K 5jRfM62Qw2pWvZRuUeFWAX9FLQ3unb7LgP/l5AXRY/m0Wx78bHAKzgcLvdA0HKdHqP71 fS5b+UP9X4eWO74kC26Lff+R7y/iSmfLeu0KsNlB/D4SdIn8kW1EJa7GfMK5VxYVCfhf hNV232pVQ7soSbf3h6ROeRt9DDGsDKqrCnOQAMF+muQW5CQbTUbOLRGuPh/O08E9nkGJ GBNJMFr3i1kZ2M1KbF8goEcB5B3dcujFZjDl/HMz2biZlmnJsJMFnAY+MjCxIOflvizS H1lA== X-Gm-Message-State: ACgBeo0exWdP4be2xrH4ytdVo7WxAQ58JiNuz9OdlRQNRYPvEOQ3SFHe crET/aS5DoF7BYNeCkjN55o= X-Google-Smtp-Source: AA6agR7tknpXrSHxXY8gUBUjgXpDt38xGtwncIW4QbOSSF0dOFc3Qs3dwbCQINtlXI/tbX2uLAAHsg== X-Received: by 2002:a05:6214:3010:b0:47b:5759:8be9 with SMTP id ke16-20020a056214301000b0047b57598be9mr20349646qvb.103.1660701377106; Tue, 16 Aug 2022 18:56:17 -0700 (PDT) Original-Received: from [192.168.1.161] (pool-108-20-30-136.bstnma.fios.verizon.net. [108.20.30.136]) by smtp.googlemail.com with ESMTPSA id b13-20020ac8678d000000b0034300e35487sm11261354qtp.54.2022.08.16.18.56.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 18:56:16 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::f33; envelope-from=ericludlam@gmail.com; helo=mail-qv1-xf33.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, NICE_REPLY_A=-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:293528 Archived-At: On 8/16/22 6:42 AM, Lynn Winebarger wrote: > On Sun, Aug 14, 2022 at 3:24 PM Eric Ludlam wrote: > > I was also frequently surprised by how hard it was to get CEDET to 'just > > work' well enough for everyone to use it as intended, and how often > > people just jumped over to simpler one-off external tools because the > > full suite way CEDET works was too heavy a lift.  That in turn resulted > > in not a lot of contributors to help support/improve those workflows. > > Tools like LSP also became good enough where there was no way I could > > keep up.  I had hoped to pull data from external tools like lsp into the > > framework CEDET used, but again the simpler one-off tools were too > > appealing to that audience. > > > > Overall, I think that is fine though - having many projects > > experimenting with different techniques, and having the best solution > > win is the benefit of free software.  Developing CEDET back when it was > > the only game it town was a good time with many good people helping, and > > I am glad to have been a part of that, and I'm glad CEDET is still > > useful in many cases. > > I think there should be a substantive place for such a framework in > Emacs, regardless of external tools that can be used to provide some > of the analysis.  Even if a mode doesn't use the parser generated by a > grammar, the grammar can also provide a description of the syntactic > structure that can be used in separating fontification from syntactic > analysis.  If I understand it correctly, Semantic provides support for > that generic approach and tying the classification to the text through > overlays  It should be straightforward for a major mode to create a > set of faces that can be applied generically by font-lock based on > those overlays instead of via regular expressions on the underlying text. > I've skimmed lsp-mode, but I can't tell how it attaches the analysis > from the server to the text. > Just looking at tsc-core's GitHub page, I don't see a similar generic > approach being provided.  I get the impression there is a lot of > dependence on the individual language/mode as to how the information > gets incorporated in the fontification. One of my goals in CEDET/Semantic was to provide distinct interfaces between layers.  Thus, there is a parsing/tagging layer, a middle layer to manage tagging data, and a few example tools that could take advantage of the data. This mostly worked well.  One parser that didn't make it into Emacs used ctags which added support for 8 additional modes such as sh, asm, & pascal.  This tool would populate the tag data the same way as other semantic parsers, so when you use some of tools that sit on top, such as 'senator' everything just works. So indeed, if the middle layer were to be used with more tools, new parser/taggers could just fill it in as a way to let those tools work.  In fact, there's no reason why lsp couldn't populate the tagging layer while continuing to do the other things it does well. Eric