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: Wed, 10 Jan 2024 15:51:38 +0000 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> 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="8979"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Monnier , 68246@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 10 16:52:21 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 1rNasO-0002Cm-Dq for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Jan 2024 16:52:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNas9-00009e-5v; Wed, 10 Jan 2024 10:52:05 -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 1rNas7-00009N-JK for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 10:52:03 -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 1rNas7-0004Z8-9z for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 10:52:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rNas5-0003Vj-OH for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 10:52: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: Wed, 10 Jan 2024 15:52: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.170490191913486 (code B ref 68246); Wed, 10 Jan 2024 15:52:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 15:51:59 +0000 Original-Received: from localhost ([127.0.0.1]:42541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNas2-0003VR-L5 for submit@debbugs.gnu.org; Wed, 10 Jan 2024 10:51:59 -0500 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:49317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNarz-0003VB-4w for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 10:51:57 -0500 Original-Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cd053d5683so51458461fa.2 for <68246@debbugs.gnu.org>; Wed, 10 Jan 2024 07:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704901910; x=1705506710; 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=65iiwI2/L8YFzJf5ch97/iNZ4joNiMRzHUOsOUVnekE=; b=LX60vt7k59eZqYzfZxPuEcLccle/chCPxWvBxBErxNQfmswSSCZhDvviG8tYv1OBT5 /6P9a+s1FqSGeOy4x65sZfb7hJq1OUSxhVfRR6wsGucNzY41mi5wWxxQApbY17gZQgJ0 tTY9yV806Z3AR64slTC/DQ9Senpf1eUgtT8iidWSIgaO14K06BEPrt65l3P7Gv9B2wnJ 9j/ZzGIjOjGa/mKA/1QA4xcv4Q16qLMIFLoiTpq9pPgkk+/8glDEfvXEuvlMG77At5wN nZapsHKIXUHlfN5pVcChorYhPh8b08OctEJCEOd6vl7fq8jkjgiiYbtJzMOZ+4e/iXyS BsaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704901910; x=1705506710; 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=65iiwI2/L8YFzJf5ch97/iNZ4joNiMRzHUOsOUVnekE=; b=kCjSBjSMeKvE/5TdBK6sZSBJQleunDOoVSGhiZcaWnWQOuzFWID1WHE1kt+d48D9PQ sU8LTBLTK4OwYFd+0a+7/xjYuwIijbERIKexrHs9HmW5pStlsRV7qFTgtML4eVYu8qMm Hnm3iuPI1NeZAKCTCU6FV7d8ATHcq/zLgqdgbETjRh1QKiv8f51SNvymn4weBHidHFtG h2hi7CdvmyqZsdk9CeqcxS1CqVZJ53QKIAAwZV4lWUUa6x6tqighqFKNYpxmF8IKIlso spbFZhAPbuUZtiFUOTFJAXdAsVd8XZFJTbdXDkMLvWp1TIA7kpInoAJqg0tkcRGu/hKN Ud0g== X-Gm-Message-State: AOJu0YxFMgPAPUeFFpd2GreVEZ/zdso+wS1+uImMlDOA5faN7AN6LjEL KXPUc3YoxhfTG8CWkXd/nnHR2pBkczcY6Y3ggDVJmisf X-Google-Smtp-Source: AGHT+IEuqwiTBMAMPdZGQnEV8r1CUiMVFG8a8N6axnFaPO83xfe0eU3rwJ9myLh4PwmTDXm65tweNvfJn0yC5fKbpw8= X-Received: by 2002:a2e:a284:0:b0:2cc:eefc:20af with SMTP id k4-20020a2ea284000000b002cceefc20afmr539174lja.52.1704901910155; Wed, 10 Jan 2024 07:51:50 -0800 (PST) In-Reply-To: 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:277767 Archived-At: On Wed, Jan 10, 2024 at 6:24=E2=80=AFAM Stefan Kangas wrote: > I.e. the difference is: > > (derived-mode-p 'foo-mode) vs (language-for-mode-p 'foo) > Monnier T=C3=A1vora > > Either of those would answer the question "does the current buffer > contain language FOO". The former reuses the old taxonomy, the right > introduces a new one. Yes, but the on on the right looks more like (cl-defun get-language-for-mode &optional (mode major-mode) ...) i.e. it's not a boolean predicate. You can make one with it, of course. > Basically, the biggest weakness of Stefan M's solution is the biggest > strength of Jo=C3=A3o's and vice versa: "backwards-compatibility" (if we = can > call it that) vs "clean taxonomy". Indeed I think it's important to clearly state what "backwards compatibility" we're trying to solve here. What exactly was "broken" after the introduction of TS modes? We could answer "nothing, the TS modes were new things!" Or we could answer "some things, because in some situations the user is led mode or less easily to use the new mode and her configs for the old mode don't apply" I believe Stefan and Eli and using the second interpretation. Fine, that's perfectly fine. They are actively trying to fix this breakage. Also fine. Importantly, I think it's important to quantify how many "things" were broken. In the beginning of this discussion, I saw references to Eglot and Yasnippet. Then CEDET, then lsp-mode, then ffap. I know very well what's going on with the first two, but not the others. Does anyone? It's important to have an overview of what is broken where, and if it's in the Emacs tree, in the ELPAs, or elsewhere entirely. We also know the problem is already mostly fixed in places like Eglot and lsp-mode. Elegantly? Manifestly not, but it's "no worse" than what was in place pre-TS-modes. Can we do better for Emacs 30 (or Emacs 29 + compat.el)? Probably yes. 1. We could have more "base" modes like we already have and keep the relative simplicity of simple inheritance. 2. We could have a new concept of "language" that is a non-nil property of _some_ major modes. With this new concept a number of new useful features are being speculated (for example language-specific hooks, a friendly dialog for beginners looking to use a specific language, etc). But these new features are not essential to "fixing the breakage". The concept of "content type" works just as well here, IMO. Also, it has been pointed out that the existing major-mode-remap-alist could be used for this. I agree, but it should come with accessors and be localized to to define-derived-mode anyway. 3. We could have this special concept of extra parents so that any existing derived-mode-p call does what we thing is the right from here on. All valid alternatives, but I'm surprised option 3 is such a strong candidate, since it requires exposing the user to a non-trivial concept. The symbol "-mode" would be promoted to designate something like a "meta-mode" (I also called "family" earlier) where the current major mode might be 'derived-mode-p' from it but the concrete-mode's hooks and body is not run. Interesting as this is (Stefan M made a defense of it based on practices in other packages), I think it's just too strong of a hammer to use here, and at least a minor headache in terms of docstrings. Jo=C3=A3o