From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Extending define-derived-mode Date: Mon, 5 Jun 2023 00:31:02 -0700 Message-ID: <85BA8FC1-148C-438B-877A-A06CDCCDE1BF@gmail.com> References: <20F07C52-6B39-4B24-8433-82E2226EADA6@gmail.com> <83zg5mf62s.fsf@gnu.org> <835y87elec.fsf@gnu.org> <83ilc6axl9.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel , Mickey Petersen , Theodor Thornhill , dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 05 09:32:06 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 1q64hC-00097V-12 for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Jun 2023 09:32:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q64gT-0005bB-AW; Mon, 05 Jun 2023 03:31:21 -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 1q64gR-0005b1-47 for emacs-devel@gnu.org; Mon, 05 Jun 2023 03:31:19 -0400 Original-Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q64gP-0003AP-1e; Mon, 05 Jun 2023 03:31:18 -0400 Original-Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-390723f815fso2286333b6e.3; Mon, 05 Jun 2023 00:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685950274; x=1688542274; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qx4qsDvwhY1fCoiwFHlTwt2hxON9GFozX3nlbTVsV5Y=; b=cnzyP0KM6lRj9gckXCMRk2VhPXqogsLmratGVAxteIYQ9a38aDY2wVzcrjomYqeGZb VfN3ZbOOseSvTR49SLo07ogJZksDQDWYDTOLRKOo7a1Lso31lSweCLHZGUxZHguDcy/1 zuSHqRV6QaKTp8flcbm2Bwa79tZL8lvEsCuu023BvUZuX6MjUCKZuFXR7Lii512z+AUi 4UPlNYuKEUKQBSZvRxoP6FVQEbFZGFP87Tg0yirjlGs+Sqs9Ovb8MCFZtJKFieOsHrOV 9Tdr86wJEyHwW9mJB1RWZEkXk0av+21h9+8wpLpQAEQWAcDDVxY+KkiVTJWdN8yW35VW PFpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685950274; x=1688542274; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qx4qsDvwhY1fCoiwFHlTwt2hxON9GFozX3nlbTVsV5Y=; b=Xelc5z2riYBnPe7y7RgAHLVG+w6vNeGfPyI2cqfbMllYY4E8dUcPcL2X164rCwMYWg qnmE6bCoxsQX36v3GyT9jBlYucZ7gK7OHXMONVCA5/a1tz1Q7JlJdR9AAEovzX9Z+nP6 wAIGSrJbDpoJWwr9SMepRX39a8HclI19TkTqdkJU4DY6gBjBLdtSmCFFZA2eqPMEd/r3 nz+xuOoCazRHF9Is319lDYUsm255p0YhkrW7X25r3556zO3a7G6QPa9D/jQM4wbGZqTc ildNUlOTz0Lq8kzee09ue12+Nl266Fnq30dUFYjJdtYnstSmQVlOlb6koydhz/AvDCO7 JCIg== X-Gm-Message-State: AC+VfDwMaKJGuAGFW7wX7Hk7IDsU+ZRKIyeLOWDlLm/XzpxEjjwqm4Vb ugnr1eWQrYCQV5H1I+WrdO5wgjH9CS8= X-Google-Smtp-Source: ACHHUZ6qZHu8GS0VEquAjQShFxD0NIdhPgVi/2lPQDbfZyp/rCRwCo4Php3Wu2vRcwLzTQzeMM2dlg== X-Received: by 2002:a05:6358:bd19:b0:129:c526:bddb with SMTP id dh25-20020a056358bd1900b00129c526bddbmr805757rwb.13.1685950274464; Mon, 05 Jun 2023 00:31:14 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id l184-20020a6325c1000000b0053fbacdaf59sm5118259pgl.69.2023.06.05.00.31.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2023 00:31:14 -0700 (PDT) In-Reply-To: <83ilc6axl9.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.600.7) Received-SPF: pass client-ip=2607:f8b0:4864:20::22a; envelope-from=casouri@gmail.com; helo=mail-oi1-x22a.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:306635 Archived-At: > On Jun 2, 2023, at 4:54 AM, Eli Zaretskii wrote: >=20 >> 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 >>=20 >>> 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. >>=20 >> I fully agree. Note thought that I wasn=E2=80=99t saying ts and = non-ts modes should accept the same set of configs. I know all-too-well = that=E2=80=99s 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.=20 >=20 > 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. I=E2=80=99m talking about sharing the sharable config. Electric modes = already work the same in ts and non-ts modes: electric-pair-mode and = electric-quote-mode inserts matching pairs and quotes and aren=E2=80=99t = affected by tree-sitter, electric-indent-mode uses the standard = indent-line-function which both ts and non-ts modes confront to. Is = there any other electric modes? Also, ts modes generally have the same syntax table as non-ts modes. So = if some package uses the syntax table they are largely not affected = either. Yuan