From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [SPAM UNSURE] Maybe we're taking a wrong approach towards tree-sitter Date: Fri, 30 Jul 2021 15:57:58 +0200 Message-ID: <20210730135758.y7eol56zyszo5boe@Ergus> References: <8735rzyzbz.fsf@163.com> <86v94v3xh9.fsf@stephe-leake.org> <87wnpargnb.fsf@elite.giraud> <87h7gey7zx.fsf@163.com> <83pmv2twrl.fsf@gnu.org> <86sfzwogsn.fsf@stephe-leake.org> <87o8akmy4p.fsf@163.com> <87bl6kezgu.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26816"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?B?w5NzY2Fy?= Fuentes , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 30 15:59:11 2021 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 1m9T2c-0006lA-8C for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 15:59:10 +0200 Original-Received: from localhost ([::1]:35704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9T2a-0003tm-Mj for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 09:59:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9T1r-00038v-OA for emacs-devel@gnu.org; Fri, 30 Jul 2021 09:58:23 -0400 Original-Received: from sonic311-13.consmr.mail.bf2.yahoo.com ([74.6.131.123]:36442) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m9T1o-00066O-K0 for emacs-devel@gnu.org; Fri, 30 Jul 2021 09:58:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1627653497; bh=uJ0jofkHSijzl+Q6mebzErtZfjymCKmYXg7lydn6mbM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=Ahp2VwEi/P+/yq9xsp5PSjwXYv+nRUc4kbYPM9usGFc2WkPaa4yztt2nQ80u7x2Usi4C4iuJvMzEI4rgUDUxwhoXsbgBmTL98wa2bjHcWPKS+12XdFbBotqLTK26owUjM5pqNnWXNLBqHATV5zWip0wMbej08am/ozvMWr50LptYcUIqtiCa5UqPT/EQsqJ2Or1arg9MzKmFeflx8sKn9uKR2QknUfHftnz4IIP5AbDmYtnKsKJbBCG7zlrtOrLt+Fye7SqZdhDoBjLlVgs0Q8jMoA/8gSH+RTqw3OLirozA8k1+WIiUM1ln9Ilsh8k1LTFKFrdtPEt+AEtGdNj6SA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627653497; bh=eDXHQngc7O0Y0lY6+gwfJSwHrNFqnQ/ldLfUmVJ3yid=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=IBKumMUrqlkxZuvGpEN/QCvAioy9YxNggDB3TAYqq0L8lOtZzWJPAsC1iFuRGYTCkzxHo5t2ogjJxh1gm8mKykQYONFkBoS+9VCxSdmrU9h0ysbd+JExfl6xoHN2DnlAucA2B3m08Ae/aSRsxq1JZrT/N2GsNyPRYoUF6+XRvT2gxHp1vIAdTmdn+vrMoVU0AA6PEPGSjsjTOXZlHyTGVWEWJWCmJ8ZG1HDV6jxMcM6eWU4/xlvmNsPjuAuk/M8g6ojE0rRKsgveFmsFwPLM0EVTIlcUORCz/dzmszfb6yIQJ1XiFCR5Rvuh1K20VHQjORJ7Geh5A+HsS3o+Hs9S1w== X-YMail-OSG: CYwnwEYVM1miI8ibSDvoR8YezyevlDZ.lzI7LhslmoajVPdkUR14eSuSw76W92M lIwe.Q6uBdEx_f_40JSATkpTf2MbM.qCEsEJhByN9EUxq2yasuIJQ.pOQV6abFt_hC15cwBffiu5 STXlV.VVHYp2ymGqDMG4cGJmG46FH_69ocC3uKmW7q58JfsBZ.23WtR2b0zQx9i8SmxLm2JuvxQu 0k3.MT1FUghRCfBQ6wRh18TEhb.v9EiqWgzQhpRtR3asskdnFRD3edJ4RW0of.kkbFfSGL_8WwnT Y1w.gv8Tu5684bYiy0ZSMS9_0B.HrjG2w6zU2Xs_6ppDAK3MU8pwd_2m9eCB0zjLaIUB9t7UIoCY Cz454xDYJS3oIiRT_9mWDOucgsv8MkICi.91XoeqwWK1ePoE9MA4lwOM8thtu.sdNLQGMP22G46W 89zpTgCIfjlM0w5hgWhmJDrZM5yIGkP67AizZe5w7yJQqWcf5Jndqj2Y5B94WaTgWbK8nj7nS5Dd Jo0uyw.YwqhF3_KfSOKAHQEqbhv0ZVkNziJPODcauC7Fe3Nhtb0DQIMTuOH7ppnUvt8B5hYe2VW8 7REFtutCmMdeNo3aJEmyoeNCUWuxR75vlbXYQTvHAMa8urToEu4l8wNwUFpJ7DOr0xCb2F4cfRWA niT4fb6ZKBVASI1rD7vw10bAV5N0FfOv93qSjxDGRtDcdETA0FfxIGtd5KRoEpQWvbPYg1GvY7Ob G1eOyNPc1fzJa5vOBptyeK4fl0kDg46lj96j9KXyPlPDu87n7NSZmiycbksyzABy9Zl0zMyIEX26 A3t2iprgpa7WecFx8_8IRhm0c7WXdcWf.s9fcnJRCB X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 30 Jul 2021 13:58:17 +0000 Original-Received: by kubenode517.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dc48e7f173e3612e08a882f63a5c90c4; Fri, 30 Jul 2021 13:58:15 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.18749 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.131.123; envelope-from=spacibba@aol.com; helo=sonic311-13.consmr.mail.bf2.yahoo.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, RCVD_IN_MSPIKE_H2=-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.23 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:271847 Archived-At: On Fri, Jul 30, 2021 at 03:30:42PM +0200, Arthur Miller wrote: >�scar Fuentes writes: > >> Arthur Miller writes: >> >>> I undestand that having specialized regex matcher is more efficient than >>> some generalized regular matcher current font-locking in Emacs relies >>> upon, but is it *that* more efficient to be worth the extra troubles? >> >> AFAIU this is not about efficience, but mainly about correctness (modern >> languages are increasingly more difficult to analyze) > >Ok, I understand, and I can buy that one. Question is if it is still >worth just for the syntax hightlight and indentation? If I get some >spurious color here or there sometimes not colored, do I care? > Yes, we care. Syntax highlight for an editor is a basic feature in 2021. >Can that syntax tree of TS be exposed to lisp and used for some other >purposes, This is the idea. use the tree for navigations like up-list or goto-defun for example. Maybe not the tree directly, but the information it provides (maybe calling TS function wrappers or setting the TS information as text properties). >or is it just internal to TS and only output we see is some >colors on the screen? > How we use it is more a design choice. We can access the tree information with the TS api or we can just put the tree's information as text properties... imagination is the limit ;) >> and also about >> decreasing the maintenance load. >Sure, but it is also a limitation. If Emacs will rely on TS maintainers >to create new grammars and update existing ones when language changes, >it means Emacs users will have to wait for changes until they are >fixed upstream, similar as how gnu/linux distros work regarding >packaging. Of course, a user who wish to modify or introduce new >language can always rely on old font-lock or go through pain of TS >toolilng based on JS and custom tools. Lisp frontend to that toolchain >can probably be developed but that is even more work. > Sincerely; create a grammar for TS is much simpler than create a mode with font-lock, navigation commands, indentation rules and some flymake. All the modes with TS will be a bit more consistent in colors and keybindings (now we have modes where all commands use different prefixes, or lacking navigation or with different indentation customs. So using them is like learning different editors for every language) >> In the process, Emacs gets support for >> some new languages too. > >Yes, it is always nice I guess :). Is there really demand for some >language currently provided in TS and not in Emacs? > Indeed. As I mentioned before web developers are using VScode or neovim because Angular, React, Nodejs and Python are painfully supported (compared to VScode or Sublime). Rust is very limited supported in emacs, so users rely on external packages like rust-mode, elpy or anaconda that introduce different bindings, collisions and require some complex setups for the basics. >I don't know, I am maybe overly sceptical to TS; I don't mean it is a >bad package, and I am sure it has it's place in other editors, I am just >not sure how it fits in Emacs where everything is easily configurable >and extensible. > It is just a good trade-off configurable enough for 99% of the use cases. Unless we expect all the users to be advanced lisp hackers to customize their fontlocking, indentation and navigation functions for every single prog-mode.