From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Unifying "foo-mode"s and "foo-ts-mode"s Date: Fri, 30 Dec 2022 14:19:30 +0100 Message-ID: <87tu1dowpp.fsf@thornhill.no> References: <877cyagmti.fsf@posteo.net> <831qoi85u7.fsf@gnu.org> <87mt76f4n4.fsf@posteo.net> <83sfgy6l0n.fsf@gnu.org> <877cy9b1k0.fsf_-_@posteo.net> <87wn69oy1c.fsf@thornhill.no> <87edsh9gzn.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35077"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, Yuan Fu To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 30 14:20:22 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 1pBFJ6-0008uf-Vb for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Dec 2022 14:20:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBFIS-00078W-Jp; Fri, 30 Dec 2022 08:19:40 -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 1pBFIR-00078O-Hc for emacs-devel@gnu.org; Fri, 30 Dec 2022 08:19:39 -0500 Original-Received: from out-109.mta0.migadu.com ([91.218.175.109]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBFIO-0004DR-UI for emacs-devel@gnu.org; Fri, 30 Dec 2022 08:19:39 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1672406373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XLtL+MEn98KcYhAFM05qjMNVvEn8GNwmVQeiYCy+L/4=; b=RJqg7AyUVpSePjidMmyckulGDYcZJd9aMdRJcD0iDToZS4A/oSUKrkuJMvVVXf2U9GhTAU KA127hiWVqmtdzQ/la2iu8moyypUyFxQhz7QOJNBh0KalAC8GpgpQSmJUBd0zxZFm8dWhe SW79OrMFoXeT7SRlILRw5YUyeSBEkQ3oP/jMlvCGoEXJ7cI5tuw+NIrEoPyeaprY+Bq9tN tfs0iFQde4xwnQr8LFaCy07fHEbVgUJnk0jHKYKMzN+YPL9Zq1YIuAI/tOy/BBXJ31upNh YlHJ/RH4QJ6VrZEmEMOVCAVbdt75ahwifLwZUfYUnx4IgMlCCmKws+KdNjGZdg== In-Reply-To: <87edsh9gzn.fsf@posteo.net> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=91.218.175.109; envelope-from=theo@thornhill.no; helo=out-109.mta0.migadu.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, 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:302103 Archived-At: Philip Kaludercic writes: > Theodor Thornhill writes: > >> Philip Kaludercic writes: >> >>> Eli Zaretskii writes: >>> >>>> 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? >>> >>> I have attached a sketch of my proposal with support for Python. >>> Instead of a separate python-ts-mode, we regulate tree-sitter support >>> using a user option `treesit-enabled-modes'. It can either be a list >>> >> >> [...] >> >> IIUC this will make all other config run before the treesit-related >> code? > > If that is the problem, that we can solve that by re-adjusting the order > in which the expanded code occurs. > >> In that case I think this cannot work, because we _don't_ want to >> set all the before/after-change functions many modes set, for example. > > What exactly is the issue here? Can't we overwrite it again if > necessary? > For example the CC modes set up lots of functions in the mode init, many of which override things like '*-function' variables, that if either not overriden explicitly by a treesit alternative or removed before mode init will impact performance. There are some modes that will be worse in this regard than others, but one of my earlier suggestions was to just: (define-derived-mode foo ........ (cond (use-treesit-p (init-all-the-treesit-stuff)) (use-hypothetical-future-thing (init-all-the-hypothetical-future-stuff)) (t (init-all-the-other-stuff)))) In this case we don't let any code bleed in between the modes, which IMO is necessary. At least we should be very careful with _when_ it is ok for such settings to bleed in. Things like comment-start/end etc can bleed in just fine, but stuff like ``` (c-init-language-vars js-mode) (setq-local indent-line-function #'js-indent-line) (setq-local beginning-of-defun-function #'js-beginning-of-defun) (setq-local end-of-defun-function #'js-end-of-defun) (setq-local open-paren-in-column-0-is-defun-start nil) (setq-local font-lock-defaults (list js--font-lock-keywords nil nil nil nil '(font-lock-syntactic-face-function . js-font-lock-syntactic-face-function))) (setq-local syntax-propertize-function #'js-syntax-propertize) (add-hook 'syntax-propertize-extend-region-functions #'syntax-propertize-multiline 'append 'local) (add-hook 'syntax-propertize-extend-region-functions #'js--syntax-propertize-extend-region 'append 'local) (setq-local prettify-symbols-alist js--prettify-symbols-alist) (setq-local parse-sexp-ignore-comments t) (setq-local which-func-imenu-joiner-function #'js--which-func-joiner) ``` Should absolutely not. Does that make sense? I don't think this is impossible, but my biggest argument was that we need to keep things distinct, or at least be very explicit on when we share code. Theo