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: Extending define-derived-mode Date: Fri, 02 Jun 2023 14:54:26 +0300 Message-ID: <83ilc6axl9.fsf@gnu.org> References: <20F07C52-6B39-4B24-8433-82E2226EADA6@gmail.com> <83zg5mf62s.fsf@gnu.org> <835y87elec.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11076"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, mickey@masteringemacs.org, theo@thornhill.no, dgutov@yandex.ru To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 02 13:54:31 2023 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 1q53MV-0002dU-3v for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Jun 2023 13:54:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q53Lv-0001g5-Ef; Fri, 02 Jun 2023 07:53:55 -0400 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 1q53Li-00016E-G5 for emacs-devel@gnu.org; Fri, 02 Jun 2023 07:53:46 -0400 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 1q53Lf-0007NC-9p; Fri, 02 Jun 2023 07:53:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=9/s2hZIN6swVFzf5gf+/WmOtTHxy4tn9CXeGjtvm7TE=; b=Dzl8l+OzbP7+yzbMss55 LiU30lphGYYkGvrcrOWQwPYpe7Tx5etMnsLA2mUJrkWtVfipy2O/lC1v1zC9tyls49Zu6W5yFlxym lIVeqXkyhne5CLh80BRrDGLPNK8hJnQ4XcTnqdg4Z1rfg0pEOsnyNzXOZ5sOMxx6y0C19wSTlVeK0 x91ZJfxkBq5gJ5y5MiHo4bQvOSnYKaAn2lwEJFkrE3VrzzqScFJxns+TVK8o9xI0r+ZKK+f8ZUUjz VU/iZRRNRAHr8i7NJkurzss3ZdVV+9gKb8vYeuZUqf2TB6+gmoyY93+L6fCgXvhJIPzsL0BkCXMmV +7gfYc2RsIaq9g==; 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 1q53Le-0007l5-G3; Fri, 02 Jun 2023 07:53:39 -0400 In-Reply-To: (message from Yuan Fu on Fri, 2 Jun 2023 00:50:07 -0700) 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:306552 Archived-At: > From: Yuan Fu > Date: Fri, 2 Jun 2023 00:50:07 -0700 > Cc: Stefan Monnier , > emacs-devel@gnu.org, > mickey@masteringemacs.org, > theo@thornhill.no, > dgutov@yandex.ru > > > It's a good point, indeed, but with some mode pairs is very hard > > (read: impossible) to achieve. A notable example is c-mode and > > c-ts-mode: the former has a lot of mode-specific commands and features > > that cannot be used with the latter, because there's no equivalent > > infrastructure that supports the same interfaces, and sometimes > > because the feature makes no sense in a TS-based mode. We try very > > hard to use the same key bindings and variable names where it does > > make sense, but the group of features where that is possible is very > > small. For example, all the enormous set of features we have in CC > > mode around indentation and its customization cannot be "ported" to > > c-ts-mode and c++-ts-mode, because the latter is built on completely > > different analysis of the text. Another example is the ad-hoc support > > for some frequently-use macro names that CC mode has. > > I fully agree. Note thought that I wasn’t saying ts and non-ts modes should accept the same set of configs. I know all-too-well that’s impossible (for the majority of modes). I was saying that sometimes there are configs that can be shared (enabling electric-quote-local-mode, for example), and it would be nice to put them in a single hook rather than duplicating the code in two hooks. For users to be able to share stuff like electric-quote-local-mode we'd need to rewrite those supporting modes to allow that. When one of the two modes uses regexps and syntax tables, whereas the other uses treesit-based parsers, this is not a trivial task. I invite you to audit the various electric modes we have and see how many of them can be shared with minimum effort between non-TS and TS modes.