From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Need for "-ts-mode" modes Date: Thu, 29 Dec 2022 18:26:07 +0000 Message-ID: <87mt76f4n4.fsf@posteo.net> References: <877cyagmti.fsf@posteo.net> <831qoi85u7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36016"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 29 19:39:10 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 1pAxo5-00099W-6k for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 19:39:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAxbZ-0003Kd-17; Thu, 29 Dec 2022 13:26:13 -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 1pAxbU-0003Ig-SM for emacs-devel@gnu.org; Thu, 29 Dec 2022 13:26:09 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAxbQ-0007ge-BW for emacs-devel@gnu.org; Thu, 29 Dec 2022 13:26:08 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 08D2C2401A8 for ; Thu, 29 Dec 2022 19:26:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1672338362; bh=joCAU12mSKeH5FDcPf1aIKpVtJLbWkH5Ens0z9skvGs=; h=From:To:Cc:Subject:Date:From; b=YS7Q2OXoXNFBghFHbCPnXuivZXJ1xx0cFy+TKnRac/eLqjrgLNP8VP1enYZPzu3zM Wgo3hdk2ljY8pTXwXxS8K48zdhy5uVXL+uAKUyCLOvAlegsd0vaVJdo3xbs+SLLlvi Xzt0dy31NGJ8iS7ZKgbwXjaFwD84HUDUxNvt5yui/VMIWYuDDYrqZlvykwQHVE5NUg KHjl2b1zFsp6uL80sZCJuOJauXg8nKmE4rq6iji7Q0t8TD1kxV6PxTLeGZaqJtMh5o hHhHMalE6nD0CFhW4R8HHFMVJcWpu+4rr4sCSmn5dX7pkTTe0glm5Y67Xuej1vLaKt xtxWKga9hHewQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NjcK52Skjz9rxL; Thu, 29 Dec 2022 19:26:01 +0100 (CET) In-Reply-To: <831qoi85u7.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Dec 2022 19:42:08 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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.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:302056 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Philip Kaludercic >> Date: Thu, 29 Dec 2022 17:08:09 +0000 >> >> The issue has been discussed before, but I failed to understand the >> point of duplicating a lot of modes > > 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? >> or creating new modes that depend >> on tree-sitter and that don't work or even try to provide some fall-back >> if the library is not available. > > 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. Sure, if I have the parser installed use that, but otherwise it would be preferable if instead of giving up with a warning the keyword list is extracted from `dockerfile-ts-mode--font-lock-settings' and converted into something that is useful even if I don't have tree-sitter configured. And this doesn't just apply to this mode. > Besides, we've lived this far without major modes > for those languages, so adding a tree-sitter based one cannot possibly > do any harm, it can only make things better for Emacs. With the exception that a warning is generated, popping up a new window, which is distracting. >> 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. --=-=-= Content-Type: text/plain Content-Disposition: inline diff --git a/lisp/progmodes/dockerfile-ts-mode.el b/lisp/progmodes/dockerfile-ts-mode.el index 40d90cc2df..99fea26c94 100644 --- a/lisp/progmodes/dockerfile-ts-mode.el +++ b/lisp/progmodes/dockerfile-ts-mode.el @@ -141,36 +141,24 @@ dockerfile-ts-mode--imenu-1 ;;;###autoload (define-derived-mode dockerfile-ts-mode prog-mode "Dockerfile" "Major mode for editing Dockerfiles, powered by tree-sitter." + :tree-sitter-settings treesit-font-lock-settings + :tree-sitter-features '((comment) + (keyword string) + (image-spec number) + (bracket delimiter error operator)) + :tree-sitter-indent dockerfile-ts-mode--indent-rules :group 'dockerfile :syntax-table dockerfile-ts-mode--syntax-table - (when (treesit-ready-p 'dockerfile) - (treesit-parser-create 'dockerfile) - - ;; Comments. - (setq-local comment-start "# ") - (setq-local comment-end "") - (setq-local comment-start-skip (rx "#" (* (syntax whitespace)))) - - ;; Imenu. - (setq-local imenu-create-index-function - #'dockerfile-ts-mode--imenu) - (setq-local which-func-functions nil) - - ;; Indent. - (setq-local treesit-simple-indent-rules - dockerfile-ts-mode--indent-rules) - - ;; Font-lock. - (setq-local treesit-font-lock-settings - dockerfile-ts-mode--font-lock-settings) - (setq-local treesit-font-lock-feature-list - '((comment) - (keyword string) - (image-spec number) - (bracket delimiter error operator))) - - (treesit-major-mode-setup))) + ;; Comments. + (setq-local comment-start "# ") + (setq-local comment-end "") + (setq-local comment-start-skip (rx "#" (* (syntax whitespace)))) + + ;; Imenu + (setq-local imenu-create-index-function + #'dockerfile-ts-mode--imenu) + (setq-local which-func-functions nil)) (provide 'dockerfile-ts-mode) --=-=-= Content-Type: text/plain 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. 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. --=-=-=--