From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Need for "-ts-mode" modes Date: Thu, 29 Dec 2022 21:57:12 +0200 Message-ID: <83sfgy6l0n.fsf@gnu.org> References: <877cyagmti.fsf@posteo.net> <831qoi85u7.fsf@gnu.org> <87mt76f4n4.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17220"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 29 20:57:44 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 1pAz28-0004I0-4B for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 20:57:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAz1Q-0000Yh-QQ; Thu, 29 Dec 2022 14:57: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 1pAz1P-0000YT-C3 for emacs-devel@gnu.org; Thu, 29 Dec 2022 14:56:59 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAz1P-0004vv-38; Thu, 29 Dec 2022 14:56:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3jjHlc1GjXn1EO3OQUFKLzToqPC/KQov9SWhXJ28Kqs=; b=G4a/1srnI7yt cepulmJqIN5rmLOxQ91UylSQJ6o924f3CL405aKF9R9MhDQ+nD8O1TImgg4Rbui1eq6Z9jv6QnlAu VslsXowouPpJ13a1UCCn9Ad1l/t/ntpO+L8sCzNIIcgJZu0DPADKIUD+G9rH4o9QPGmRZp5voFjsA eEiZzyOf8AxRPPGfv0xcp7TLkkTZ2/8Sz4q9z6Z5znYh7RiuxEFRp/qxqwEVCvQ2gb6c2gzIUXgMl Ax6afb8JsCYTjBFcn4Ln4V7JaZB0M7HVWLGpmRjWnmel3LPx9Md10co5sRucs5jdFjbEoiKDnOBLA u034GV/o2dlgqel1Mfb4xQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAz1O-000627-Ib; Thu, 29 Dec 2022 14:56:58 -0500 In-Reply-To: <87mt76f4n4.fsf@posteo.net> (message from Philip Kaludercic on Thu, 29 Dec 2022 18:26:07 +0000) 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:302065 Archived-At: > From: Philip Kaludercic > Cc: emacs-devel@gnu.org > Date: Thu, 29 Dec 2022 18:26:07 +0000 > > > Because this was the simplest way, that created no complications, > > neither to users nor to the code, and could be added in > > backward-compatible ways. > > What backwards-compatibility are we taking about here? Let the users decide whether and when they want to turn this on or off, and keep their init files and use habits working. > > I fail to see what's wrong with that. It is entirely legitimate to > > have a major mode which depends on an optional feature and doesn't > > work without it. > > Naturally, if there is no way around this. My argument is that there > is. What prompted me to ask this question was when I just opened a > Dockerfile and a warning popped up, telling me that I was missing the > right libraries. I took a peak inside of dockerfile-ts-mode, and found > the following > > --8<---------------cut here---------------start------------->8--- > (defvar dockerfile-ts-mode--keywords > '("ADD" "ARG" "AS" "CMD" "COPY" "CROSS_BUILD" "ENTRYPOINT" "ENV" > "EXPOSE" "FROM" "HEALTHCHECK" "LABEL" "MAINTAINER" "ONBUILD" "RUN" > "SHELL" "STOPSIGNAL" "USER" "VOLUME" "WORKDIR") > "Dockerfile keywords for tree-sitter font-locking.") > --8<---------------cut here---------------end--------------->8--- > > For me, using these keywords would provide all the "functionality" I > could need from a Dockerfile. If you want to provide a dockerfile mode without tree-sitter, please do. I'm saying that having just a TS-supported mode is better than not having any mode. > With the exception that a warning is generated, popping up a new window, > which is distracting. Not a disaster, IMO. > >> Or the re-phrase the question, why can't tree-sitter support be > >> implemented by extending `define-derived-mode', ideally in such a way > >> that can be translated to some kind of font-lock rules for basic syntax > >> if the library is not installed. > > > > Because it doesn't work. Tree-sitter supported modes are not derived > > modes, they are completely different modes with different settings > > which make no sense when tree-sitter is not used. > > I am not talking about deriving foo-ts-mode from foo-mode, but adding a > keyword to `define-derived-mode' that would generate code to try to make > use of tree-sitter if available, and fall back to traditional font > locking if not. The *-ts mode provide more than just fontifications. They provide indentation, navigation, and Imenu support. And they do that in ways that are radically different from the "traditional" ways we did this stuff, with data structures and algorithms that are very different. If you think you know how to extend define-derived-mode so that we could treat tree-sitter as some enable-FOO style variable, please show the code, and let's see whether it's clean enough for our palate. But please do this for a serious major mode, like Python or C/C++, not for dockerfiles, because that's where we bumped into problems that eventually led to what we have now. We did try to do something like that before. > Perhaps it would be even better to bundle all the tree-sitter related > options into a single object, define it as a defvar and pass that via a > keyword. Feel free to propose how to do that. We tried several different ideas and each one of them either had problems or was not cleaner than what we have. > What I want to know is, if this is viable (as I plan to find out in the > next few days), would it be possible to change the current route before > 29.1 is released, so as to avoid committing to the current strategy. You can try. I would like to start a full feature freeze in a day or two, so I'm not sure you will have enough time. And it isn't like we didn't try various approaches during the past two months, so frankly I don't think that a better way even exists. But if you come up with some very bright idea, who knows?