From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Sat, 6 Jan 2024 14:54:49 +0000 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> Mime-Version: 1.0 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="17810"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 06 15:56:27 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rM864-0004SS-Ag for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 15:56:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rM85e-0001YH-P4; Sat, 06 Jan 2024 09:55:58 -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 1rM85d-0001Xx-8k for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 09:55:57 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rM85d-00074L-0P for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 09:55:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rM85h-0001E3-Uq for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 09:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jan 2024 14:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68246 X-GNU-PR-Package: emacs Original-Received: via spool by 68246-submit@debbugs.gnu.org id=B68246.17045529143565 (code B ref 68246); Sat, 06 Jan 2024 14:56:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 14:55:14 +0000 Original-Received: from localhost ([127.0.0.1]:58977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM84w-0000vG-9f for submit@debbugs.gnu.org; Sat, 06 Jan 2024 09:55:14 -0500 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:55452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM84v-0000uI-2g for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 09:55:13 -0500 Original-Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-50ea226bda8so472863e87.2 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 06:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704552902; x=1705157702; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tJx+twFCbhx4bOCS+NmDQHIlb4Jqfa25eJVge2KkQ2c=; b=nsGxN5MOp0y2j0WZmuJGBzU1y5JbDswBO5fGm5ZXzBi0IVwNb/jLowNHfO2IgAaSRr eMgfwdrjTDi9ZvKdN/jx3Sipt5Ppy/FwZ5rfQf2OK8vSBt9NFH2k1gQTtU17ekfRJJHS 6q/K5yIGlhQaJeRvQyeHh25ETsNCx0C7xEGHFBEFPXdv5TyOVjQHPYAvIarnur89u94H 6ugasrtEyxv09RgqjawA2LRClO3E2hwPL4VpziDJNfm8hqJBNQqRTKhGqwAYaomD+neF Tm6zKOAuWs+GNrDT6XJPHZ6fxVMy3d1c3Zi7VkJ/7EI8aKeeI6qY2Cpt/83/x4eJ6fNQ j23w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704552902; x=1705157702; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tJx+twFCbhx4bOCS+NmDQHIlb4Jqfa25eJVge2KkQ2c=; b=mY6Q2zxcV/0LRhJzQxL5+u4iifJTRlCiaS6GjlNO6qaAVDIBA5uhlw6DleVThTyTfq 5FUzMHoAchukw6RJfPhh3+Rl7bHpmlUlIOPbzk+y91N6hkWrf46PE89+922elO55TCMf csoXdfXBMdg5kA34DqeYU4i54B+GXXtNyrxLalHEq7p6v9pDAKWhVEeyxKWhE0MAZSUF Mab05HR74C9/YLMTfHzHsK92dXEw5/GQH4KLU6RvIquBY/Gyyd7RvGJUBRCBh6X3TBL0 ZlirEUCV+7oTuVZjhYGPQ9Ojg4izvKskNW2CLcuUPpwkvIknlH9pFPSwDSYTxfROnRfi kW6w== X-Gm-Message-State: AOJu0YwYMSUkU1fRMR8lktqmTPKxx0PmmPrJfGJKmEkTJ32zjPa0K2pq vClfoSK8kiH8CDHPr27Zn2oqQpl0A8OXMtpCn8Y= X-Google-Smtp-Source: AGHT+IGVRj50zsZUfUZzIxeDugUVfZQQv5vJIw8ZzEn2/EbUg8UMUMe8cFpm9o/7VtaEHMRB6vMDLWg2CvFaWEsTB3A= X-Received: by 2002:a05:6512:312d:b0:50e:7224:ad4f with SMTP id p13-20020a056512312d00b0050e7224ad4fmr306463lfd.59.1704552901866; Sat, 06 Jan 2024 06:55:01 -0800 (PST) In-Reply-To: <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277467 Archived-At: On Sat, Jan 6, 2024 at 3:19=E2=80=AFAM Yuan Fu wrote: > > I certainly welcome base-mode, I=E2=80=99m the one that added them in the= first place. But I also want to point out that they are only a partial sol= ution. For one, adding the base mode needs cooperation from all the major m= ode authors. For built-in modes, that=E2=80=99s not a (big) problem; for co= untless third-party modes out there, I don=E2=80=99t have high hopes for it= . I don't think this is such a serious problem. Ultimately, the affected party aren't major modes themselves, it's the minor modes that base decisions on 'major-mode' variables and derived-mode-p. So far examples are Eglot and Yasnippet (some unknown way in CEDET). Expressing the "foo-ts-mode" to "foo-mode" relation directly in these minor modes isn't really hard, in fact Eglot already does it for something completely different that Stefan's patch wouldn't be able to fix anyway: (or language-id (or (get sym 'eglot-language-id) (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym)))) This is hacky but it works fine. To do better, we would need an abstraction like (get-mode-family major-mode) So, personally I think Stefan's patch a rather heavy hammer to fix something that has many alternatives. > The good thing about derived-mode-add-parents is that it doesn=E2=80=99t = need major > mode author=E2=80=99s cooperation. Even a normal user can do it themselve= s. Yes, precisely that's good. I actually think derived-mode-remove-parents is more useful, as it would fix a real bug (bug#67463) that doesn't seem to have _any_ other solution. > Then there is the problem Eli pointed out, base-mode hooks runs before ch= ild major mode body does. It=E2=80=99s probably fine for most of the things= , but if you want to change some buffer local variable that the major mode = sets, base-mode hook can=E2=80=99t help. (Arguable a niche use-case, but my= point is base-mode hooks have their limits.) As Dmitry pointed out, this is so for normal inheritance. It's not really a problem of the mechanism itself. > As for adding xxx-mode to xxx-ts-mode=E2=80=99s parent, I think it=E2=80= =99s fine? Like others in the thread, I couldn=E2=80=99t think of a scenari= os where this will be problematic. I thought about adding xxx-lang as the p= arent of both xxx-mode and xxx-ts-mode, but that=E2=80=99s probably not ver= y helpful, since the goal is to make things work for ts-mode without needin= g to change the existing code, and using xxx-lang still requires modifying = existing code. Dunno if problematic, time will tell. I have run into "endless cycle" problems with bad derived-mode-p in the past. Granted, these were all bugs in my code, since fixed. Above all I think it's a bit akward for users to grasp this whereas a cleaner "file type registry/language family" or some other cleaner concept seems more solid. But maybe if I squint very hard and try to think of a (single?) "extra parent" as the "language family", maybe it will work flawlessly. Regardless I still think the concept of "language id", "file type" or "family" or whatever should be described somewhere and linked to our particular implementation of it, currently based on "extra parenting".