From unknown Sun Jul 20 14:10:14 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#68246 <68246@debbugs.gnu.org> To: bug#68246 <68246@debbugs.gnu.org> Subject: Status: 30.0.50; Add non-TS mode as extra parent of TS modes Reply-To: bug#68246 <68246@debbugs.gnu.org> Date: Sun, 20 Jul 2025 21:10:14 +0000 retitle 68246 30.0.50; Add non-TS mode as extra parent of TS modes reassign 68246 emacs submitter 68246 Stefan Monnier severity 68246 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 17:11:51 2024 Received: (at submit) by debbugs.gnu.org; 4 Jan 2024 22:11:51 +0000 Received: from localhost ([127.0.0.1]:55873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLVwM-00011o-Fb for submit@debbugs.gnu.org; Thu, 04 Jan 2024 17:11:51 -0500 Received: from lists.gnu.org ([2001:470:142::17]:54942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLVwI-00011W-W5 for submit@debbugs.gnu.org; Thu, 04 Jan 2024 17:11:49 -0500 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 1rLVw9-0000h1-Am for bug-gnu-emacs@gnu.org; Thu, 04 Jan 2024 17:11:37 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLVw6-00053I-UE for bug-gnu-emacs@gnu.org; Thu, 04 Jan 2024 17:11:37 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 76A31441C07 for ; Thu, 4 Jan 2024 17:11:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704406289; bh=Xg972bFY/cv2BiXz5jkdcT9cpnqJ6jd1frjShOZ4ymc=; h=From:To:Subject:Date:From; b=A93MZfCfOwAnqAXWT4TcN4+Q37E77wk8MjrKXwZlz1QK6UKQc1oGrBMXTk2lfA4PG IyYhk9b2zT5KcAIy3QoBB8BFM1FMaXxDgXNQypIBocTAI+ZDvjZdmot2hyNzoWwxK/ TI6jh1pVAEaDLXr8+wctRzNOgpLG0XnWN+73INKLDbFLNslY3IPM/w/WI3tG6XB2Ws t2cV8qblEgghFKH4PcQ9pM+1nU9QLa93H4AmdJx/42ra9FZ+Ddtgo3h7Jbd+LwWQaY q0uWOWGW+8bi4HhWQoJGhpo+GlgV/HiN90qTeblJNRyc47PfhuxpfiIjuNkdj2cBbS /mWCnmNMNC2Aw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CC881441429 for ; Thu, 4 Jan 2024 17:11:29 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B08C012023C for ; Thu, 4 Jan 2024 17:11:29 -0500 (EST) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Add non-TS mode as extra parent of TS modes X-Debbugs-Cc: monnier@iro.umontreal.ca Date: Thu, 04 Jan 2024 17:11:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.184 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Package: Emacs Version: 30.0.50 Many packages use the `major-mode` as a proxy for the type of content in the buffer. When using the new TS modes, these packages tend to behave poorly because they do not understand that a buffer in `js-ts-mode` contains Javascript. I suggest we add the non-TS mode as an extra parent, so `derived-mode-all-parents` includes `js-mode` in `js-ts-mode`. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=ts-parents.patch diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index e5835bdb62d..461218cbb7d 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -1314,6 +1314,8 @@ c-ts-mode (lambda (_pos) 'c)) (treesit-font-lock-recompute-features '(emacs-devel))))) +(derived-mode-add-parents 'c-ts-mode '(c-mode)) + ;;;###autoload (define-derived-mode c++-ts-mode c-ts-base-mode "C++" "Major mode for editing C++, powered by tree-sitter. @@ -1357,6 +1359,8 @@ c++-ts-mode (setq-local add-log-current-defun-function #'c-ts-mode--emacs-current-defun-name)))) +(derived-mode-add-parents 'c++-ts-mode '(c++-mode)) + (easy-menu-define c-ts-mode-menu (list c-ts-mode-map c++-ts-mode-map) "Menu for `c-ts-mode' and `c++-ts-mode'." '("C/C++" diff --git a/lisp/progmodes/cmake-ts-mode.el b/lisp/progmodes/cmake-ts-mode.el index d933e4ebb81..2a185fb0aa2 100644 --- a/lisp/progmodes/cmake-ts-mode.el +++ b/lisp/progmodes/cmake-ts-mode.el @@ -261,6 +261,8 @@ cmake-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'cmake-ts-mode '(cmake-mode)) + (if (treesit-ready-p 'cmake) (add-to-list 'auto-mode-alist '("\\(?:CMakeLists\\.txt\\|\\.cmake\\)\\'" . cmake-ts-mode))) diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el index 7bf57bcbe21..18114d08528 100644 --- a/lisp/progmodes/csharp-mode.el +++ b/lisp/progmodes/csharp-mode.el @@ -998,6 +998,8 @@ csharp-ts-mode (add-to-list 'auto-mode-alist '("\\.cs\\'" . csharp-ts-mode))) +(derived-mode-add-parents 'csharp-ts-mode '(csharp-mode)) + (provide 'csharp-mode) ;;; csharp-mode.el ends here diff --git a/lisp/progmodes/dockerfile-ts-mode.el b/lisp/progmodes/dockerfile-ts-mode.el index 334f3064d98..618082cfe7a 100644 --- a/lisp/progmodes/dockerfile-ts-mode.el +++ b/lisp/progmodes/dockerfile-ts-mode.el @@ -190,6 +190,8 @@ dockerfile-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'dockerfile-ts-mode '(dockerfile-mode)) + (if (treesit-ready-p 'dockerfile) (add-to-list 'auto-mode-alist ;; NOTE: We can't use `rx' here, as it breaks bootstrap. diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mode.el index b493195eedd..9a819f5df0c 100644 --- a/lisp/progmodes/elixir-ts-mode.el +++ b/lisp/progmodes/elixir-ts-mode.el @@ -745,6 +745,8 @@ elixir-ts-mode (treesit-major-mode-setup) (setq-local syntax-propertize-function #'elixir-ts--syntax-propertize))) +(derived-mode-add-parents 'elixir-ts-mode '(elixir-mode)) + (if (treesit-ready-p 'elixir) (progn (add-to-list 'auto-mode-alist '("\\.elixir\\'" . elixir-ts-mode)) diff --git a/lisp/progmodes/go-ts-mode.el b/lisp/progmodes/go-ts-mode.el index 65adc1c55ea..e16459cd975 100644 --- a/lisp/progmodes/go-ts-mode.el +++ b/lisp/progmodes/go-ts-mode.el @@ -261,6 +261,8 @@ go-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'go-ts-mode '(go-mode)) + (if (treesit-ready-p 'go) (add-to-list 'auto-mode-alist '("\\.go\\'" . go-ts-mode))) @@ -437,6 +439,9 @@ go-mod-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'go-mode-ts-mode '(go-mod-mode)) + + (if (treesit-ready-p 'gomod) (add-to-list 'auto-mode-alist '("/go\\.mod\\'" . go-mod-ts-mode))) diff --git a/lisp/progmodes/heex-ts-mode.el b/lisp/progmodes/heex-ts-mode.el index 7b53a44deb2..702610bc1eb 100644 --- a/lisp/progmodes/heex-ts-mode.el +++ b/lisp/progmodes/heex-ts-mode.el @@ -177,6 +177,8 @@ heex-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'heex-ts-mode '(heex-mode)) + (if (treesit-ready-p 'heex) ;; Both .heex and the deprecated .leex files should work ;; with the tree-sitter-heex grammar. diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el index 0b1ac49b99f..51e0eeef79a 100644 --- a/lisp/progmodes/java-ts-mode.el +++ b/lisp/progmodes/java-ts-mode.el @@ -401,6 +401,8 @@ java-ts-mode ("Method" "\\`method_declaration\\'" nil nil))) (treesit-major-mode-setup)) +(derived-mode-add-parents 'java-ts-mode '(java-mode)) + (if (treesit-ready-p 'java) (add-to-list 'auto-mode-alist '("\\.java\\'" . java-ts-mode))) diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el index 0115feb0e97..2420bdde50a 100644 --- a/lisp/progmodes/js.el +++ b/lisp/progmodes/js.el @@ -3898,6 +3898,8 @@ js-ts-mode (add-to-list 'auto-mode-alist '("\\(\\.js[mx]\\|\\.har\\)\\'" . js-ts-mode)))) +(derived-mode-add-parents 'js-ts-mode '(js-mode)) + (defvar js-ts--s-p-query (when (treesit-available-p) (treesit-query-compile 'javascript diff --git a/lisp/progmodes/json-ts-mode.el b/lisp/progmodes/json-ts-mode.el index 32bc10bbda9..1fb96555010 100644 --- a/lisp/progmodes/json-ts-mode.el +++ b/lisp/progmodes/json-ts-mode.el @@ -164,6 +164,8 @@ json-ts-mode (treesit-major-mode-setup)) +(derived-mode-add-parents 'json-ts-mode '(json-mode)) + (if (treesit-ready-p 'json) (add-to-list 'auto-mode-alist '("\\.json\\'" . json-ts-mode))) diff --git a/lisp/progmodes/lua-ts-mode.el b/lisp/progmodes/lua-ts-mode.el index 3b600f59521..e81f05ff3cb 100644 --- a/lisp/progmodes/lua-ts-mode.el +++ b/lisp/progmodes/lua-ts-mode.el @@ -757,6 +757,8 @@ lua-ts-mode (add-hook 'flymake-diagnostic-functions #'lua-ts-flymake-luacheck nil 'local)) +(derived-mode-add-parents 'lua-ts-mode '(lua-mode)) + (when (treesit-ready-p 'lua) (add-to-list 'auto-mode-alist '("\\.lua\\'" . lua-ts-mode))) diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el index 1148da11a06..94a133b0688 100644 --- a/lisp/progmodes/python.el +++ b/lisp/progmodes/python.el @@ -6995,6 +6995,8 @@ python-ts-mode (add-to-list 'auto-mode-alist '("\\.py[iw]?\\'" . python-ts-mode)) (add-to-list 'interpreter-mode-alist '("python[0-9.]*" . python-ts-mode)))) +(derived-mode-add-parents 'python-ts-mode '(python-mode)) + ;;; Completion predicates for M-x ;; Commands that only make sense when editing Python code. (dolist (sym '(python-add-import diff --git a/lisp/progmodes/ruby-ts-mode.el b/lisp/progmodes/ruby-ts-mode.el index 598eaa461ff..7282d43e091 100644 --- a/lisp/progmodes/ruby-ts-mode.el +++ b/lisp/progmodes/ruby-ts-mode.el @@ -1196,6 +1196,8 @@ ruby-ts-mode (setq-local syntax-propertize-function #'ruby-ts--syntax-propertize)) +(derived-mode-add-parents 'ruby-ts-mode '(ruby-mode)) + (if (treesit-ready-p 'ruby) ;; Copied from ruby-mode.el. (add-to-list 'auto-mode-alist diff --git a/lisp/progmodes/rust-ts-mode.el b/lisp/progmodes/rust-ts-mode.el index c5fc57cc374..c67ac43e4d0 100644 --- a/lisp/progmodes/rust-ts-mode.el +++ b/lisp/progmodes/rust-ts-mode.el @@ -474,6 +474,8 @@ rust-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'rust-ts-mode '(rust-mode)) + (if (treesit-ready-p 'rust) (add-to-list 'auto-mode-alist '("\\.rs\\'" . rust-ts-mode))) diff --git a/lisp/progmodes/sh-script.el b/lisp/progmodes/sh-script.el index 0562415b4e5..e7e08fba1c9 100644 --- a/lisp/progmodes/sh-script.el +++ b/lisp/progmodes/sh-script.el @@ -1638,6 +1638,8 @@ bash-ts-mode (setq-local treesit-defun-type-regexp "function_definition") (treesit-major-mode-setup))) +(derived-mode-add-parents 'bash-ts-mode '(sh-mode)) + (advice-add 'bash-ts-mode :around #'sh--redirect-bash-ts-mode ;; Give it lower precedence than normal advice, so other ;; advices take precedence over it. diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el index e9c6afff440..83a3baaf5ef 100644 --- a/lisp/progmodes/typescript-ts-mode.el +++ b/lisp/progmodes/typescript-ts-mode.el @@ -491,6 +491,8 @@ typescript-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'typescript-ts-mode '(typescript-mode)) + (if (treesit-ready-p 'typescript) (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))) @@ -548,6 +550,8 @@ tsx-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'tsx-ts-mode '(tsx-mode)) + (defvar typescript-ts--s-p-query (when (treesit-available-p) (treesit-query-compile 'typescript diff --git a/lisp/textmodes/css-mode.el b/lisp/textmodes/css-mode.el index 425f3ec8a30..f5a20e0ca0e 100644 --- a/lisp/textmodes/css-mode.el +++ b/lisp/textmodes/css-mode.el @@ -1830,6 +1830,8 @@ css-ts-mode (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))) +(derived-mode-add-parents 'css-ts-mode '(css-mode)) + ;;;###autoload (define-derived-mode css-mode css-base-mode "CSS" "Major mode to edit Cascading Style Sheets (CSS). diff --git a/lisp/textmodes/html-ts-mode.el b/lisp/textmodes/html-ts-mode.el index 301f3e8791c..bf6c1307e96 100644 --- a/lisp/textmodes/html-ts-mode.el +++ b/lisp/textmodes/html-ts-mode.el @@ -123,6 +123,8 @@ html-ts-mode '(("Element" "\\`tag_name\\'" nil nil))) (treesit-major-mode-setup)) +(derived-mode-add-parents 'html-ts-mode '(html-mode)) + (if (treesit-ready-p 'html) (add-to-list 'auto-mode-alist '("\\.html\\'" . html-ts-mode))) diff --git a/lisp/textmodes/toml-ts-mode.el b/lisp/textmodes/toml-ts-mode.el index 1ba410045f5..1b621032f8a 100644 --- a/lisp/textmodes/toml-ts-mode.el +++ b/lisp/textmodes/toml-ts-mode.el @@ -153,6 +153,8 @@ toml-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'toml-ts-mode '(toml-mode)) + (if (treesit-ready-p 'toml) (add-to-list 'auto-mode-alist '("\\.toml\\'" . toml-ts-mode))) diff --git a/lisp/textmodes/yaml-ts-mode.el b/lisp/textmodes/yaml-ts-mode.el index 2b57b384300..854ce3ad456 100644 --- a/lisp/textmodes/yaml-ts-mode.el +++ b/lisp/textmodes/yaml-ts-mode.el @@ -143,6 +143,8 @@ yaml-ts-mode (treesit-major-mode-setup))) +(derived-mode-add-parents 'yaml-ts-mode '(yaml-mode)) + (if (treesit-ready-p 'yaml) (add-to-list 'auto-mode-alist '("\\.ya?ml\\'" . yaml-ts-mode))) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:02:50 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:02:50 +0000 Received: from localhost ([127.0.0.1]:55928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWje-0004M9-KG for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:02:50 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:49388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWjY-0004Lt-W7 for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:02:45 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cd053d5683so12335941fa.2 for <68246@debbugs.gnu.org>; Thu, 04 Jan 2024 15:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704409351; x=1705014151; 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=pCB7k6Luc7A8AMdQ0CB+wWM7Du2vwZP6vMW/kUuxP8k=; b=QIyIDdkYSMWAauNA3shQ0ENcdJTKfdWL16MTXzA499vKn3tsgoITR58L9CwciqeMIX JE5SVkoiy9/7C5fLC5hHU870I9WiNbhPNFUMUfKSbM93wDZ68HV82Fk3i8Q7lZc2oJPz wXmiJ99/phFZJTTY8rSOOQyN5Q3Brk/Qnl7d/18dlW2jrJNq70yxVs03jJ+E2ql0ekzv JSMKqIb1wJS2LgCdqtKlRm3b+PZq1pATGBDeqCsyCdbb1lig5uaj0QG1OI8dARVbj2Vj /6WkC2cIaL5idmLkFzfRsDizF6Vmdv0eKzS0/IxPsQBNYsFW9jjlD/uNdlio1qyDt/no behQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704409351; x=1705014151; 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=pCB7k6Luc7A8AMdQ0CB+wWM7Du2vwZP6vMW/kUuxP8k=; b=i8yew2SxN1fdYVWKvjXs9WBBzm8nkoEoY9lGvTuhgydg5rJH/Be4PGQJqhc7CIRqfB N/kAUTsjbR8QCAuVpat0d99Wa7kmvonokeGVucXhH6C58FtQkIsTbI2zlMmQBBYUzJMF jorSJfk1jFm25Wi8Uom2WufJzpNRMU2VF7U9kdQDRBC9eyHKMurUGWrXJsZir3oCD8LR uolladOIV082SRk+2U2Nu0SrFp+4J1VlUmBEteKpiwYgkmzDTo/Y1bayFPYPtVYUYpkU AXd9EmN6YYL/H6aFHcu0YgI2prnkuBSQG8NtCq0Qdj/RqvdL7xdXouBAOhJz3VSsng3l bPPg== X-Gm-Message-State: AOJu0YyCmjUXVD7j33Y1asyVTXCphslzlVfi5ameCNieJV4IzwpOF049 uCj4/VdqplEOlnIqNiRLxMFnPpERjxZM0o/FlRXNBrmB8IY= X-Google-Smtp-Source: AGHT+IFenQK1ce6wIpZimcl97lFkk9+YpEBrRI4/7gpAD+uwokP9xsMhGVdr/Crml5z6W3n3+IkMLoFGtvVbma5DdAY= X-Received: by 2002:a2e:9017:0:b0:2cd:16fe:da1e with SMTP id h23-20020a2e9017000000b002cd16feda1emr617865ljg.96.1704409350603; Thu, 04 Jan 2024 15:02:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 4 Jan 2024 23:02:19 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jan 4, 2024 at 10:12=E2=80=AFPM Stefan Monnier via Bug reports for = GNU Emacs, the Swiss army knife of text editors wrote: > > Package: Emacs > Version: 30.0.50 > > > Many packages use the `major-mode` as a proxy for the type of content > in the buffer. When using the new TS modes, these packages tend to > behave poorly because they do not understand that a buffer in `js-ts-mode= ` > contains Javascript. > > I suggest we add the non-TS mode as an extra parent, so > `derived-mode-all-parents` includes `js-mode` in `js-ts-mode`. Hmmm, this would either mean stupendous and welcome simplification in eglot-server-programs or horrible breakage there. Or maybe something in between :-) Seems risky, so I hope we give it adequate testing. In a fair number of servers. Can some Eglot user help me out here? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:05:33 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:05:33 +0000 Received: from localhost ([127.0.0.1]:55933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWmK-0004QG-Qq for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:05:33 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:44221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWmH-0004Q1-Cc for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:05:32 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 086835C024E; Thu, 4 Jan 2024 18:05:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 04 Jan 2024 18:05:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704409520; x=1704495920; bh=pjE3yH8diPDTiI2BDkwBnNAj8qcEqb1aj6dT3l6G+oY=; b= mTG8h3CfagvamU011EYHmj8pIhKbRqx0pdyirmz0+VGsEU3LJt2kitbd38/IbIHL CRGCkwhopqce4CRlfrG8vLgGQgLXQfpdkXJmgfM+BjlSnuXxd37akrnnKT5IBNBU YYmOduK6bcwfeSHEVegFRFFN0kxuQvd6nAl/RQylAjm2sg05Nfdvblh5KCfDhnFm K5Z9lhpJqtbbBhFPenXBb3AAX7eSUmBoJxUoFldEcjAHMLnDaZMmKGrmF1Ld36Zb 4qb7xJmoeVojneqFuM0X6DTjsq/XMBBH+lq/BDvx1Grb4vTcU5LFg5f+MVYd4aor u9NgE4kvQfZNK4P3yJfRTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704409520; x= 1704495920; bh=pjE3yH8diPDTiI2BDkwBnNAj8qcEqb1aj6dT3l6G+oY=; b=u 0DMqi3h4NXNJ6oVwAPwADqeCFPzjg3erMclf5uR/DPLStjG+W2e85aTQmez2TcaV 4h7b31cWl9/jXAcZnHZRssuLgI/yiM2a1Zd6QGtMrKP2/YULk06TqX3qgb6daNN6 lU3mqdkQAms+7bxvAt4pKVv8rAcleGmI0Io2XJ84bGxhdTPYzihHFkLbbrTjKhKF hWD7cejMui/LZj+24Xrrle51io9o/PJ6NMVHE9exAxq/OxOA2c8XZzfrklPoIj5w WdfQomZvQ/+33/KP5SFc/6iZKQMqVryCP57qU8AXyjQhxOs/udjQnNT1sXw6C7VX F/ijjiMtAtY6KxpOCakag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegkedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Jan 2024 18:05:18 -0500 (EST) Message-ID: Date: Fri, 5 Jan 2024 01:05:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 05/01/2024 01:02, João Távora wrote: > Hmmm, this would either mean stupendous and welcome > simplification in eglot-server-programs Probably not, if you want to keep compatibility with ts modes in Emacs 29.1. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:18:47 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:18:47 +0000 Received: from localhost ([127.0.0.1]:55947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWz9-0007Kc-0Z for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:18:47 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWz4-0007KM-FW for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:18:45 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AB14C83064; Thu, 4 Jan 2024 18:18:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704410311; bh=jREFq+ED39XSK8ZXRjAuqvuLGjOavhv3UvsBMC5lgtw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JLH+DLwbGLlmYca3Ptw/ez+8eHXQiAM5zpwHKygkb43c6dkLdd+MmLEinh1tzZvrf brrKsewb6/LoFgTaZQ+7heCFribaUB5GWrStlniPJ1bFWVwb6s4OEO7/3jb4mG8QtQ vGNYL1s3qd0DK7/K+ip45/3VLM52oGHiLC3x2GM4+/8cKTW1K8d3ts5QffhJ5JrxoA 7R8k0KRgX5fZNs+KTt65TBaI6luDmw4oFDGQyr/2Z0eT/LNBiPlWrtQ/eMSR7ZQq1m GbBjMrr60va6mGF5noqISM60My+EarzqEuH3sQgd9yxn5hU7o+8RrE/7iMiKR0Yjym JsCY4gGnFA+tg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9B6E180430; Thu, 4 Jan 2024 18:18:31 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7922A121223; Thu, 4 Jan 2024 18:18:31 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 4 Jan 2024 23:02:19 +0000") Message-ID: References: Date: Thu, 04 Jan 2024 18:18:30 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Hmmm, this would either mean stupendous and welcome > simplification in eglot-server-programs In the short term, most affected packages (like YASnippet as well) won't benefit very much because they still need to accommodate Emacs<30. > or horrible breakage there. Or maybe something in between :-) Seems > risky, so I hope we give it adequate testing. My preliminary tests were encouraging, but it's just a small dot in the vast space of possibilities, so yes, we need people to try it out. [ Maybe we'll need to offer two kinds of `derived-mode-p` and `derived-mode-all-parents`: one which pays attention only to the "true inherited parents" and another that's more permissive and includes the extra parents. I'm crossing my fingers, hoping that it won't come to that. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:41:48 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:41:48 +0000 Received: from localhost ([127.0.0.1]:55954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXLQ-00021A-7b for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:41:48 -0500 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:43076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXLL-00020v-LY for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:41:47 -0500 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2ccc6e509c8so778971fa.0 for <68246@debbugs.gnu.org>; Thu, 04 Jan 2024 15:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704411693; x=1705016493; 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=nM/J18mNUh48xOdvofsaYjyd2XI9Dk27BMu87seB5X8=; b=agv4qryGY+Plgb8Z/Nny/F+MUNtzVGZ8q3wZgQj5AEgHedJWRAeGZk1eXTym5oy8Kz ovjFRBJGMHeMJSHhtoeemuCdj3T2+myJR8EXkjFwxHUNS51nT9FnbRyDI8rsfnXLcWGy zd1YdwMaRBtyVnGVmfuDzUfTyAN7FI9CztvLkKv6fZc+LnS7r6w4BQ4Cl7bstDlxl8Ba hobKsfA28Fi9zz6eLRnp8W2si4Dwc/lflhILqhaFsoDSgEg8INT3I9lTUwHN0cDhUs4A pitKshhQk25GN27htdoizufn68g0vFT9Q1h6JrxNHsemthxhZWapCH0pqnGJQHTz0YA7 0ExQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704411693; x=1705016493; 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=nM/J18mNUh48xOdvofsaYjyd2XI9Dk27BMu87seB5X8=; b=JH2CQOxNoQOrAllmn418+cQMnNFfZbdUc9uV7gluvmag1+z8v/ZGGE+eZUdnpWNlQJ vTAShz5vC02gVT6LfrOiAFHViDdXyinWKDo4srVg2N0SBFqlyek+BpzB+Gw5tzHdGEZN bADxLtSV8SNyrwHsX/7jFSBXj5IivNCkWHM5gRZGn02K5uEyhrDQxK4MKoqyyEelcfXm Yxag3CY+3XdrU40xgYphhzYZljAy6rkELQFwxRpEtBmzeyT+Zau5XUhZbYQOLw/FcwdB PkAPZtAsPHKw2ByMghbhz+vGV4K5GtJeft5r0HVc+I99oBz23jzIRfwO0ucXD3iULWcU Q3Xg== X-Gm-Message-State: AOJu0YyGcZGARKsqPgiBqY9vEyBQF6yy7QAfxopXJ3MWgQt79LJ9/VWH p58KnljTaYKvkwoqAO9So5gi9/8Oqmnx6qupeXE= X-Google-Smtp-Source: AGHT+IGY0cjWTpAmygPOrtc0iivsR1bpm/WTbKS2B0/PjHiCN1RMTZHDauHNsasQAd1W3sxYZqZRCj+XuxAeOe9jLdc= X-Received: by 2002:a2e:87cd:0:b0:2cc:699f:323c with SMTP id v13-20020a2e87cd000000b002cc699f323cmr746710ljj.9.1704411693215; Thu, 04 Jan 2024 15:41:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 4 Jan 2024 23:41:21 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jan 4, 2024 at 11:05=E2=80=AFPM Dmitry Gutov wro= te: > > On 05/01/2024 01:02, Jo=C3=A3o T=C3=A1vora wrote: > > Hmmm, this would either mean stupendous and welcome > > simplification in eglot-server-programs > > Probably not, if you want to keep compatibility with ts modes in Emacs 29= .1. Not a problem, could have my own derived-mode-all-parents thing in the meantime. Or could just copy the idea directly. Or, yes, could just wait. The question remains tho: does this work every time? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:49:12 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:49:12 +0000 Received: from localhost ([127.0.0.1]:55961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXSa-0004s8-3L for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:49:12 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:57643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXSX-0004ru-L8 for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:49:10 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cd1ca52f31so12294241fa.3 for <68246@debbugs.gnu.org>; Thu, 04 Jan 2024 15:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704412139; x=1705016939; 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=yp8R6erxaTu3Zvu87bityPE9G5TvZn2gugEh46DqPDw=; b=ZSDxefxeCG3pbnTp7mGQoVorY9qNlkSoW00fKR/MDAJj1xqNuGW31xAQQqGJj2oZS2 Zkb7VYjhqJlhizB6AGkRO48lE915qBtPh8c418jprAVp/fX3ijPlUjjLD9R8odzLGPRM G/KHqke8DRg5iA6r+8D8Yp5yinLCDeUEcsHXoCQ/LJiJWBFWCUMBHyN2WE9+xjNiIFr1 vNX7eCaH7+iYBn6DQ/lSSrQMNAlH3eCkcWWU9tvyICZnCF0MjQJLc+gtw7aUvfq7awuw lPOugvk7YqzSJ1XjGdJ1P4pWb1DHM6z5OP8krbnsI565zPxnmCBnIrXycBA2V2cqa6VW En+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704412139; x=1705016939; 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=yp8R6erxaTu3Zvu87bityPE9G5TvZn2gugEh46DqPDw=; b=TDO9O9n7C7S4aBdvcLN12zVNswNipC/zHDihnWspeMlDJu1ecKBNKVXWDFxCSmTABC wcfy2x3iqsQouCWN5+ESIocUT40qkz+nuB/Mjn4AbnUJ/sPCOnQrNMiXIlCvOc+ZSu49 LL5dafBSTVp4DI+5isup4DRP1cqQ++udKHrWW1p9/a8g4UptyXq+x4Ra00w6UILx73mD AOhyioRqADHbeg7ydJQOVesn5IM+Ri5f8D+Plow60mQ+6x1OM3H+OliSCGPXnLgcGKcT TBebqPeKiAn3hGrSQSI5nYF/EKP+s0A0O7/gXvZXRjZAbN+VzNyEMybzWxoyQWiqhbco bw6A== X-Gm-Message-State: AOJu0Yy5QVOAotWO/wDgPsbt6ORur6idCc6uKweQs6VWQxQmsUe1kh94 pHdohvXTpw04D8YTgRTyd9iBV4CvXeefqFmpdbY= X-Google-Smtp-Source: AGHT+IEkBZhn96egCk+MQLjvmtWt5ai+ltWvr6AzSrYPx8uoWijoEfiFRFKgPPeNEllGNjL5p8AB9qZOFG3I2pSBg90= X-Received: by 2002:a2e:7412:0:b0:2cc:7174:48fb with SMTP id p18-20020a2e7412000000b002cc717448fbmr667967ljc.40.1704412139289; Thu, 04 Jan 2024 15:48:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 4 Jan 2024 23:48:48 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jan 4, 2024 at 11:18=E2=80=AFPM Stefan Monnier wrote: > > > Hmmm, this would either mean stupendous and welcome > > simplification in eglot-server-programs > > In the short term, most affected packages (like YASnippet as well) won't > benefit very much because they still need to accommodate Emacs<30. But like I told Dmitry: if the idea is good, I guess the logic isn't hard to implement as a package-specific hack, which is then removed in the future. I have to say that, practical advantages aside, I don't much fancy this implicit derivation based on a name of a specific convention. More than the implicit bit, it's that it only affects types or at least would seem so. Why can't we go to the ts modes we control ourselves and write in this derivation? It's because of hookage right? We _don't_ want x-mode-hook to run when we activate x-ts-mode. Or do we? Maybe we do? How exactly is inheritance defined for major modes? What properties are inherited? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:59:30 2024 Received: (at 68246) by debbugs.gnu.org; 4 Jan 2024 23:59:30 +0000 Received: from localhost ([127.0.0.1]:55981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXcY-00057T-3W for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:59:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXcW-00057E-LV for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 18:59:29 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 58401441CE5; Thu, 4 Jan 2024 18:59:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704412757; bh=R+6qoEAaFTYhPG1yKeHsZmnzgYglrsf7XiNPPWNgDUY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D66qqjciIfdc21+/bhnddvP99+1yTUpDV2+/HCzhukSkdpdvozmkiGMs1CpWaCGRz gqQqKKUqDHFANNXxuQ5GjwlkxbGRs/F8cNlMjszjyI7vnSRk+n9r0F2ELK0Hzux6+v xEXMc9gEWyyPIlHtVkhrqF7xrpZnFMkmkOpVqBGdF4nn5rwGl+tlrmh80UEyusiz84 T91YFha1axfLvSxM9xT8yT0AD7AKeCwJ+wtGHBXEAP0xacUP+WAsXthfGwGfWOFjOF NL3V/ot+AWmOt6rXKuFp0/iaXquQikGrRzfQ1lp7Zif2AkvT+SeS+2A+7XriIsW/a3 D8R+rE9uy1Nqw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D47BC441C18; Thu, 4 Jan 2024 18:59:17 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AFA1D120D8C; Thu, 4 Jan 2024 18:59:17 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 4 Jan 2024 23:48:48 +0000") Message-ID: References: Date: Thu, 04 Jan 2024 18:59:16 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.181 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I have to say that, practical advantages aside, I don't much fancy > this implicit derivation based on a name of a specific convention. Not sure what you're referring to. > Why can't we go to the ts modes we control ourselves and write in > this derivation? Isn't this what my patch does? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 19:35:54 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 00:35:54 +0000 Received: from localhost ([127.0.0.1]:56008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYBm-0005MV-1e for submit@debbugs.gnu.org; Thu, 04 Jan 2024 19:35:54 -0500 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:46305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYBi-0005ME-2H for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 19:35:52 -0500 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cd08f0c12aso11975861fa.0 for <68246@debbugs.gnu.org>; Thu, 04 Jan 2024 16:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704414940; x=1705019740; 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=114paIRoyn/RNvFYI6ruNkXaGfUUNmcI36n3TRtfPtY=; b=Raa6ZH6of7ht3EouGn2EK6/eIZGJfDynbNy5OAQoBD9mhLzyguZJ5Qz29OpAbd718X 0fo8IUSYgZPr7xdIrScNPD+RnMrfpwRYKpK3Feji7BzKzcjS0z47oztz9y4YgDWRdkdv jbPTplNapOa7NNTBnYk/hpSTAIhJs8DXIXUNinBu4yk3LMNHOlvDaYG+nFzaa26Kp3iL zI/MyGeJ+Br7u8G5lxgAOGu07pr0JjbyJoB3fwJ89dyxQxD4Qjnb2ipL17HYq5GAAK33 M2/QD/M7KzAYdToEei4V//pvmWWZg+FCu7Rt7fHhwBxk16bC7Ng6d2DGXrhoqOmStA/m Wb/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704414940; x=1705019740; 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=114paIRoyn/RNvFYI6ruNkXaGfUUNmcI36n3TRtfPtY=; b=mGvZbyiM/7ONySQy9Y3+bcbX9/1ZSo5RppGzvUsPArsQY7/uu8gluZna+2M+hiJDNL J3PwDH9KgJRHDHB8bcfEJQD2h4BxaEnU9aOaeBNlz/NBSdZgy0Q3f9B4h4mgb3uOONBW ha32K07yFKKhoQRw5Bd51BVqld12l3rqaCIB6WvZ50rd+jfWkyDrOAbXDbmWeJgX2rpo q0wojNEraLkqwXyaE51mXFDMp65M4GF0uCymtbze80jo6PywFZYivK7jHt06W/EfT408 qBEaqbn84+nOScHWRpPDLSm52z0kmBYToaVHQdhRLTwtf9V2KbweYE2qKaKvRrcmlMoB jzKA== X-Gm-Message-State: AOJu0YxW5yWPk1UPf1MrUIEedFJjLPpaboWXlyGsC2X+PF4Nl+h9MCnY WZq8BXgIoYnN6/dRK3qICVI9KrxNn0DHmMG26NqtkXq5p3w= X-Google-Smtp-Source: AGHT+IHHwwzn6oi99B8gjadxTWzbhXUGyViW435ceZNpEgKEGUL36WSZqjGJfEASAcCfl4YVi4R2sd/d8WcEFCHdZUM= X-Received: by 2002:a2e:a993:0:b0:2cc:da2a:d266 with SMTP id x19-20020a2ea993000000b002ccda2ad266mr607214ljq.71.1704414939678; Thu, 04 Jan 2024 16:35:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 00:35:28 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Jan 4, 2024 at 11:59=E2=80=AFPM Stefan Monnier wrote: > > > I have to say that, practical advantages aside, I don't much fancy > > this implicit derivation based on a name of a specific convention. > > Not sure what you're referring to. Doh. Shame on me for not reading the patch. For some silly reason I just assumed it was some trick on symbol-name inside derived-mode-all-parents. > > Why can't we go to the ts modes we control ourselves and write in > > this derivation? > > Isn't this what my patch does? Sorry. Well in that case, that takes care of one misgiving :-) I suppose one way to proceed would be to try it out for some time and be ready to revert it, or parts of it? Maybe announce on emacs-devel? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 19:44:01 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 00:44:01 +0000 Received: from localhost ([127.0.0.1]:56026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYJc-0005Z9-Ri for submit@debbugs.gnu.org; Thu, 04 Jan 2024 19:44:01 -0500 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]:53520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYJa-0005Yt-Kv for 68246@debbugs.gnu.org; Thu, 04 Jan 2024 19:43:59 -0500 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-205cdc4b2b8so361101fac.3 for <68246@debbugs.gnu.org>; Thu, 04 Jan 2024 16:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704415429; x=1705020229; darn=debbugs.gnu.org; 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=DwkF90iXTKaATfLZBU6NeZ9AYRku9/pFblG7qFL82Oo=; b=LCzfd+9fTSBNcqDbKhcMUV3fRSw4Bugt91IF8DkM/uLPEQZhLuX4Nk/zgOJNJlSsXK eqcsppavi5zROYVOsx/WbODdrWnI92F1c5BbSGxg4kSdcJ0dligNHbzqQC7qghqfML+g s0atouMNazGkMMEpl8kJITg6cz255FNRhevaBrvfg3QKgHH3Hay884HKM2K5GWI97UK+ kQLRsiK6QeRw9SVoNzgXNkyNQpmgUlROQTyhqB/vhf5WS27dQPnCp5k9XfKd3zuBtA3x vCYevBUDXjI6vALbOzEbJ0xnjICeAZt9Y23sx9Il5VrrUE4BZX9apOeUdBpvy7nUEvIj 6dgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704415429; x=1705020229; 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=DwkF90iXTKaATfLZBU6NeZ9AYRku9/pFblG7qFL82Oo=; b=NwUkp4jAlLtp1QBiny5ytP6DE9lfPNvR7UQbb+2Dxeg9EFLiuso+U9VMKgwaznY5wD 8N3WVSHOPY03iaFFuVkuCt3Pj8py4oFQbqB4z92gt3SigJzeCgx4A9H9Dr2RR47J/Qlz r5i9KnS2KuKuVYV+pIJTBMkHU8N8GOx1h+h8fWysvOtWMATcwnktdeRZK8egG5/s1FK7 rLoWBDAJnl5+E8ZXGexqV5+7GQklryl+Bo1sFIzW/PPQh18BTOXrAGTKAGl0h2OYHm6m 8DZLXypOOJtytUESEQpVm4nJRou1ew94/xixuhsqzCW7XQPXHGGoeHkyXY/8/lT/ik64 jB8g== X-Gm-Message-State: AOJu0Yz50d40/SDY1VoQ9Tw8dOIAI6KVCD2jIrv/UHKukIo3N6Cepf/9 9BEXgWAyDBHiojrdzn19QYE= X-Google-Smtp-Source: AGHT+IH6M3YulpCxVtArCRS2w+HtphVYGgOdKw/o/VZ44kOeUblemGZ8JNyv5zbpBSkveaPTy8OhUQ== X-Received: by 2002:a05:6870:a40c:b0:203:d7ae:5ec9 with SMTP id m12-20020a056870a40c00b00203d7ae5ec9mr1528199oal.100.1704415428850; Thu, 04 Jan 2024 16:43:48 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id z5-20020a636505000000b005ca0ae17983sm263294pgb.8.2024.01.04.16.43.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2024 16:43:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: Date: Thu, 4 Jan 2024 16:43:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >=20 >>> Why can't we go to the ts modes we control ourselves and write in >>> this derivation? >>=20 >> Isn't this what my patch does? >=20 > Sorry. Well in that case, that takes care of one misgiving :-) > I suppose one way to proceed would be to try it out for some > time and be ready to revert it, or parts of it? Maybe announce > on emacs-devel? I=E2=80=99m all for it :-) Yuan= From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 02:40:41 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 07:40:41 +0000 Received: from localhost ([127.0.0.1]:56238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLeor-0005La-E8 for submit@debbugs.gnu.org; Fri, 05 Jan 2024 02:40:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLeop-0005LJ-9A for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 02:40:40 -0500 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 1rLeof-00052z-Hf; Fri, 05 Jan 2024 02:40:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yDHRiqaDioRNKdEmfXGsdbUVC6qeZ1Y1qCqjCu8W0uY=; b=Q9lK2TqcoE5g G0hqwixLcSRjAmkvJ7fDx2g6TPpccWukbun6VMvswOmU0cERXhNwME9C2ivORKYy/4bomYO0qD5jR upqWSkGO6mAIZmo8JsM0StClQmoeyYM2oiJ9zkaXokzzKI6zSufuRrXYEaOn7x2zLPGHgK18yLdZV TzCcVdwOPzako7MeYHf+aSY3HL6kr1iTD5EkbCn/fo3Xm7usdOdgNU2yTVESeCMn7KHsIh9cWRQWf qeRwKH6F0kx9p1SimWnEEyg8NsJ6T3kdljyR1jrxdzv6om9NJkur4Lb3qaVcAmcAjcAipdYLCoUZD T9hixwntSvojkJ8GIwKUnA==; Date: Fri, 05 Jan 2024 09:40:17 +0200 Message-Id: <83h6jsw7mm.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: monnier@iro.umontreal.ca > Date: Thu, 04 Jan 2024 17:11:14 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Many packages use the `major-mode` as a proxy for the type of content > in the buffer. When using the new TS modes, these packages tend to > behave poorly because they do not understand that a buffer in `js-ts-mode` > contains Javascript. > > I suggest we add the non-TS mode as an extra parent, so > `derived-mode-all-parents` includes `js-mode` in `js-ts-mode`. If it works well, it's a good simplification, IMO. But this patch is IMO incomplete: . it should modify our .dir-locals.el and Eglot's database to remove special entries for TS modes . it should add the recommendation to consider using this to the "Major Mode Convention" node of the ELisp manual From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 02:52:08 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 07:52:08 +0000 Received: from localhost ([127.0.0.1]:56264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLezw-0008Mn-1f for submit@debbugs.gnu.org; Fri, 05 Jan 2024 02:52:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLezt-0008MH-6r for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 02:52:06 -0500 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 1rLezj-0005C5-OH; Fri, 05 Jan 2024 02:51:55 -0500 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=nuKJxt2raEHoeZs5u/daKFdFBL3abUtdmh4PAkllpoc=; b=WjaN5YHls/N7iGUF2px6 8cXwb1TWk18Mvn/cyXnDeadfzk41FK4XHbuyi3AgAdJDwMxkaomIT+dV8NkAEPmNdlzvYVbxZK5Zw MZvRlxFsp93bQuQqZ7HrPrBQ1ZlWlfGlrXjVoc7YZhhpAetO3i8QvF6mFoELGlxi1ngbTtnOBS7wf tl2jFODyQcT8/ZuuCmeWi/BLHrorf1+kPO1W7DdV1pCLzFmWMtoys8Lsi+OrivDzyHJu/lHZZUu9N bCL9gcJPgUwhcZAD+o+e057yuBAmIKfUW+mH97//PKPkZH5MPEMd7YFmp8zhS/yM0IOQtMmE7GJlZ rMdCx2Eg5mz66A==; Date: Fri, 05 Jan 2024 09:51:44 +0200 Message-Id: <83edeww73j.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 4 Jan 2024 23:48:48 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 68246@debbugs.gnu.org > From: João Távora > Date: Thu, 4 Jan 2024 23:48:48 +0000 > > We _don't_ want x-mode-hook to run when we activate > x-ts-mode. Or do we? We don't, because FOO-mode-hook usually assumes all kinds of things that are generally not true for FOO-ts-mode. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 06:28:19 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 11:28:20 +0000 Received: from localhost ([127.0.0.1]:56534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLiN9-0008MW-E1 for submit@debbugs.gnu.org; Fri, 05 Jan 2024 06:28:19 -0500 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:55344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLiN5-0008MH-UY for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 06:28:17 -0500 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50ea226bda8so1558024e87.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 03:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704454086; x=1705058886; 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=EBSO/1HD7H2/cI4nZMXMa7JvEAXuoQJjvE216y09Ap8=; b=ZjWfZ8Eg9wNVPuBMGYpQ3Vjvu2ZPCvmogK0SFyRbxNDiVU3eZ6zpqcubstMPnkkp/q a8MRgoO/hpvvCHgcW2BFBFNvbil7vm1PJS/vaSlsrt30vm3MSUHyPHK/O8LFHIjyDzdC N3/Rd+M8Y8zg7dW7rbS7jDzWS2AOjGl4gWMB0YTDesJKA57Xah7Ep4uWHSv9JaEG4Ksy 7gXyoO76mxW6GlJKdFDhBXY9VP6dzZ3ZWDwMm1m6/dU0JovVNkEDvCI3wfrnWWUPN4GH VhyD5qRJCXTe345zeCGKqplTMwIAAJDhtqSxwoHUcFF7F4PKE4+mx6424DWTI5uqgNv0 Gg9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704454086; x=1705058886; 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=EBSO/1HD7H2/cI4nZMXMa7JvEAXuoQJjvE216y09Ap8=; b=v2Qi6/2RYT1Yw2MU/VZfBSz6ohR6T102XQ8uR9IEY9MOXLjTwIDtS8vhNmTSQqSpxe e5ILTiSFLBIc2+EuFnbzP9C83UQoS4Zj7Fu/CjxTTJwYiYSZgOvqpb1XJy1e6oEk3kd8 epuKFndcA47u2jjdmZXLx0I8ebYZx/z19L7Fw9Mmhm9Pw+Z0K3sEiFajA3BLo4k4ISuO K1WrekxCKEEtHPF/uRbu9h8PsiiNYbGw5QPozUxIEXoe4tVlHcQtUOceD7quKZBDnNIS 83VFR904OaGqZIwj+Ul5SKopP47CUoj5gTVwXYdxsSVOctp4Ir93pMXQ+l/ZlsQaEoQp CCBA== X-Gm-Message-State: AOJu0Yxj5KpS3j+oXWerVqKeXmqfsjmm0fPmpfTPjgvnzdrgS4H1bbEG kvSMgGav9lNdzc7i8PxM73iYPftn6eqT0ajXTWY= X-Google-Smtp-Source: AGHT+IFDpUB7Lki2ZkFrZGroRMcRlGUgJ1UdsH37NevWdvZYkaBRyagHJ0yj0WfiiwB8YEIiBhpS1Yiy0Q9CzKfvl60= X-Received: by 2002:ac2:4e13:0:b0:50e:7711:45c with SMTP id e19-20020ac24e13000000b0050e7711045cmr1259771lfr.77.1704454085450; Fri, 05 Jan 2024 03:28:05 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> In-Reply-To: <83edeww73j.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 11:27:53 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 7:51=E2=80=AFAM Eli Zaretskii wrote: > > > Cc: 68246@debbugs.gnu.org > > From: Jo=C3=A3o T=C3=A1vora > > Date: Thu, 4 Jan 2024 23:48:48 +0000 > > > > We _don't_ want x-mode-hook to run when we activate > > x-ts-mode. Or do we? > > We don't, because FOO-mode-hook usually assumes all kinds of things > that are generally not true for FOO-ts-mode. Indeed. Sorry for the long mail, here's a TL;DR: let's experiment, but maybe tighten up the docs to state 'define-derived-mode' is parenting and 'add-derived-mode-parents' is more like adoption. Possibly add 'remove-derived-mode-parent' for safety and fixing existing bugs. Now I've read the patch and the misgivings are back. It uses `derived-mode-add-parents`, whereas by "adding the inheritance ourselves", I was suggesting going to each `define-derived-mode` of each 'foo-ts-mode' and really putting in 'foo-mode' as a parent. So this is the multi-file macro-expanded moral equivalent of the symbol-name hack I was talking about 'd-m-add-parents' is a very new util in our tree, and I suppose it has been discussed. It's not really full inheritance as given by normal parenting, it's more like "adult adoption" :-) I guess we can try it, and even like it, but can we be sure of all the semantic impacts? If you ask me, authors should prioritize getting their hands dirty and extract commonality for the foo-ts-mode and foo-mode one by one. Name such modes foo-base-mode or base-foo-mode maybe. This is what was done for lisp-data-mode which now parents most (all?) Lisp modes, so much that the other day I could write a functional 2 line Clojure-mode based on lisp-data-mode. The situation is that camp is much cleaner now, and it wasn't a very difficult change. base-foo-mode is a natural place for setup that is common to both foo-mode and foo-ts-mode to exist. There is a good number of things that are independent of the particular implementation of parsing (lisp-based vs ts-based). Is it too late for the ts-modes to be looked at like that? It seems our approach to TS modes often/always looks like 'foo-rewrite-completely-using-ts-while-at-it-mode'. Maybe for some modes this makes sense IMO, like C and C++ modes. Inadequate parenting is a real problem. The lisp-mode example 2-3 years ago, but also recently the parenting the js-json-mode <-> js-mode relation has caused a so-far unsolved problem in Eglot described in bug#67463. That bug can also really only be solved by "getting hands dirty" or by introducing some remove-derived-mode-parent counterpart to the new derived-mode-add-parents. If that's how we want to view "derived-mode-p" from now on. Maybe it is. But it should be well explained in the docs of both define-derived-mode and derived-mode-p that you don't need the former to get the latter and that d-d-mode bakes in much more powerful relation that add-derived-mode-parents doesn't fully emulate. And that remove-derived-mode-parent can sever that part of the relation (and only that part). > It should modify our .dir-locals.el and Eglot's database to > remove special entries for TS modes As Dmitry mentioned: if that is done just like that it will break Eglot's support of ts modes in any Emacs which doesn't have Stefan's patch. But we could easily add some compatibility code to Eglot that does the same thing as the patch in ad-hoc fashion, and then remove that code (much later) on. Also, I know this mail is long enough, but apropos Eglot's database, it's getting quite large as you may notice. Another, much more natural way to simplify it would be, if major-modes started setting eglot-server-program (singular) buffer-locally variable which takes precedence over eglot-server-programs. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 08:26:29 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 13:26:29 +0000 Received: from localhost ([127.0.0.1]:56667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLkDV-0006w6-8Y for submit@debbugs.gnu.org; Fri, 05 Jan 2024 08:26:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLkDS-0006vp-AE for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 08:26:28 -0500 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 1rLkDH-0003Fu-4J; Fri, 05 Jan 2024 08:26:15 -0500 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=SLi4+BIHlMRY01n6wP67UNGTF/Aa8Hv1e8Ot6lRYk9M=; b=anp7CVfKC2zriOc3RzFx McN76nUyavQOWcwVMZNrKl1J2Z/yRxOdXMbot3vyNZwZD1kiDXk6KJw+aZipLanu2EUl0UHRsnGx7 6SsCQ0kzUIi/yM35VR8LUWpNbDReNwyboFBmMns0MHPdAW6wDrjDN5ewkPOEtU/exCtd8KsrsnKsE b0kFS4AAilszfWJeQmFcuu+0guOFnAUlvthE5rMZKBBO8QqJidwW9k+PfjDiqUPRpAPRsBvMKh7yx eLox5+R3SXlJTmrYWj2ZWB/hn1qHJlbVbahXx6kE3gxZEBg7+p67n+9xgTJiyEOCz8e5MEa26jGnt WzMxgoR3tpsu7w==; Date: Fri, 05 Jan 2024 15:26:00 +0200 Message-Id: <83o7dzvrmf.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 5 Jan 2024 11:27:53 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 5 Jan 2024 11:27:53 +0000 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > base-foo-mode is a natural place for setup that is common > to both foo-mode and foo-ts-mode to exist. There is a > good number of things that are independent of the particular > implementation of parsing (lisp-based vs ts-based). > > Is it too late for the ts-modes to be looked at like that? It doesn't always make sense. Where it does make sense, I think we did it (see python-ts-mode, for example). > It seems our approach to TS modes often/always looks like > 'foo-rewrite-completely-using-ts-while-at-it-mode'. That's right -- but it's justified. The commonality is usually either very thin or almost non-existent. If you think about it, you will understand: where the traditional modes use regexps and syntax-pss, the TS modes use parser-related primitives. How can you find common grounds between these so different bases for implementation? > > It should modify our .dir-locals.el and Eglot's database to > > remove special entries for TS modes > > As Dmitry mentioned: if that is done just like that it will > break Eglot's support of ts modes in any Emacs which doesn't > have Stefan's patch. Then Eglot (or maybe compat.el) will have to provide compatibility shims. But for .dir-locals.el, I still think we should update it. > Also, I know this mail is long enough, but apropos Eglot's > database, it's getting quite large as you may notice. Another, > much more natural way to simplify it would be, if major-modes > started setting eglot-server-program (singular) buffer-locally > variable which takes precedence over eglot-server-programs. Maybe. But that's an unrelated issue. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 10:16:55 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 15:16:55 +0000 Received: from localhost ([127.0.0.1]:57612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLlwN-0005UV-Dj for submit@debbugs.gnu.org; Fri, 05 Jan 2024 10:16:55 -0500 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:44374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLlwL-0005UF-5N for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 10:16:54 -0500 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2ccae380df2so19647791fa.1 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 07:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704467803; x=1705072603; 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=n6IUbGB7hnFL6E/N8uwIcS3p9Llt0GwBfK1uiQJhY38=; b=HYChveTTn4jApQRv0MD1GWyt+wJugpv0BMetE1ayxXvq92HWIUHzvF4ppcSXs1P7/p NnhklVVUhyuKKbzMCQYwI6eKIXSlaeIG9flLl3241A5QMqgE2JxJMYBkD9qId0yoSMPg WUoT2j21ESFas2iGXMrIm/A/YXk5Z/ebCleaWVwlJqQohvKnh/1GAp/Bgc2Z/FguhzvQ dCMQ8Td7ejMJm5wChsfvvFA+7kuu/mvVkWyS3oURqIUmCJFolB2NF4WJq5SKBlHA5doh rEPtAzkGyjyvIQUVzKYhcO0mMcY4CYV0FgzTnBT/pWP3Z8dpkEZs7X88677I/TEgA4iE YySw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704467803; x=1705072603; 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=n6IUbGB7hnFL6E/N8uwIcS3p9Llt0GwBfK1uiQJhY38=; b=IaEXQjZOBM+n9jeGCrP2VyU3J8/nk8tLujAdIfZ/LlNPIcfdyCCep9BbxtcwQscRS7 v8liD8oA9Ojgn9Ml3L3UahYHDDnjZyiy1ShrdQAvJzGy00WZ00i/yGKvQj7XjWy+UOjF 9tPPMLUzXurBqm1fJhU+H8yZEuW8btaUzvUg7sKnV3BN2S/9ldPXtKP0uixdjfmxcrGg FkCZchVWP0Jr1U9FbT9MVLnVVfQCyPWgfu9NRw6bcJ3gFHgS2faWuCy3JINKbO1A36ID nO/wrQ98QgH+aW2YskLp+Zat4bFdirkF/6zl8e0tTathgKlE/pV0rLP+SINYgmuN9YsY v6AQ== X-Gm-Message-State: AOJu0Yzm9ittMVy4GJMlO0mAJiHFdbzyqv30GD4tNcsNAbbs/X9OGPxb Ifw8SCryfIR+K++vPwBfKjiiC7tmLjKLt0D7Z28= X-Google-Smtp-Source: AGHT+IHS+TAZsHLf8nrOsetgffXaNO/eG7AZOJYE2A4V6GMWBlI0MGB+YrbKXvJWd8nl1qfdwrOGVMv3T5ZI14rUkVo= X-Received: by 2002:a2e:7d04:0:b0:2cc:a67d:fee6 with SMTP id y4-20020a2e7d04000000b002cca67dfee6mr1127829ljc.39.1704467802661; Fri, 05 Jan 2024 07:16:42 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> In-Reply-To: <83o7dzvrmf.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 15:16:30 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 1:26=E2=80=AFPM Eli Zaretskii wrote: > That's right -- but it's justified. The commonality is usually either > very thin or almost non-existent. If you think about it, you will > understand: where the traditional modes use regexps and syntax-ppss, > the TS modes use parser-related primitives. I _have_ thought about it. And I started from evidence that not everything a major mode dedicated to a language supplies is directly related to the parser implementation. Many things are, but not all. So reimplementing a full major mode just for changing the praser backend might not make sense. > How can you find common > grounds between these so different bases for implementation? Very easily, I think. Stefan's patch is one such example. What it is fixing? Tools that want this common ground and haven't found it, of course! But there's also my own hookage that I had to move from c++-mode to c++-ts-mode. Stefan's patch doesn't fix that. Take inserting comments via comment-dwim. Or invoking LSP in any mode for another example. Or consulting documentation. Or anything we've built (including muscle memory) that lives on top of syntactic abstractions like forward-sexp. Basically any preference that the major-mode expresses regarding an orthogonal facility (minor mode or not) should, in principle, be shared. At the very least, it seems a common hook would be useful, and that's what an empty foo-base-mode() would give. It _also_ gives you the possibility to fix this more elegantly (well, at the expense of yet another naming convention). > > > It should modify our .dir-locals.el and Eglot's database to > > > remove special entries for TS modes > > > > As Dmitry mentioned: if that is done just like that it will > > break Eglot's support of ts modes in any Emacs which doesn't > > have Stefan's patch. > > Then Eglot (or maybe compat.el) will have to provide compatibility > shims. Yes, if any wants to update Eglot to use compat.el, I think it would be useful in this and more situations. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 10:35:01 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 15:35:01 +0000 Received: from localhost ([127.0.0.1]:57625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmDs-00006i-Kg for submit@debbugs.gnu.org; Fri, 05 Jan 2024 10:35:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmDo-00006T-Ry for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 10:34:58 -0500 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 1rLmDe-0003OJ-FD; Fri, 05 Jan 2024 10:34:46 -0500 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=1lWxnn+LPsWs25U9PIviQPoE1gV2vd5ks3pKmYCiZUo=; b=ejI761QxM9JE711d5vZ3 Jwq5wJ2bsecqGYZqnz+5/UtQQQQ0Vi0RY7z3fVTFOvVc1+iGQnIC9xoS1+FG6rRSWirEIk46xM0rF XgRm24NC6BXu4UFjaLnlXgdAH4FDdyYSRM3X2VAxKdsOFUPbvXznbCL0fNULO+rDi0pa3j1/3cIy0 oD+o9zF4219hYXS/GfyojNBKuiAEtRNxqCGkLdY98gZhtkR0AFpmV0Di4xfqF1ulTFUlhgvRhIX61 4z++7H2U90WRCW9G4DpRBQSaJ8PXShok/Cmj9674mofXiZXZr7VHz2iO+OqDvHhaKxkd+1VMpjpXF jhxyqNERr6fT/w==; Date: Fri, 05 Jan 2024 17:34:34 +0200 Message-Id: <838r53vlo5.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 5 Jan 2024 15:16:30 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 5 Jan 2024 15:16:30 +0000 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > On Fri, Jan 5, 2024 at 1:26 PM Eli Zaretskii wrote: > > > That's right -- but it's justified. The commonality is usually either > > very thin or almost non-existent. If you think about it, you will > > understand: where the traditional modes use regexps and syntax-ppss, > > the TS modes use parser-related primitives. > > I _have_ thought about it. And I started from evidence that > not everything a major mode dedicated to a language supplies > is directly related to the parser implementation. Many things > are, but not all. So reimplementing a full major mode just > for changing the praser backend might not make sense. Experience shows that eventually most if not all of that goes back to how the mode parses or analyzes the text (a.k.a. "source code"). > > How can you find common > > grounds between these so different bases for implementation? > > Very easily, I think. Stefan's patch is one such example. > What it is fixing? Tools that want this common ground and haven't > found it, of course! What Stefan's patch fixes is the features that depend only on the mode's symbol, but don't call any mode-specific functions or examine its data structures. > Take inserting comments via comment-dwim. Even comment-dwim already shows a problem: it must determine whether point is inside a comment, and TS and non-TS modes do that radically differently. The commonality could of course be increased by refactoring the existing stuff so that it uses more abstract interfaces, which could then be implemented separately for TS and non-TS modes. But that requires some motivation, and for now I see no such motivation where different people maintain the traditional and TS modes. Such refactoring is not an easy business, so without the motivation I see no way for that to happen any time soon. > Or invoking LSP in any mode for another example. LSP only cares for the language, so of course it can benefit from Stefan's patch, because all that matters is the mode's symbol. > Or consulting documentation. Again, only the mode's symbol is important. > Or anything we've built (including muscle memory) that lives on top > of syntactic abstractions like forward-sexp. Here you already bump into a problem, because most languages have no notion of "sexp", so making a TS mode do the same as a traditional mode is not easy at all. > Basically any preference that the major-mode expresses regarding an > orthogonal facility (minor mode or not) should, in principle, be > shared. I invite you to compare CC mode with c-ts-mode, and see for yourself how the common grounds are very small. It seems surprising at first sight, but once you look at the code, it is very clear. > At the very least, it seems a common hook would be useful, and that's > what an empty foo-base-mode() would give. Where a base mode makes sense, sure. But even that causes problems, since the base mode leaves some stuff not set up, and this various things that you'd want to do in a mode hook are impossible in the base-mode hook. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 13:02:57 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 18:02:57 +0000 Received: from localhost ([127.0.0.1]:57793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLoX2-0004tU-Or for submit@debbugs.gnu.org; Fri, 05 Jan 2024 13:02:57 -0500 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:57447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLoWy-0004tC-Fm for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 13:02:55 -0500 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2cce6c719caso22006291fa.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 10:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704477762; x=1705082562; 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=jy7DOxzuhqu+xwFyshBsS7i2uqzvM/PhYO3ZQEFfRms=; b=gIzNvuQhp71PvMzP/fQ4lqySBDOHjIaaltec5hPkkYn/Tc8L4x1mKKQmxswfi+RO6h H4gt0wXTTmccProGBqkDjgSG6ZQRxkmCYjXeI0xOXX5/nO3PtATP+8Bg81jx5CA2fqQa p+PmO8LaXUxyqKNYBOFiWXbfCQuFNo01xDgeuLVV+8OGaTRGRGldylIBh8csHHmrF2+5 LVtGH4tZXhAtayJ1NgsVpSuz1aIOJBLi3WE4v7vediU6Hff2eSi59B/6JDF8vMdY17WX SiJv+3Qrr14x55jnkfuFwOLoIVNoyNCnSISTzpQSbrIz7Vbo3YGL/LPXe2G3JCN4Mcf2 UuJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704477762; x=1705082562; 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=jy7DOxzuhqu+xwFyshBsS7i2uqzvM/PhYO3ZQEFfRms=; b=O0GhrvGVgnjS5lqqqZy2yMPIVHUb25ZCxR8E8DuIAVQ8+L/1WvyoX3gdVpuUFpFhdZ huPG2CsHkY893Yp8f7uOMh+HO+4Q28WT+8522ZV6b7CeX0ChqFiaCuUBW4JQcfUr280B PA+xdXfi8BIyBq3q61wkuo4xb1AtvZ+z29Q0OfJwOpXzsStlhjfKaezk42udlELsQ8Xj D1J6OLKW1zhN+LFly4CuYhUftO1PGwr+Ri9dA8Q0+tP+Jv8FSs/lfIvqBhSFnOMPC2xU eOxs92nmYKxI1RaWGAatVEcJ/SLusKjZ3KbU8kbcH9yE5XGGCGypOxsqUX28ZEEEz+h4 +Acg== X-Gm-Message-State: AOJu0Yw2lOmHsuZtwoilHJzfe0czEexRBA9T5mB5QwAKKNEIEh/lPiU8 wPlS8Q5W1/sanB/O8SJAZQcN8/s2/bkLdCzQjYY= X-Google-Smtp-Source: AGHT+IGbQlG8iz29bOmJvd7UQ0IpnNU9bvgF3Ka9OYt4Y7JyIxje5DnE9lfbghYm71lIotP1y4fQTksUdeIrwZVc/uA= X-Received: by 2002:a05:651c:169b:b0:2cd:1c12:cb16 with SMTP id bd27-20020a05651c169b00b002cd1c12cb16mr1167462ljb.81.1704477761710; Fri, 05 Jan 2024 10:02:41 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> In-Reply-To: <838r53vlo5.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 18:02:29 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii , Yuan Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 3:34=E2=80=AFPM Eli Zaretskii wrote: > > I _have_ thought about it. And I started from evidence that > > not everything a major mode dedicated to a language supplies > > is directly related to the parser implementation. Many things > > are, but not all. So reimplementing a full major mode just > > for changing the praser backend might not make sense. > > Experience shows that eventually most if not all of that goes back to > how the mode parses or analyzes the text (a.k.a. "source code"). That might be. That's why I specifically wrote "parser implementation" It _needn't_ (and quite fortunately often _doesn't_) go back to that. > > > How can you find common > > > grounds between these so different bases for implementation? > > > > Very easily, I think. Stefan's patch is one such example. > > What it is fixing? Tools that want this common ground and haven't > > found it, of course! > > What Stefan's patch fixes is the features that depend only on the > mode's symbol, but don't call any mode-specific functions or examine > its data structures. Yes. But it doesn't fix a minor mode that relies on a buffer-local setting of one of this minor-modes variables, and this setting happens in the mode body or in a hook, say flymake-diagnostic-functions, but there are many. Same for a minor mode relying on syntax-ppss. > > Take inserting comments via comment-dwim. > > Even comment-dwim already shows a problem: it must determine whether > point is inside a comment, and TS and non-TS modes do that radically > differently. Again, that's true for the implementation-wise. But it needn't be of the interface. > LSP only cares for the language, so of course it can benefit from > Stefan's patch, because all that matters is the mode's symbol. Stefan's patch becomes irrelevant (for LSP) if we switch to eglot-server-program (singular). Either we will have two identical settings of eglot-server-program in foo-mode and foo-ts-mode, or we will use a shared one. Yasnippet (another package I re-wrote mostly) also relies on this "database" approach. It shouldn't, but I didn't know better at the time. Stefan's patch is only needed for it because refactoring it is work that noone wants to put in (at least I don't). > > Or consulting documentation. > > Again, only the mode's symbol is important. No. Say some consult-documentation minor-mode relies on some setting of 'documentation-function'? > > Or anything we've built (including muscle memory) that lives on top > > of syntactic abstractions like forward-sexp. > > Here you already bump into a problem, because most languages have no > notion of "sexp", so making a TS mode do the same as a traditional > mode is not easy at all. Of course they do!! How else would electric-pair-mode have worked for virtually every language for more than 10 years, or C-M-u, C-M-SPC, etc etc? e-p-m doesn't have knowledge of past and future modes, yet it works. How? Well the reason why e-p-m and these things work today for most ts modes is because they are also _using_ the Lisp/C parser based on syntax tables and syntax-propertize-function. So, in essence, TS modes currently use two parsers wasting CPU doing a fair amount of duplicate work. I suppose this waste would only stop once syntax-tables are nullified for those modes. But we can't many syntax-ppss clients (e-p-m, symbol-at-point) hanging. IMO There's an elegant out. When one puts a suitable syntax-propertize-function that consults ts nodes, like someone did for c++-ts-mode (still very minimal though) we take full advantage of TS and even enable things that are very complicated to do without TS. For example, in non-TS c++-mode it's hard to have e-p-m pair '<' with '>' but only in C++ template contexts. But in c++ts-mode it's within reach. It does needs both an addition to c++-ts-mode's s-p-function and a bugfix to elec-pair.el: I'm looking into that. > > Basically any preference that the major-mode expresses regarding an > > orthogonal facility (minor mode or not) should, in principle, be > > shared. > > I invite you to compare CC mode with c-ts-mode, and see for yourself > how the common grounds are very small. It seems surprising at first > sight, but once you look at the code, it is very clear. And this is mainly because CC mode is, well, rather corpulent software, let's put it like that. This is why I wrote it makes sense to start from scratch for this one. But would some kind of c++-base-mode hurt in some way? Presuming Alan allows it, of course. > > At the very least, it seems a common hook would be useful, and that's > > what an empty foo-base-mode() would give. > > Where a base mode makes sense, sure. But even that causes problems, > since the base mode leaves some stuff not set up. I don't follow. Can you give an example of a problem? In fact I'm happy to see exactly the strategy I suggested is already done in ruby-mode.el and ruby-ts-mode.el. What problems are caused by it? It makes sense for the base mode be abstract of course: meaning we should flag an error if calling 'foo-base-mode' detects it is called outside of the the context of 'foo-concrete-mode'. > and this various > things that you'd want to do in a mode hook are impossible in the > base-mode hook. I don't follow this part either. Can you give an example using, say the existing ruby-base-mode. In summary, my position is that regardless of Stefan's patch, which I'm not opposed to, we should: 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when possible. 2. have a remove-derived-mode-parent (for the other bug) 3. perhaps tighten up what we mean by derived-mode-p in the docs Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 13:43:27 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 18:43:27 +0000 Received: from localhost ([127.0.0.1]:57896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpAE-0002hr-PY for submit@debbugs.gnu.org; Fri, 05 Jan 2024 13:43:27 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:56515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpAA-0002hY-Jd for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 13:43:25 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-555aa7fd668so2141433a12.0 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 10:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704480192; x=1705084992; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=XOi4ybxGTguRKN3pWbQLlvdgNgWo4z9DkwiGPJR1TgU=; b=RTX3ugQUW1rUyKDX/a7RSw7jqdgzBp/oqwOrt1IXiXpUWB3bWiWgYc/q/ixFO4OLyQ U7kJkknIMpPLee6dy5Ga0ny6izvkNN5k2yUWjuN1NHU+JXkKEeaDh3HY2YF7nrRAG+wf 9Jvo8KdoqSkDj0bM1SpprKJUU1RJP6Au6ua7DMTbIcjf5MqYdyzkp5+BWmyLzvsazGhd dOsIfcCcRop1sAL2BPTYKg5n++xrIm4hxN+PQAl8GhGUWtoL/69JdP60gN5sxaHAqMV6 Xo/Df0Kbmn1MFs32upqpOsbOGw3weuP2JyoYtjB2y68FcCLehWbxaXUU0V1m7CXTHN2F oATA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704480192; x=1705084992; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XOi4ybxGTguRKN3pWbQLlvdgNgWo4z9DkwiGPJR1TgU=; b=a854Q1tLmFOmbdROoXTE7EyEOoCQms6K0Cw4qipn4nqpGquXl0skNktgnh5H4Cf29P Tv2Sg274xYgNHymCbJzWfin5Svn4yO5veSYwPxAjj9aU9kBRRFaB9d+tTOn94VUrD3lE kN2e3JAwboooouVdOK64htcg74M8ddXFDFCZY+mYbDWBZcNGqGsqbHEZTsLRJn4WAsNc x8p+ZRZ2/ru+T6Y1XFil/3GLQDY4EE7AB/hQn0RrwK1uon7eaqbYBlHvcyIZoJCsncs7 BztMaL4hw7NVCETppaY4mLwYcuYTOFpN+fu38x1U5IPDkSKLmpnF5J8lGWVLygFT1CTf u3oQ== X-Gm-Message-State: AOJu0Yz4ywJuiweUMluQ1wpxYSrsnLAL4Fz8vkZGQCzSnjHONepsK2mH 9ThMlL82mEisbwDSEfAZ0/QG6TlFTmiKGpCEDY4GkFY5 X-Google-Smtp-Source: AGHT+IG4qZDRGWu6jqH7G+JPzILxaXt5O34C9MtTS7aWnBGMfSu4KiwpJjKc5W0arUr79cIqfyKCTz5CGz3u53HHYls= X-Received: by 2002:a50:aac3:0:b0:556:e0ee:85bc with SMTP id r3-20020a50aac3000000b00556e0ee85bcmr1447919edc.51.1704480191935; Fri, 05 Jan 2024 10:43:11 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 5 Jan 2024 10:43:11 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 5 Jan 2024 10:43:11 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: 68246@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Many packages use the `major-mode` as a proxy for the type of content > in the buffer. When using the new TS modes, these packages tend to > behave poorly because they do not understand that a buffer in `js-ts-mode` > contains Javascript. > > I suggest we add the non-TS mode as an extra parent, so > `derived-mode-all-parents` includes `js-mode` in `js-ts-mode`. We should probably also change *Help* to displays the extra parents, or this will be pretty confusing. It should probably both list it as a parent mode, and say that it will run the corresponding hook. Here's an example: (progn (define-derived-mode python-super-mode prog-mode "SuperPython" "Doc") (derived-mode-add-parents 'python-super-mode '(python-mode)) (describe-function 'python-super-mode)) From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 13:57:20 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 18:57:20 +0000 Received: from localhost ([127.0.0.1]:57913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpNg-0005hc-2w for submit@debbugs.gnu.org; Fri, 05 Jan 2024 13:57:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpNb-0005hL-Uo for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 13:57:17 -0500 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 1rLpNQ-0003IO-Li; Fri, 05 Jan 2024 13:57:05 -0500 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=Nfuta7OCB0iVKZc14IPs3edmpJI6DlGQcA9Mxeda9yA=; b=sKyCMlFTKn2y2BvwG8Zd aoS2stCeVBsDsIosgkqIyiYEA/mrkdh7bmEvXMJ+pHQaEwTWTBhqYBrhS5rgnUvp29APQgIFi57et rvC5rTSjSRsxF5rJkyV65MoZHkJaCACi17adDI5XLthyJdbmeBF8r9dNS4vL2zOzKHoJo11wcFM0z PMuCaqG0v8WPCLqBHS77ZP/kWpYjLXHs06fnZIXim0DtqaFDWhslLh0EOeBOhYKXTPWMl1D98M9Fw uBt8fIOCTqtP7pOvI5UTLLJVf5aNKXLgwvEKIZmZH3qBA89SZp7B+dHU8sCS08JdXLu5DdnawjVc4 HRtZ4ZNiLt7v4A==; Date: Fri, 05 Jan 2024 20:56:27 +0200 Message-Id: <831qavvcbo.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 5 Jan 2024 18:02:29 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 5 Jan 2024 18:02:29 +0000 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > > > Or consulting documentation. > > > > Again, only the mode's symbol is important. > > No. Say some consult-documentation minor-mode relies on > some setting of 'documentation-function'? I had info-look in mind. > > > Or anything we've built (including muscle memory) that lives on top > > > of syntactic abstractions like forward-sexp. > > > > Here you already bump into a problem, because most languages have no > > notion of "sexp", so making a TS mode do the same as a traditional > > mode is not easy at all. > > Of course they do!! How else would electric-pair-mode have worked > for virtually every language for more than 10 years forward-sexp moves forward even when there are no parentheses or braces anywhere in sight. > Well the reason why e-p-m and these things work today for most ts > modes is because they are also _using_ the Lisp/C parser based on > syntax tables and syntax-propertize-function. That's because a language parser will not have any notion of a sexp, so it cannot help. > > I invite you to compare CC mode with c-ts-mode, and see for yourself > > how the common grounds are very small. It seems surprising at first > > sight, but once you look at the code, it is very clear. > > And this is mainly because CC mode is, well, rather corpulent software, > let's put it like that. This is why I wrote it makes sense to start > from scratch for this one. A discussion where you brush aside any argument that doesn't fit your theory is not a useful one. In Emacs we have to solve problems that happen in the messy real world, not problems in an ideal world where everything is according to some elegant theory. > But would some kind of c++-base-mode hurt in some way? Presuming Alan > allows it, of course. Feel free to suggest such a base mode. If it works and is helpful, we will install it. Frankly, I doubt you could come up with a useful base mode like that: the differences are too large. > > > At the very least, it seems a common hook would be useful, and that's > > > what an empty foo-base-mode() would give. > > > > Where a base mode makes sense, sure. But even that causes problems, > > since the base mode leaves some stuff not set up. > > I don't follow. Can you give an example of a problem? Yes, look at python.el and sh-script.el. The base mode can only go so far, it must stop before it gets into the stuff that is really different between the TS and non-TS modes. This means that the base-mode hook will not see a mode that is ready for work, only its beginning. > In fact I'm happy to see exactly the strategy I suggested is already > done in ruby-mode.el and ruby-ts-mode.el. What problems are caused > by it? Some modes succeed in that, others don't. I guess it depends on the language grammar. > > and this various > > things that you'd want to do in a mode hook are impossible in the > > base-mode hook. > > I don't follow this part either. Can you give an example using, say > the existing ruby-base-mode. Again, look at the two examples I mentioned above. > In summary, my position is that regardless of Stefan's patch, which > I'm not opposed to, we should: > > 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when > possible. > > 2. have a remove-derived-mode-parent (for the other bug) > > 3. perhaps tighten up what we mean by derived-mode-p in the docs I have no opinion on that. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 14:04:03 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 19:04:03 +0000 Received: from localhost ([127.0.0.1]:57923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpUB-0008Tt-B5 for submit@debbugs.gnu.org; Fri, 05 Jan 2024 14:04:03 -0500 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]:45188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpU6-0008TK-71 for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 14:04:02 -0500 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2cd2f472665so11322681fa.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 11:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704481428; x=1705086228; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=0neHecBQ4zYJ+c84cFn3/0/Z3EZLi1Zlt3OSqXa4oY8=; b=D1/HXXiZu4K4Z32PyYYvJJMyVCdzMEvSSBQWMrnLfxW0G8VQIdrqYKyw2xZ1rxIbB6 YnE+fhQtWxOzwSsMv3NAl/odtyimGe9uLYce3wZnwGt0Al/JcEBqKoR44dW/9Ed0F9Y9 YbeI/ErTRMADoz4zlWQ659UagBmucsqkN67r39R3iCb75oMo29BsEtml+0rwtYscIYSQ oqSaidKJyaotLjEmMTWSAVL3AlXDVST2CmVFqrsAYQY2nAMBmpJQ0pHGklnN2/ut/CE7 +Y4N+E3AVPjFSE+yXAbG1WrvYCGu2Pw6bPPU4zAFDCx0LoieWoj7SdGAE0dc7tlN2PUI Mw0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704481428; x=1705086228; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=0neHecBQ4zYJ+c84cFn3/0/Z3EZLi1Zlt3OSqXa4oY8=; b=J4o/nBBBn0Wsa/1ZxcxUHp/0LZ2kSRaYiXvGr6s3RvIlxufafy3fDH/TlrEZoEoImW BSSKp2hrOSjhjKsr2DmKPzit8GwFsnQYpdcjRoEQ4ysVO6ZUsrnTtr9RzGKguPOQ1SkU +S8XnAzKB6OvwWIA7EK5EHMgmNqBcYn/HEmVwNLH0ZDJISN3Fmv5qNpHJSDExgKoUPe7 Ejb4VCkUi0SfAuv5wwfgDRJ878ccDaOojZqmodgtY8RYT7BxNu6L4xni3iONg1S1T74q iHleerbeD9N/DqNbXvv6FJAKKWufPoln9T2jsOl6qKv1Ak68gME+BmVX6fc+f0Wn8eB1 BvNQ== X-Gm-Message-State: AOJu0Yxf3P4JyNaVCGGTr1PkPY952g0XqhODrtadl9X6zxf2t4yTLglY eC4ExRGSkr429IgNZu2P06tBJ+g0mN+MpUo693A= X-Google-Smtp-Source: AGHT+IEjOA+N3XigsypQirl9PsDlBAWX8xIDZb12ggVoPWCl7eZYHuV58bEiFWVGhPNoYkaZ4Nq6THmlzq8FJUHVqmE= X-Received: by 2002:a2e:a26e:0:b0:2cc:708a:456f with SMTP id k14-20020a2ea26e000000b002cc708a456fmr1191722ljm.17.1704481427452; Fri, 05 Jan 2024 11:03:47 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 5 Jan 2024 11:03:46 -0800 From: Stefan Kangas In-Reply-To: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> MIME-Version: 1.0 Date: Fri, 5 Jan 2024 11:03:46 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Eli Zaretskii , Yuan Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > In summary, my position is that regardless of Stefan's patch, which > I'm not opposed to, we should: > > 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when > possible. I agree that inheriting from a `foo-base-mode' is a good way to reuse code between different modes. It's easy to think of examples of where this will be useful: looking up some documentation, running a REPL, interacting with a debugger, and so on and so forth. But even if we added all the base modes today (as empty stubs), AFAIU it wouldn't solve the exact problem that Monnier's patch is addressing, namely to make packages and customizations work in both foo-mode and foo-ts-mode even if they only say: (derived-mode-p 'foo-mode) So I'm not sure doing one excludes the other, or that one should be considered preferred over the other. IOW, I'm not sure about the recommendation to use `add-derived-mode-parents' sparingly, as that would seem to defeat the point. Am I missing something? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 14:12:03 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 19:12:03 +0000 Received: from localhost ([127.0.0.1]:57941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpbv-0000Ej-IU for submit@debbugs.gnu.org; Fri, 05 Jan 2024 14:12:03 -0500 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:55474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpbt-0000EF-TN for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 14:12:02 -0500 Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cd0c151cdcso24183651fa.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 11:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704481911; x=1705086711; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=yJr40T6Ftz5ypC0qcVYBIcAZ63EZWL89Cnh6Hm6s9UE=; b=DK+YWz18FQpAkEm48CltvumBxyOZB+XR7bv5Ekidto3EEMAkXEYslRTqoV1UUCcvbT ruoOjl1TFxRONuc2YJsIKuRAv22XHvBeBqqeyXj1I3q9g8KLaUMK7jds3icNCdrwsEHC RElQFipyo1PSO7GKYYV8da+JLo19OJpRWqGuJiYyztyYI5RSEuQCr+pcofkiUepyrd2O BPZ+54gakjXno/l9g1AJgcLMgKvnIpGwiTfwRWVpaOLB+U3mH/tRA51COaax0OuntTUD zDKVG010OqIh0nVnRgNufPuFylA9b2V1zomVLYpzVh35foktQovp+KOijovFZSdhJCQE nnIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704481911; x=1705086711; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yJr40T6Ftz5ypC0qcVYBIcAZ63EZWL89Cnh6Hm6s9UE=; b=PkvMJ3Ww50oI3jBlAz2A+AtRpHJQm62xpj4Ka+B3mondNDM8H0eL3e4m8B4FtDAb+b OixUXTYjZu31XIWvV1UJv7v+PkOVVoo0hc7VIdqzEcR/I5VnXcAQASxwEuvUWZ5Cxj36 Kt1YyXLT40I7CdRLR2dOkN9opJBDeFp8LMO3D7veJGwUBjGUIkWHeUMGpmIbiYJCPatS SINUeyGnDOeD5h3g+uJ6bsJNcqjaEuF+bt/xEe2cVZLcNfamv8I+3Nnjqzi2Cz+BQLND YwqT8ShP3yCZ0uUq6ChH/be344h4bTwny7f1TPIsj9UnJ+DLD4Ubf1NrDwoU1OVuc0I1 MDpA== X-Gm-Message-State: AOJu0YwAkKdnezTM8SO3IhNngMyApCgI1dV6w5LypVhDEvISxH8I4AWv 3WWXHSUMsdZbHL/8XU7woqwZzO85EAa+YRxq8AxCJjL6 X-Google-Smtp-Source: AGHT+IF5+l2e9QvrMAuCZu4N0IFhldqaGjt9wMM1PICHDGH+u6YQjHr1nGqp/6V/D9SwvfUaQx+O5uKKdmVXoVYsN1k= X-Received: by 2002:a2e:9848:0:b0:2cc:cc56:ef9d with SMTP id e8-20020a2e9848000000b002cccc56ef9dmr1297891ljj.16.1704481911253; Fri, 05 Jan 2024 11:11:51 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 5 Jan 2024 11:11:50 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 5 Jan 2024 11:11:50 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: 68246@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas writes: > We should probably also change *Help* to displays the extra parents, or > this will be pretty confusing. It should probably both list it as a > parent mode, and say that it will run the corresponding hook. Correcting myself here: the hook shouldn't be called out here as it won't get run. So please disregard that part. But it should say something about the extra inherited mode. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 18:20:56 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 23:20:56 +0000 Received: from localhost ([127.0.0.1]:58118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtUl-0008Uq-IL for submit@debbugs.gnu.org; Fri, 05 Jan 2024 18:20:56 -0500 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:60422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtUf-0008UK-E7 for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 18:20:54 -0500 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-50e67e37661so95168e87.0 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 15:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704496839; x=1705101639; 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=gJVA8T+fDBYkBHW6tK8hgaa5VvyqL8KG6VG2oo+tVGo=; b=EkIXdx8cPavzk08LF+nbIXIpBwvUiKptGrZt+G9fQT2NQLsDmzP7fZpES3+10jLQiB GexEgWgcC9P0WEve2uBSFejxu1YP1ujnYSDKe68nSgv57joJ9Yo14ZP0yVKlquHO53C8 xJsY1mcPW+rw9ZqaYVuSAdMN0zoe/JaWIm9hgv41zohqElZEu3CrcZ939CqHMzRpVuIv J+5a8WSIOwwf8h6p42CtInMe2H/CQxhRX0kG3dg9+Gk0YMGVjs9HsduiuDkoNG/RGgMk DftnvLrRdHVSxZdTqzzPsWKQzWledDU8ffCXGPffyYX0AtNUnhJue1d57mtzovhullE3 iRWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704496839; x=1705101639; 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=gJVA8T+fDBYkBHW6tK8hgaa5VvyqL8KG6VG2oo+tVGo=; b=VauEWp67jtZfilWhYG/pTCrXP0XMKreHyX/LmX5h6D46CUMVE5Uhy1jIEMpxus7Dto H7QTJ5nOMDog0anGW4UEsTJ0sBNNmhazQTBuHY8nv48v7RIMcLhg4RPFeHSeQTZpQurz kpXt6MUEHl5lmNPTX8UXSUQD2yXVuPq0s91YKJyZU57tbbz51xtwTW4MD2vdGD4HljhL oiJlzSNQNdP0puYJskqyEDh+KoTHirjOU14UsLIfl0i7phdf9qCRcrjKLOWF0rRCdpxS pStNnuEnUMXpSnZoqws+tlEA0WFL5Yq3Jy6sM/gp5WLp/3f4zxEEMHMCRinzZQl19+N/ C6xQ== X-Gm-Message-State: AOJu0Yz3J3yo3J9sLQ4CH1G6LiGEz7p44pb6CGUSUv8nBpSlOEK4s/JA 9vjhuBXcTMsihu6b4/8abaWxbfCjBrahzAKs8uo= X-Google-Smtp-Source: AGHT+IFzZNvk8H59QvMRLE5ABjFheUvhgKw7G9vAt/EciRY1WcocuuorsQ0vGfg7aflzqsGYOkS31yV4SeeSxXcePyM= X-Received: by 2002:a05:6512:318e:b0:50e:7a9e:5c1d with SMTP id i14-20020a056512318e00b0050e7a9e5c1dmr96933lfe.0.1704496838569; Fri, 05 Jan 2024 15:20:38 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: <831qavvcbo.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 23:20:26 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 6:57=E2=80=AFPM Eli Zaretskii wrote: > > Of course they do!! How else would electric-pair-mode have worked > > for virtually every language for more than 10 years > > forward-sexp moves forward even when there are no parentheses or > braces anywhere in sight. electric-pair-mode uses scan-sexps. Scan-sexps works perfectly to navigate nested mixed delimiter structures of modes that are not Lisp, otherwise e-p-m couldn't do it's auto-balancing job. > > Well the reason why e-p-m and these things work today for most ts > > modes is because they are also _using_ the Lisp/C parser based on > > syntax tables and syntax-propertize-function. > > That's because a language parser will not have any notion of a sexp, > so it cannot help. As I am trying to explain, it doesn't have to be a "Lisp sexp". It just has to be something that scan-sexps can navigate, and scan-sexps works in all modes. I'd think that at least with a good enough grammar it's perfectly possible to do e.g. show-paren-mode with TreeSitter alone. And the way this could work in Emacs is for TreeSitter to feed into scan-sexps. > > > I invite you to compare CC mode with c-ts-mode, and see for yourself > > > how the common grounds are very small. It seems surprising at first > > > sight, but once you look at the code, it is very clear. > > > > And this is mainly because CC mode is, well, rather corpulent software, > > let's put it like that. This is why I wrote it makes sense to start > > from scratch for this one. > > A discussion where you brush aside any argument that doesn't fit your > theory is not a useful one. ? You write this precisely in the point where I _agree_ with you. That's the really the opposite of brushing aside. > > But would some kind of c++-base-mode hurt in some way? Presuming Alan > > allows it, of course. > > Feel free to suggest such a base mode. If it works and is helpful, we > will install it. Frankly, I doubt you could come up with a useful > base mode like that: the differences are too large. As I am trying to explain, even a one-line empty base mode is useful. > > > > At the very least, it seems a common hook would be useful, and that= 's > > > > what an empty foo-base-mode() would give. > > > > > > Where a base mode makes sense, sure. But even that causes problems, > > > since the base mode leaves some stuff not set up. > > > > I don't follow. Can you give an example of a problem? > > Yes, look at python.el and sh-script.el. The base mode can only go so > far, it must stop before it gets into the stuff that is really > different between the TS and non-TS modes. Very well, we are violently agreeing. > This means that the > base-mode hook will not see a mode that is ready for work, only its > beginning. Correct. But a major-mode doesn't have to be "ready for work" (I presume you mean ready for editing) for the hook to be useful. That hook would be perfectly suitable for setting variables used by minor modes and other things. (eglot-server-program, flymake-diagnostic-functions, company-backe= nds, mode-line-format, etc etc) For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-mod= e,) For binding commands. And even without the hook the mere fact that foo-mode and foo-ts-mode are derived from foo-base-mode according to derived-mode-p makes it useful. > > In fact I'm happy to see exactly the strategy I suggested is already > > done in ruby-mode.el and ruby-ts-mode.el. What problems are caused > > by it? > > Some modes succeed in that, others don't. I guess it depends on the > language grammar. I don't see the problem, really. Now I see that many mode "base modes" alr= eady exist. That's great! That's at least four simplifications to eglot.el's eglot-server-programs (ruby, python, js and bash/sh). I'd be happy to know of more if someone has a fuller list. And all the base mode definitions could well have settings for the upcoming eglot-server-program. > > > and this various > > > things that you'd want to do in a mode hook are impossible in the > > > base-mode hook. > > > > I don't follow this part either. Can you give an example using, say > > the existing ruby-base-mode. > > Again, look at the two examples I mentioned above. I couldn't see the problem in either python.el or sh-script.el. What do you wish you could do in those base mode bodies on have the user do in the base mode hooks which is impossible? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 18:38:11 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 23:38:12 +0000 Received: from localhost ([127.0.0.1]:58124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtlT-00034N-HS for submit@debbugs.gnu.org; Fri, 05 Jan 2024 18:38:11 -0500 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:52335) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtlS-00034A-3Q for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 18:38:10 -0500 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cd33336b32so745671fa.0 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704497879; x=1705102679; 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=ykIWutQ8k/rdmbtEn29ZH16wvGDTrPYTrIZUBCNTzFg=; b=mVoAXDubxIFNJek8Ursw1KTs/OH9/fy+vRDNmXNNdRF3W9ng6EaZ5ll97HEVgq6d8B yr2g1nvBUUgbGRhV2uR8ERyUyZPSvUvsdS42/oNMfRuA7KF9qlHFiCkXDqx8NfkZpoiL ZhdG9NoUmi07pzlbsqNzUZwIELmQ2XbhT7N3oSZC8gKBNZasx9WYSwr6een0+2tkfPB/ v4caUrMP+3k1CwZRC6NnSQzQT1a7UHScvNGWpkI0/qChK5HDGZ4DcDcE9pvvAFsYL2qG ZUcvou8jY1WCcdPZciKks3q5MAih8kWzfuzk4TzSwY0qpaDOpqWZBEHb3OAEzGzzaR3c 3wbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704497879; x=1705102679; 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=ykIWutQ8k/rdmbtEn29ZH16wvGDTrPYTrIZUBCNTzFg=; b=SELvg3cafpHW/BcKn+gNmuVYg4Hzirz3v+saTWKD6Dw4zrA8nN2ICMBh1m5SDlwXdN i2J7rk1w65nItQHsoOAf4J6i2WPOny5brohBYHEojbPwYBgk1kVumG6SJ1PjgQ6NUeHH t4e0PkcNx7GgyINQHrNVC2p088BpUqopO0u19fM6PL9cvJxVCF76JvOHtPrBPtwqhxPA IM/HkFDHXoxACtDr6aMUAx6JkBVNLqUogNmtdxVnM+gmULPcem4WHzDSELDq2LUgcMzs z34Ar2Hf4bzbh+AFiZVekgoqIjS0Lq+qg6+vh4NNe3sbOq83vhhHSUvoX0C5JgzQyA5t POow== X-Gm-Message-State: AOJu0YwqsEvUQg0omqQe0SFMCOhvb1/7h/LVwR2RARDn36EFFIe9ooN5 +avgdTxiFnv8GxCnfV7QMwKVl5CAAM/k5qerfSA= X-Google-Smtp-Source: AGHT+IFWeGWIujPvSjzIWfWh7yUvA5sVPCz8LGIeJh3y2ed4Ic5V2tDXEZWJ2DI183mLhIDk2pbXBclfLtGuykDtOU8= X-Received: by 2002:a05:651c:1986:b0:2cc:e3b7:f7a3 with SMTP id bx6-20020a05651c198600b002cce3b7f7a3mr55406ljb.71.1704497878703; Fri, 05 Jan 2024 15:37:58 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 5 Jan 2024 23:37:46 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Kangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 7:03=E2=80=AFPM Stefan Kangas wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > > In summary, my position is that regardless of Stefan's patch, which > > I'm not opposed to, we should: > > > > 1. Use add-derived-mode-parents sparingly and consider foo-base-mode wh= en > > possible. > > I agree that inheriting from a `foo-base-mode' is a good way to reuse > code between different modes. It's easy to think of examples of where > this will be useful: looking up some documentation, running a REPL, > interacting with a debugger, and so on and so forth. Exactly. It's much cleaner and I am happy to see exactly what I had idealized is already in the tree. > But even if we added all the base modes today (as empty stubs), AFAIU it > wouldn't solve the exact problem that Monnier's patch is addressing, > namely to make packages and customizations work in both foo-mode and > foo-ts-mode even if they only say: > > (derived-mode-p 'foo-mode) That's why these packages should be changed to say (derived-mode-p 'foo-base-mode) Or maybe (cl-some #'derived-mode-p '(foo-mode foo-base-mode)) I'm not sure there is a problem in doing that, is there? I can confirm there isn't in Eglot and Yasnippet, two packages that use major-mode how Stefan Monnier described it. How many more are there and is it really so hard to change them? Or is it that we're deliberately trying to establish that 'foo-mode' is the canonical symbol designating a family of potentially many major modes -- including, somewhat confusingly, 'foo-mode' itself -- that are used for editing foo source code? If so, fine, but this should be very well documented. And yes, definitely called out in *Help*. The concept of "major-mode family" could emerge, perhaps. > So I'm not sure doing one excludes the other, or that one should be > considered preferred over the other. IOW, I'm not sure about the > recommendation to use `add-derived-mode-parents' sparingly, as that > would seem to defeat the point. Indeed one may not exclude the other, depending on how feasible it is for extensions to start using the foo-base-mode. Maybe it depends what are these many packages that use "major-mode" in such ways. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 18:51:56 2024 Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 23:51:56 +0000 Received: from localhost ([127.0.0.1]:58141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtym-00065O-6J for submit@debbugs.gnu.org; Fri, 05 Jan 2024 18:51:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtyk-000659-6q for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 18:51:54 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3F72510009E; Fri, 5 Jan 2024 18:51:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704498703; bh=KDbcOCxvisRvg+sEh8aS0AO/6vuly3DBh1574Rp5dRQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TtFGc6bRwwxx8y79HJfkvqN5Wm3TbvEuz71LYm+B5BRJPYtdqTEmV5gM9T3M0ddSD l7Ouvd4IHmbFDmkl0H0x/7OLYvsFLak2OKOu51a0noyuJu86rw7pnEI1ZSaQU6tk4R KTmx5nxZNc1sBW6WmrGJnghtjbnJUSUywR7wnN9HkGplB0YJQgFRntMXLqP07+RoPv tys3dq4y+Ybrgj4iCh1RrTkGj8pBC3Dsf+n9SLtxh2cypPzN+YajY2jpKJsJ7GoQS1 HSKI0sgfCddeVVZSAH22zqSKyOIdJ5WPdo3x+Wrt6HPIkaX7b1rIUfSKlFYmRyxulL I4Y+knf89/img== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 10A49100068; Fri, 5 Jan 2024 18:51:43 -0500 (EST) Received: from milanesa (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C6391120C25; Fri, 5 Jan 2024 18:51:42 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 5 Jan 2024 23:20:26 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Fri, 05 Jan 2024 18:51:41 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.320 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [ IMO, it would indeed be a good idea to try and write some abstraction layer so we can share more code between modes parsing with syntax-tables/tree-sitter/wisi/SMIE/younameit. It will also be very useful when tree-sitter goes the way of the dodo. But that's a difficult job, and with limited immediately-visible benefits to the end users. In the mean time, we're stuck with major modes that don't share much code. ] Whether it's worthwhile to have a `FOO-base-mode` or not depends on the specifics, but it's largely an implementation detail. More importantly it's not directly relevant to this here bug, because I want to say "FOO-ts-mode is a kind of mode for FOO, so it's a kind of FOO-mode". There are very few YASnippets for FOO-base-mode, instead they're all for FOO-mode. Similarly, Eglot doesn't have rules for FOO-base-mode, only for FOO-mode. That's why in my patch I add `python-mode` as an extra parent of `python-ts-mode` even though they both share `python-base-mode` as their parent. IOW, in my patch, I'm using `FOO-mode` not really as the name of a major mode, but rather as the name of a *file type*. I already mentioned this distinction in the bug-report where I introduced `major-mode-remap-alist`: Emacs usually conflates file-type and major-mode, which works great where there's only one major mode for a given file type, but less great where there are several alternatives. Stefan Jo=C3=A3o T=C3=A1vora [2024-01-05 23:20:26] wrote: > On Fri, Jan 5, 2024 at 6:57=E2=80=AFPM Eli Zaretskii wrote: > >> > Of course they do!! How else would electric-pair-mode have worked >> > for virtually every language for more than 10 years >> >> forward-sexp moves forward even when there are no parentheses or >> braces anywhere in sight. > > electric-pair-mode uses scan-sexps. Scan-sexps works perfectly to > navigate nested mixed delimiter structures of modes that are not Lisp, > otherwise e-p-m couldn't do it's auto-balancing job. > >> > Well the reason why e-p-m and these things work today for most ts >> > modes is because they are also _using_ the Lisp/C parser based on >> > syntax tables and syntax-propertize-function. >> >> That's because a language parser will not have any notion of a sexp, >> so it cannot help. > > As I am trying to explain, it doesn't have to be a "Lisp sexp". > It just has to be something that scan-sexps can navigate, and > scan-sexps works in all modes. I'd think that at least > with a good enough grammar it's perfectly possible to do > e.g. show-paren-mode with TreeSitter alone. And the way this > could work in Emacs is for TreeSitter to feed into scan-sexps. > >> > > I invite you to compare CC mode with c-ts-mode, and see for yourself >> > > how the common grounds are very small. It seems surprising at first >> > > sight, but once you look at the code, it is very clear. >> > >> > And this is mainly because CC mode is, well, rather corpulent software, >> > let's put it like that. This is why I wrote it makes sense to start >> > from scratch for this one. >> >> A discussion where you brush aside any argument that doesn't fit your >> theory is not a useful one. > > ? You write this precisely in the point where I _agree_ with you. > That's the really the opposite of brushing aside. > >> > But would some kind of c++-base-mode hurt in some way? Presuming Alan >> > allows it, of course. >> >> Feel free to suggest such a base mode. If it works and is helpful, we >> will install it. Frankly, I doubt you could come up with a useful >> base mode like that: the differences are too large. > > As I am trying to explain, even a one-line empty base mode is useful. > >> > > > At the very least, it seems a common hook would be useful, and tha= t's >> > > > what an empty foo-base-mode() would give. >> > > >> > > Where a base mode makes sense, sure. But even that causes problems, >> > > since the base mode leaves some stuff not set up. >> > >> > I don't follow. Can you give an example of a problem? >> >> Yes, look at python.el and sh-script.el. The base mode can only go so >> far, it must stop before it gets into the stuff that is really >> different between the TS and non-TS modes. > > Very well, we are violently agreeing. > >> This means that the >> base-mode hook will not see a mode that is ready for work, only its >> beginning. > > Correct. But a major-mode doesn't have to be "ready for work" (I presume > you mean ready for editing) for the hook to be useful. That hook would > be perfectly suitable for setting variables used by minor modes and other > things. (eglot-server-program, flymake-diagnostic-functions, company-bac= kends, > mode-line-format, etc etc) > For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-m= ode,) > For binding commands. > > And even without the hook the mere fact that foo-mode and foo-ts-mode > are derived from foo-base-mode according to derived-mode-p makes it > useful. > >> > In fact I'm happy to see exactly the strategy I suggested is already >> > done in ruby-mode.el and ruby-ts-mode.el. What problems are caused >> > by it? >> >> Some modes succeed in that, others don't. I guess it depends on the >> language grammar. > > I don't see the problem, really. Now I see that many mode "base modes" a= lready > exist. That's great! That's at least four simplifications to eglot.el's > eglot-server-programs (ruby, python, js and bash/sh). I'd be happy to > know of more if someone has a fuller list. > > And all the base mode definitions could well have settings for the > upcoming eglot-server-program. > >> > > and this various >> > > things that you'd want to do in a mode hook are impossible in the >> > > base-mode hook. >> > >> > I don't follow this part either. Can you give an example using, say >> > the existing ruby-base-mode. >> >> Again, look at the two examples I mentioned above. > > I couldn't see the problem in either python.el or sh-script.el. What > do you wish you could do in those base mode bodies on have the user > do in the base mode hooks which is impossible? > > Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 19:16:29 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 00:16:29 +0000 Received: from localhost ([127.0.0.1]:58147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLuMW-0003Hw-QR for submit@debbugs.gnu.org; Fri, 05 Jan 2024 19:16:29 -0500 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:57369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLuMT-0003Ay-J5 for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 19:16:26 -0500 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2cce6c719caso774021fa.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 16:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704500175; x=1705104975; 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=R662cBevtu78MocBPURfWzwf3WYX+muP/lGQgZEB+dc=; b=nIjgSVZlFpbqi7iUQ/UfGIQ13Z64jcFWJcw0E8MnJ9S1g/zqhU34wLLfFB1d8tV7/2 Bsg15pXcuRwboKG8LRuI3fEKHVWSo+ISvKKwjqjZ67Xo2Bd+9HfxJ8YKjA6NYiPUstqI euT4uUbyOBE6yjmD7U4FX+V2LpLjQ6RrKPJxgIu7FlK04pT25HQSy9L/C/BwXTYypOyL LEvlz+QmJOHafcNgfM7XPnRTdKKcuQLvUldZx6M70IAxwZ5yY8NnhInSTMHzEZCk0Ir5 XQiFxwyjyUIwKDXlOwuLc3+l93dl9RhjTW0wrviXb2DG2tjzE02gxCVgvLvmBttfpu1+ 3E1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704500175; x=1705104975; 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=R662cBevtu78MocBPURfWzwf3WYX+muP/lGQgZEB+dc=; b=J3YGZGrTgXnhYNel6UhPlTBf05jnkdSIQJWFFm6e66qAoV7PQKmQ3PnqfvmCMuTaxB /2IEtQaOFMfSVq14+BJ3PKkt38B+fhhQOlZaDyEsRc52+Q3K6qV5AZMURelIcQlg69Tf L0u9PKXs+mj8nm2o+r5TFJs2AQH0rJTpKu1Mb7Uum/tg6Fneoq+xgdeUWmIgUJ5OO0Pg 1r/tBRU3p9BoveFmVTbl3L3FVbRGn6rmDnG7KX/HGE9m4RmVbGGwZj18Z1bwL5MzUm1g gkI/769R9ByheIo2L9224nmf+rNQfD2s2y3br3fV88zWSyKxoBKf4RpG+YhXYtO7g1f5 ABGA== X-Gm-Message-State: AOJu0YxA3BviVzsSLNQs19kApD8QDhPhX/CMmzRJr8InSmPW1Tihvw/E aXC2goi2hluyvCbZpVEVYEoyMK/nseRL78xgryg= X-Google-Smtp-Source: AGHT+IGU8u5WlgfGshe0BEN9s18qGzeDeCBt76TNbsb5+BTkGULh5RSJ/L5g45QsOI0R8KBqu3kzM8pU6pbdd1yQr5s= X-Received: by 2002:a2e:98d7:0:b0:2cc:d4e2:e0b1 with SMTP id s23-20020a2e98d7000000b002ccd4e2e0b1mr66812ljj.1.1704500174453; Fri, 05 Jan 2024 16:16:14 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 6 Jan 2024 00:16:02 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 5, 2024 at 11:51=E2=80=AFPM Stefan Monnier wrote: > > [ IMO, it would indeed be a good idea to try and write some abstraction > layer so we can share more code between modes parsing with > syntax-tables/tree-sitter/wisi/SMIE/younameit. It will also be very > useful when tree-sitter goes the way of the dodo. Very relevant. > But that's a difficult job, and with limited immediately-visible > benefits to the end users. In the mean time, we're stuck with major > modes that don't share much code. ] > > Whether it's worthwhile to have a `FOO-base-mode` or not depends on > the specifics, but it's largely an implementation detail. More > importantly it's not directly relevant to this here bug, because > I want to say "FOO-ts-mode is a kind of mode for FOO, so it's > a kind of FOO-mode". OK, so "kind". So you seem to want to FOO-mode designates a family of modes for FOO. That's reasonable but it has the confusing property that the name of the family coincides with the name of one of the members of the family. Using inheritance for that just seems a bit off, like a hack. Really what we wanted is a new variable called 'mode-family' and test against that. > There are very few YASnippets for FOO-base-mode, > instead they're all for FOO-mode. Similarly, Eglot doesn't have rules > for FOO-base-mode, only for FOO-mode. Right. But we can change Eglot and Yasnippet, can't we? I know what to do in Eglot, which is something like this: (defvar eglot-server-programs `(((rust-ts-mode rust-mode) . ("rust-analyze= r")) ((cmake-mode cmake-ts-mode) . ("cmake-language-server")) (vimrc-mode . ("vim-language-server" "--stdio")) - ((python-mode python-ts-mode) + (python-base-mode . ,(eglot-alternatives In Yasnippet, if I remember correctly (it was a long time ago), the snippet directory could either be renamed foo-base-mode or something in a .yas-parents inside that directory can be added containing "foo-base-mode". As to the problem that this doesn't work in Emacs < 30, we must either: * also keep the old definitions, or better * use compat.el like Eli suggested to bring in those new base modes (whereby compat.el could use derive-mode-add-parent itself, but for but adding foo-base-mode as a parent of foo-mode and foo-ts-mode instead). > That's why in my patch I add `python-mode` as an extra parent of > `python-ts-mode` even though they both share `python-base-mode` as > their parent. Right, that's what sounds hacky to me. They're siblings, but now one also is the parent of the other. Maybe it works, but is definitely odd. That said, if it works, I'm not really opposed to it. What other packages do you know like Eglot and Yasnippet which use major-mode in this way. > IOW, in my patch, I'm using `FOO-mode` not really as the name of a major > mode, but rather as the name of a *file type*. > I already mentioned this distinction in the bug-report where > I introduced `major-mode-remap-alist`: Emacs usually conflates > file-type and major-mode, which works great where there's only one major > mode for a given file type, but less great where there are > several alternatives. Agree, so your "file-type" seems to match my idea of "mode family". So a new variable called file-type would be the correct abstraction. And I don't see how "foo-base-mode" is much worse, modulo slightly more akward naming and backward compatibility problems that you would have anyway. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 22:20:10 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 03:20:11 +0000 Received: from localhost ([127.0.0.1]:58235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxEI-0005eF-JT for submit@debbugs.gnu.org; Fri, 05 Jan 2024 22:20:10 -0500 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]:61844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxEG-0005dz-IM for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 22:20:09 -0500 Received: by mail-il1-x131.google.com with SMTP id e9e14a558f8ab-35fff22678eso1107085ab.3 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 19:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704511198; x=1705115998; darn=debbugs.gnu.org; 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=LBmP4uckJgKQe3eStPjV10Ug9RVqo7iPioisdziSDAw=; b=Rg/GxNoyqriUKgyCOV1jYh66RHQTtTFu4rxVO1fMSE0CpKSKroNetElhKHjAfYVQE6 d64mgGzuuVmY5o8nEaeOIT7MKkZNDb8SZ9jmGb2fImhnDwFhEmYPd4Q+uQBpkAktF/Od NKxgr2eSWTLpVklPCtXEKT8GN++r7VRWgmXsnVR6ZUNRJSYRMVbRO9i8NPlG3qbeDgmy nb/O3JtohZNMWDemPfSdxYkrFgUVAKBq3EUar2ECEyfi8izGXQVgF8h1uBNrpyGXxAP4 FxHyWFWSvizSbcjFVDnxI3FaYgOScUr0r58aCqUYN66Y493F336uQSkTmqsqIBqu+pEH l3jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704511198; x=1705115998; 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=LBmP4uckJgKQe3eStPjV10Ug9RVqo7iPioisdziSDAw=; b=jEH79Qb5xlG/MXU9+ZQp3Tlsz4CD+SVFChZPSAsR1EoYSnHsiEmYbRAAGX+hmUX9nP g6IB0yY7m/k8Jqy+DIQrFjoLFEr5rT+a+1pR9SySwKWsKoQPzWCOG2soi2AZ8zrse20K Tl7AWj+rEM7kVYPU9zS4CGWsTIzie3Uhir32Nt9m9rkIs/Z8wYG0qjGX1mzENj5QbtWN 6zejW34ltUaHTxeehwSegrtTu05r52L85rkOxySWd6Sr0G/80RTdec9Xi1wl5XhrRQ1m o7IjR9IzgvOp468QiRdP322uJ4et/o/9LpINR/0QcWLZPc5mFns7HEPmauUc2D2WdB49 N+pg== X-Gm-Message-State: AOJu0YxmJk5ImcY1xHWDygxiRbao7bvxvuLP68pvsLK05M0VYPHWO4sJ KuhumEboRNC67pQxUFPd+fk= X-Google-Smtp-Source: AGHT+IEQCjPjjR2H58QHqw1WkZYkKb2QVA8QLCQbukNLknwme08ad9iBZezZxk3gm0ehaL0PTmzveg== X-Received: by 2002:a05:6e02:1748:b0:35f:ec66:154e with SMTP id y8-20020a056e02174800b0035fec66154emr622535ill.64.1704511198105; Fri, 05 Jan 2024 19:19:58 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id jv5-20020a170903058500b001d4e765f605sm2086699plb.269.2024.01.05.19.19.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2024 19:19:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: Date: Fri, 5 Jan 2024 19:19:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 solution. For one, adding the base mode needs cooperation from = all the major mode authors. For built-in modes, that=E2=80=99s not a = (big) problem; for countless third-party modes out there, I don=E2=80=99t = have high hopes for it. 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 themselves. Then there is the problem Eli pointed out, base-mode hooks runs before = child 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.) Obviously derived-mode-add-parents can=E2=80=99t help with hooks. But = adding the config to two hooks doesn=E2=80=99t seem to be too bad. Plus = I haven=E2=80=99t come up with good solution. So I=E2=80=99m not too = eager to solve that inconvenience.=20 As for adding xxx-mode to xxx-ts-mode=E2=80=99s parent, I think it=E2=80=99= s fine? Like others in the thread, I couldn=E2=80=99t think of a = scenarios where this will be problematic. I thought about adding = xxx-lang as the parent of both xxx-mode and xxx-ts-mode, but that=E2=80=99= s probably not very helpful, since the goal is to make things work for = ts-mode without needing to change the existing code, and using xxx-lang = still requires modifying existing code. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 22:36:29 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 03:36:29 +0000 Received: from localhost ([127.0.0.1]:58246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxU4-0000Iu-OM for submit@debbugs.gnu.org; Fri, 05 Jan 2024 22:36:29 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:36221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxU2-0000IY-7B for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 22:36:27 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3FB773200AAA; Fri, 5 Jan 2024 22:36:15 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 05 Jan 2024 22:36:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704512174; x=1704598574; bh=f3HgSTkNGzycmG1GkjHsBXYdKj3Mcvj+TM2LAjJJQbw=; b= opj4RCAe1f/qbc0b+ereeZel+h/aw16xB4G3ECnmWm7zKyeGj/+9Mrofr1zhZm8M 58kNDiJ2zlYm/P39Qvd6wbJIFT4MIhro0XsfsPWA7QdX/7vlab+BsQvJwaV6Ro6j d95+JH2uxuIAdVcFan73RwTrlabvGCka9KD+5VbhxC1arVLF7KyKt/uQCPbVVthL jzscPacxmujBkRjiOArj9wEImoQ5STajuRjQQF4XcJe7VB6dDaDsM1XvIShU/aGI RTBk/Gyirdfm8fu+cPOTRq9fhgqEKNklYzxVbwVuXGz4j1GmNv6fCm4nHH2qQTm+ O2k/P2Xw1fCY6wzmICeIAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704512174; x= 1704598574; bh=f3HgSTkNGzycmG1GkjHsBXYdKj3Mcvj+TM2LAjJJQbw=; b=y zUKkFlF6MIaFZhZmV1BKkQU8P9+9SNTg1NYYBuB6MhSA+y31Ju9p95nB6e6bl0o4 DIbKk7CLRzA8qRKXrwKErSYws5pKYDPUjgFSUv5GpHUhTBSJ5dSagxiPiZogWUUR jJJOdqy4z6h4F+EynBsZ0YgnlxwxAHuO3GcCETLiJzTT6dSOKpp7LKbf38XX2o9m r4pm4GIbKbL7Wifc4Ll2NWNcasDp8SaKdH1YiKcN3DfKFPAIqeOs1tiWmiTyHnpj vGEd3E2tLo+YJq75+5MYChXKOz0vP+FgIlHJ/dEbYF2VKkxL/jIZVPsd2iEqCioI xQIWp9aGUmHwCvG6KAYyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehtddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 Jan 2024 22:36:12 -0500 (EST) Message-ID: <7575dc49-d08e-4dd9-aa10-3ea61357e350@gutov.dev> Date: Sat, 6 Jan 2024 05:36:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Yuan Fu , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 06/01/2024 05:19, Yuan Fu wrote: > The good thing about derived-mode-add-parents is that it doesn’t need major mode author’s cooperation. Even a normal user can do it themselves. True. > Then there is the problem Eli pointed out, base-mode hooks runs before child major mode body does. It’s 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’t help. (Arguable a niche use-case, but my point is base-mode hooks have their limits.) This is the same for all other case of mode inheritance (e.g. js2-mode inheriting from js-mode, or python-ts-mode inheriting from python-mode). It would be odd if some inheriters would have this inconvenience, and others not. > Obviously derived-mode-add-parents can’t help with hooks. But adding the config to two hooks doesn’t seem to be too bad. Plus I haven’t come up with good solution. So I’m not too eager to solve that inconvenience. I was thinking some "proper" language registry is the way to go. Like a custom structure tracking the correspondence between file names and languages, and a separate association list for lang->major-mode. But it would require more changes indeed. > As for adding xxx-mode to xxx-ts-mode’s parent, I think it’s fine? Like others in the thread, I couldn’t think of a scenarios where this will be problematic. I thought about adding xxx-lang as the parent of both xxx-mode and xxx-ts-mode, but that’s probably not very helpful, since the goal is to make things work for ts-mode without needing to change the existing code, and using xxx-lang still requires modifying existing code. OTOH, the required changes could be made fairly minimal (aside those in the user's config): add a new keyword to define-derived-mode which would add (run-hooks 'xyz-lang-hook) at the end. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 23:08:56 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 04:08:56 +0000 Received: from localhost ([127.0.0.1]:58267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxzU-0006US-6i for submit@debbugs.gnu.org; Fri, 05 Jan 2024 23:08:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLxzR-0006UA-Hs for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 23:08:54 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 63CF180A64; Fri, 5 Jan 2024 23:08:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704514122; bh=MqB3zMAktUgq3tQ05DFlqxQkkiaqEA2g27MszrBBIjw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mOFOd3K3n2C22BbNxM6zk+LnxR7mGKRr46Zhio/y4v3tALFMCitEpikmk7WznIkh5 I/VXf4//s2cJdb4YJRP5loWdMgUwjcdBExJjkYDvSfVjuPP58qovl59FTFTckkOna2 3cb4QVW3o0BlUHE2LyFiQyUkWOAK7ksrXOA6UlC8SoCa2SG8p8p3cz1wZirUIJwXMD 8R1ZK6Ba4j4Aob2El0shtywuCZfxcPrqkrTXbvleeinoeKS7lqfbzGq1Nw9aE1NZcK ROd5vQhiwDTatd0PGS4NAPeA/2qqiOmL+XT2Wm6OrSmNmMouaCIWzaVdrYfJv7ixhI Y3mezqQo2CuoA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 181A3802DA; Fri, 5 Jan 2024 23:08:42 -0500 (EST) Received: from milanesa (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D154C12023B; Fri, 5 Jan 2024 23:08:41 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Sat, 6 Jan 2024 00:16:02 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Fri, 05 Jan 2024 23:08:40 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > OK, so "kind". So you seem to want to FOO-mode designates a family > of modes for FOO. That's reasonable but it has the confusing property > that the name of the family coincides with the name of one of the > members of the family. It's actually very common. Take "Lisp" as an example. Similarly, `tex-mode` is both the parent of several derived modes and the entry point that dispatches to the appropriate derived mode. > Using inheritance for that just seems a bit off, like a hack. `derived-mode-add-parents` is not inheritance: there's no reuse of code involved (tho it doesn't preclude it, of course). > Really what we wanted is a new variable called 'mode-family' > and test against that. I don't think that's necessary. This is a common programming design decision: should we have different "types" for the various stages of a pipeline, or is it preferable to keep the same type across various stages? When the stages of the pipeline often do nothing at all, it can be a good choice to keep the type unchanged. E.g. in Lisp, macroexpansion returns something of the same "type" as its input: it's OK to pass the output of `macroexpand(-all)` back to `macroexpand(-all)`. Scheme made a different design decision on this one (for hygiene reasons). Other example: keys as they go through `keyboard-coding-system`, `input-decode-map`, `function-key-map`, `key-translation-map`. Here we decided to keep the type the same. > In Yasnippet, if I remember correctly (it was a long time ago), the > snippet directory could either be renamed foo-base-mode or something > in a .yas-parents inside that directory can be added containing > "foo-base-mode". AFAIK adding a `.yas-parent` containing "FOO-base-mode" just means "oh, and also include the snippets defined for FOO-base-mode", which is redundant with the fact that `FOO-ts-mode` already derived from `FOO-base-mode`. So that won't do it. We'd need (like I recently mentioned in https://github.com/joaotavora/yasnippet/issues/1169) something like a new `.yas-children` (or `.yas-siblings`) which tells YASnippet to use the current directory also for those additional modes. >> That's why in my patch I add `python-mode` as an extra parent of >> `python-ts-mode` even though they both share `python-base-mode` as >> their parent. > > Right, that's what sounds hacky to me. They're siblings, but now > one also is the parent of the other. Maybe it works, but is > definitely odd. `python-mode` from `python.el`, `python-mode` from `python-mode.el`, and `python-ts-mode`, are three implementation of the `python-mode` functionality, yes. The fact that we use the same namespace for actual major modes and for conceptual functionalities saves us from having to do: (derived-mode-add-parents 'python-mode '(python-mode)) :-) The same happens with Debian package names and Debian package features: package `emacs` implicitly provides the feature `emacs`. > That said, if it works, I'm not really opposed to it. What > other packages do you know like Eglot and Yasnippet which use > major-mode in this way. I'm not sure which modes might be affected (beside Eglot, YASnippet, and CEDET). I presume many others outside of Emacs are, since `derived-mode-p` is used very often out there. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 05 23:16:23 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 04:16:23 +0000 Received: from localhost ([127.0.0.1]:58272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLy6h-0000dj-Bx for submit@debbugs.gnu.org; Fri, 05 Jan 2024 23:16:23 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLy6c-0000T5-Cu for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 23:16:22 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4C7DB80A64; Fri, 5 Jan 2024 23:16:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704514567; bh=ruk+KTp+7B1LPF1Z8IWXXxcqEoFC5mV1NAjF21S5fCE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OtdphALkVjsS56V6ciWffd/VtzwToIi3epHIaNghDcX9kNhsP6OTW3+YWX7oPQYq6 4QYA1XH3Z/xoRzUa7LADA1R04BszJKhrj57mHzUW9BrJ04KPawBxQuUVmQvtXCt1Zg 85CT2smrkdKuguL9JeX62u2ytTW+VT7xNJakZbiqCj0yIauVhIw52msww7F0xe2lpi 6jU3x3DSkG56KP5kzl5eiKKvwAXt4S2AhYAgSR5FMKtm2+AJGLKrbD7MMRFCovBQfA fvHhGe+RyN1VVIvNh5dTGOvyJ4ppqxbRV+M4gqlQ8K0JZDZszUDFy3n9axQZ1WoLAz cxgNeN8nlwGsQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3EABF8019F; Fri, 5 Jan 2024 23:16:07 -0500 (EST) Received: from milanesa (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 08A9A120AC8; Fri, 5 Jan 2024 23:16:07 -0500 (EST) From: Stefan Monnier To: Yuan Fu Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> (Yuan Fu's message of "Fri, 5 Jan 2024 19:19:46 -0800") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> Date: Fri, 05 Jan 2024 23:16:06 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , =?windows-1252?B?Sm/jbyBU4XZvcmE=?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Then there is the problem Eli pointed out, base-mode hooks runs before child > major mode body does. [ Side note: This is not relevant to the present suggested patch. ] No, all the mode hooks are run at the end of the major mode body, i.e. you get the following order: fundamental-mode body prog-mode body FOO-base-mode body FOO-ts-mode body fundamental-mode-hook prog-mode-hook FOO-base-mode-hook FOO-ts-mode-hook > (Arguable a niche use-case, but my point is base-mode hooks have > their limits.) It was sufficiently "not niche" that I fixed that problem in Emacs-22 (according to `C-h v delay-mode-hooks`) :-) Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 03:07:51 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 08:07:51 +0000 Received: from localhost ([127.0.0.1]:58496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ig-0003qM-MA for submit@debbugs.gnu.org; Sat, 06 Jan 2024 03:07:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ie-0003q8-AM for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 03:07:49 -0500 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 1rM1iT-0005TU-VE; Sat, 06 Jan 2024 03:07:37 -0500 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=ETOj8mZ5qPE6Tb1v4sz8TdlYfH1ubDYKrklzprESquw=; b=IlaCKgDWJ+QH1u8G8Rg2 MAMcSV6qEaqlE061FlEWhj7LFR5hGndJ5U5W3GM7IzZb3cy3k3cc9mkike9y7fcBAnaL8BIlUov8M kB/MQcdoITbkEeoPCbjRA7k2KGLw3ztbvV8KVu3vhuMQbF+qHjMl2blyO8KPYRrTu7FxwmWz6iEEX G5B58BwmRunp/NtS1ijzTZMB3CBfcTCAxKAGD1usXXa1tQZs6Z4+kM6bFGc2sK16DyIxXla6Czq4+ UYIuw/9NmGpbeQyIOnN+6Owd6Bty/0UfT8dnZ0wM2AM/7NOmit3v0f0K5JAcpJZBqI8GzY0BVDOma 0Sn7mhkF1uPUKQ==; Date: Sat, 06 Jan 2024 10:07:09 +0200 Message-Id: <83v886ubpu.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 5 Jan 2024 23:20:26 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes 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: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 5 Jan 2024 23:20:26 +0000 > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > On Fri, Jan 5, 2024 at 6:57 PM Eli Zaretskii wrote: > > > > Of course they do!! How else would electric-pair-mode have worked > > > for virtually every language for more than 10 years > > > > forward-sexp moves forward even when there are no parentheses or > > braces anywhere in sight. > > electric-pair-mode uses scan-sexps. Scan-sexps works perfectly to > navigate nested mixed delimiter structures of modes that are not Lisp, > otherwise e-p-m couldn't do it's auto-balancing job. You are thinking about forward-sexp and scan-sexps in the situations where you start from a parenthesis. But scan-sexps, like forward-sexp, handles situations where the "sexp" is not a balanced parenthesized expression. It uses syntax tables that in the case where you start not from a paren yield ad-hoc results whose relation to "sexps" is arbitrary. Therefore, doing something similar with results of parsing the source code will always produce arbitrary results that are different, and make as little sense as what forward-sexp does. There was a discussion not long ago how to define a "sexp" in TS-based modes so that it would make sense. You can see there that the conclusions are not self-evident. But we digress. My point in talking about sexps was that basing it on syntax tables (like we do in traditional modes) will produce different results than if we base them on TS parsers. If you still disagree, let's agree to disagree, because I already explained this twice at least. > > > Well the reason why e-p-m and these things work today for most ts > > > modes is because they are also _using_ the Lisp/C parser based on > > > syntax tables and syntax-propertize-function. > > > > That's because a language parser will not have any notion of a sexp, > > so it cannot help. > > As I am trying to explain, it doesn't have to be a "Lisp sexp". > It just has to be something that scan-sexps can navigate, and > scan-sexps works in all modes. scan-sexps is not using the results of parsing by TS, so it doesn't really understand the structure of the source code, and in particular cannot provide reasonable movements by portions of expressions in at least some languages. Again, if you disagree, let's agree to disagree. > I'd think that at least with a good enough grammar it's perfectly > possible to do e.g. show-paren-mode with TreeSitter alone. Why do you think so? Does a TS parser produce any information about matching parens/braces, let alone characters like <> etc? > And the way this could work in Emacs is for TreeSitter to feed into > scan-sexps. I'm not sure I understand how TS could feed scan-sexps. Did you look at the implementation of scan-sexps? AFAICT, there's no way to base the code there on TS, except by providing a completely different implementation (assuming TS parsers even provide the required information). > > > > I invite you to compare CC mode with c-ts-mode, and see for yourself > > > > how the common grounds are very small. It seems surprising at first > > > > sight, but once you look at the code, it is very clear. > > > > > > And this is mainly because CC mode is, well, rather corpulent software, > > > let's put it like that. This is why I wrote it makes sense to start > > > from scratch for this one. > > > > A discussion where you brush aside any argument that doesn't fit your > > theory is not a useful one. > > ? You write this precisely in the point where I _agree_ with you. You "agree" for the wrong reasons. You are, in fact, claiming that the CC mode cannot be an example of a problem because of unrelated reasons. I'm saying that the reasons are related. > > This means that the > > base-mode hook will not see a mode that is ready for work, only its > > beginning. > > Correct. But a major-mode doesn't have to be "ready for work" (I presume > you mean ready for editing) for the hook to be useful. That hook would > be perfectly suitable for setting variables used by minor modes and other > things. (eglot-server-program, flymake-diagnostic-functions, company-backends, > mode-line-format, etc etc) > For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-mode,) > For binding commands. Stefan's patch solves these cases in a simpler manner. > And even without the hook the mere fact that foo-mode and foo-ts-mode > are derived from foo-base-mode according to derived-mode-p makes it > useful. Stefan's patch solves this in a simpler manner. > > > > and this various > > > > things that you'd want to do in a mode hook are impossible in the > > > > base-mode hook. > > > > > > I don't follow this part either. Can you give an example using, say > > > the existing ruby-base-mode. > > > > Again, look at the two examples I mentioned above. > > I couldn't see the problem in either python.el or sh-script.el. Search for bugs in those two files, and you will see the issues that I had in mind. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 03:10:08 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 08:10:08 +0000 Received: from localhost ([127.0.0.1]:58501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ku-0003u4-G5 for submit@debbugs.gnu.org; Sat, 06 Jan 2024 03:10:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ks-0003tY-Ub for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 03:10:07 -0500 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 1rM1ki-0005wv-Pc; Sat, 06 Jan 2024 03:09:56 -0500 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=r5b2DmjPUH0h/FCsF1ypHuL1Nc3Kik6QSzu2jpPjSk0=; b=MZTtUqS4BEXLcWtLlamh UZKArq9ENon5Yfq3YJvKi6Kk/0XmDcJdoLO+iTFYpi6t4hPv+Z7mm5V3zn0u+69le4yFnQZvmSlp4 V5VSnwN6EgnGhWzUw6XfEAZ1a1rpLORUXk0glrqm2rBCEKJqUvuuD6w034YKT9gSF8kof1VYBv7bU R685nD2CsFHJecZICltoaNNrojqa+3k7sLGe+TUl6+opC0EU50kFrF+5yJB1ykZcufIVlpHGHVN0U XpOKrq8sIXUGpRnvqdb97U0Jozy/zZ0H2t29f7UXJZcufLG2By8cIIYlqOwrvXpqwsVuBFEHVMpUn vopMMEZVhI2/gg==; Date: Sat, 06 Jan 2024 10:09:32 +0200 Message-Id: <83ttnqublv.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 5 Jan 2024 23:37:46 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 5 Jan 2024 23:37:46 +0000 > Cc: Eli Zaretskii , Yuan Fu , 68246@debbugs.gnu.org, > monnier@iro.umontreal.ca > > > But even if we added all the base modes today (as empty stubs), AFAIU it > > wouldn't solve the exact problem that Monnier's patch is addressing, > > namely to make packages and customizations work in both foo-mode and > > foo-ts-mode even if they only say: > > > > (derived-mode-p 'foo-mode) > > That's why these packages should be changed to say > > (derived-mode-p 'foo-base-mode) > > Or maybe > > (cl-some #'derived-mode-p '(foo-mode foo-base-mode)) Stefan's patch solves this in a simpler way, which is also friendlier to 3rd-party packages out there. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 03:13:21 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 08:13:21 +0000 Received: from localhost ([127.0.0.1]:58506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1o1-0003yc-5e for submit@debbugs.gnu.org; Sat, 06 Jan 2024 03:13:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1nz-0003yQ-BG for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 03:13:20 -0500 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 1rM1np-0001EU-3G; Sat, 06 Jan 2024 03:13:09 -0500 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=ce37xrnf1Uaah8B9no7HmGT6srfw1a8pD8mJdcNn2uA=; b=ZsNOntZ2hrDvnm3mWeqh Rv1Ei0tGHgisi4BuTujK1V07FOrwTm9bk7v+G/N34+IfOfmT/eUh22hZ7VBLSgEZTTE5HPUg7GUIy TJf7hWok36ogRPAn/CqqiSMs4IUubTaUVedPMR7UHltVsgilU+YlQVNLJGfzlcYSUsrtGf+SdmU9r Yve4oO5CkGHJmYDkTVhtvkcuffnDW80O2yahGxAEF3XY0DcN2pY8Y4ah0h9GYPXw7zmq0DSqhbSbg tWaNwWF+0rNwkEWfAtMoHX9gXZ4Q1e4GfaDdZJhJ2fl6YoLs4iZetx4TETnwP0Jb9joSUeB+jVCGb n9GnpOIj62t2lQ==; Date: Sat, 06 Jan 2024 10:12:54 +0200 Message-Id: <83sf3aubg9.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 6 Jan 2024 00:16:02 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes 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: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Sat, 6 Jan 2024 00:16:02 +0000 > Cc: Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org > > On Fri, Jan 5, 2024 at 11:51 PM Stefan Monnier wrote: > > That's why in my patch I add `python-mode` as an extra parent of > > `python-ts-mode` even though they both share `python-base-mode` as > > their parent. > > Right, that's what sounds hacky to me. They're siblings, but now > one also is the parent of the other. Not "parents", "extra parents". The documentation explains the purpose of this. > And I don't see how "foo-base-mode" is much worse, modulo slightly > more akward naming and backward compatibility problems that you would > have anyway. It requires more changes everywhere, for starters. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 08:53:15 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 13:53:15 +0000 Received: from localhost ([127.0.0.1]:58831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM76w-0005jX-O5 for submit@debbugs.gnu.org; Sat, 06 Jan 2024 08:53:15 -0500 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:42294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM76v-0005jL-C1 for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 08:53:14 -0500 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50e7b51b0ceso433337e87.1 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 05:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704549182; x=1705153982; 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=dXTFHcfePDkuGdRDjLp1fcFz24qjeDFKKs9Lw4YNI5U=; b=X2IT9xcy7hTWd4klZ/UOGJWAqqg+daiXY/ryYFYE6JAEayYQY5CcoXfYuQMDmQXuf/ sAzbNjvQdJpSZnhRT/yUPut4kDgOdAn69543KhhdyrXH51ddEqjnXrP/lPdXfbVPm7au e5xHa1t0x/dtcelGHpSwH10qKExuleHE6gCRzwPcoXf7ZI/E8xZSUVUAASoGVzF9Lwuf PzYpGdlb5RrVMkvClWzx8VEt7dhr1ovWQ58Nr2Hc68Bxd8BbKoZ1R6KL66qsnsgaLVsR K9nCc9Q5FN1rc/FFXIUnSogACKilWoapD/QuXa87FLLeRDRoweKmzIjAhuNlTRWop0F6 92Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704549182; x=1705153982; 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=dXTFHcfePDkuGdRDjLp1fcFz24qjeDFKKs9Lw4YNI5U=; b=C4z8Tk7XWyt4/RW/rOFjhaByfUddD/SydWb3BPLNL48YUu84ZQ30XqjN98LPRT8uRy 3Y774cNylDf+SX1Z+u7K6XcdFHXIRXknCiFN02CFk18wm/7WRcptHrTy/Q3XgxtkgyhH Wp5/FTuU61nVU8namladXuAIDt2C/jlte+3eRPs0S5Bf9LZiUj9FGrJJS4Fj7CZGbxfm d+vp/fff3n5mHX91j8l8qHhJKntuEioZvauiAtAI8Q7zs/T5w10a4Tf0nTxctnpe4h4L 3qewTBfNKLvjXm4YEOtaaRJwYaTFV2sMqO/4xU4rmdKIGyAvfqsacst9KpBtXNAbt9yU N3sQ== X-Gm-Message-State: AOJu0Yx8QHICWLGEpp3nrktID+J5raKJGFiCCdzWR2mp7+AXduBo2Nov xU1i7ND0stBlpLQwk4iGIlIjNerZTrHBwrlyrWs= X-Google-Smtp-Source: AGHT+IFZeIDNE/1khVrgWMG59vgcYv8pDwUtHQY8DwzgfSO4/LuOk/R4Knvy5V16e8SeCzJVQtXNo+CFyFM43TqbePQ= X-Received: by 2002:a05:6512:ace:b0:50e:74e1:2e35 with SMTP id n14-20020a0565120ace00b0050e74e12e35mr2264975lfu.5.1704549181881; Sat, 06 Jan 2024 05:53:01 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83v886ubpu.fsf@gnu.org> In-Reply-To: <83v886ubpu.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 6 Jan 2024 13:52:48 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jan 6, 2024 at 8:07=E2=80=AFAM Eli Zaretskii wrote: > let's agree to disagree, because I already explained this twice at > least. I was just commenting on your earlier words "That's because a language parser will not have any notion of a sexp, so it cannot help." That's manifestly wrong. Even with a limited understanding of what a sexp is, it can definitely contribute to sexp navigation as used by scan-sexp clients. > Again, if you disagree, let's agree to disagree. Yes, let's. But what you said doesn't contradict my assertion that TS the can feed into scan-sexps in ways that are useful. > > And the way this could work in Emacs is for TreeSitter to feed into > > scan-sexps. > > I'm not sure I understand how TS could feed scan-sexps. Did you look > at the implementation of scan-sexps? AFAICT, there's no way to base > the code there on TS, except by providing a completely different > implementation (assuming TS parsers even provide the required > information). One reasonably effective way to do it is just have syntax-propertize-function propertize text based on TS nodes, which is what c-ts-mode does today to make show-paren-mode do the right thing to angle brackets. Pretty useful already. You're still running through text properties and that's maybe not very pretty, but an implementation detail all the same. There could be be some more efficient connection between sexps and TS (or whatever parser) later on. > > > > > I invite you to compare CC mode with c-ts-mode, and see for yours= elf > > > > > how the common grounds are very small. It seems surprising at fi= rst > > > > > sight, but once you look at the code, it is very clear. > > > > > > > > And this is mainly because CC mode is, well, rather corpulent softw= are, > > > > let's put it like that. This is why I wrote it makes sense to star= t > > > > from scratch for this one. > > > > > > A discussion where you brush aside any argument that doesn't fit your > > > theory is not a useful one. > > > > ? You write this precisely in the point where I _agree_ with you. > > You "agree" for the wrong reasons. You are, in fact, claiming that > the CC mode cannot be an example of a problem because of unrelated > reasons. I'm saying that the reasons are related. Actually it _could_ be an example. A c-uber-base-mode would have _some_ benefit, like it would be a good place to stash snippets. Just not as much benefit as others which have code. > > > This means that the > > > base-mode hook will not see a mode that is ready for work, only its > > > beginning. > > > > Correct. But a major-mode doesn't have to be "ready for work" (I presu= me > > you mean ready for editing) for the hook to be useful. That hook would > > be perfectly suitable for setting variables used by minor modes and oth= er > > things. (eglot-server-program, flymake-diagnostic-functions, company-b= ackends, > > mode-line-format, etc etc) > > For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor= -mode,) > > For binding commands. > > Stefan's patch solves these cases in a simpler manner. I don't oppose Stefan's patch strongly, but I don't think it's simpler. For one, it's innovative, a new way to do things that we could already do with a simpler-to-reason inheritance that we've had much longer. As far as motivation goes, the problems in Eglot and Yasnippet are easily solvable without it. Not sure about CEDET. As Stefan K points out this needs calling out in *Help*. > > I couldn't see the problem in either python.el or sh-script.el. > > Search for bugs in those two files, and you will see the issues that I > had in mind. Yes, will most definitely start my "search for bugs" in two files totalling 10000 lines and you know in 200 years or so. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 09:36:43 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 14:36:43 +0000 Received: from localhost ([127.0.0.1]:58862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM7n1-00067O-1x for submit@debbugs.gnu.org; Sat, 06 Jan 2024 09:36:43 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:50533) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM7my-000678-EH for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 09:36:41 -0500 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cd1a1c5addso4376181fa.1 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 06:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704551789; x=1705156589; 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=hcGVkx5h8zvCyBhgNl6cvI+6PraIgqF1jLlunoqOgrQ=; b=ezA5CxKat42Q6VQ/t0WBuj+RYWxJ03y4soMfvPKZ/ST6rSyeVzZIuGKQ1fj6GY+WWW ZeGywJ4bVHtOgvP0nPISVhvo1XWgBSOitTgsU0rRZh5SlrwW8kn6zu54oCkgTGFdfmsZ TXxG/honOCKYYkm5eDj+ukrgQvsbAcWsFF2figja6Y+LmutTJyEpjLcZnd7BEC9fJhb1 ZBkJmsVmgKfN25Wb/a/EIfIdkg3PbRleWu2W+6r+lEF25nAqERbiREL7ktaW+0HCsSG2 2NbPE3u8kOdWLSF+uWdM6AsEnslVwm5JyB2ug349YLtqLfrO1gpRiT6O3RsaFFrrL3TE brMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704551789; x=1705156589; 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=hcGVkx5h8zvCyBhgNl6cvI+6PraIgqF1jLlunoqOgrQ=; b=dpoz5PfJT0dF9Unx7/gMqb5e6U38tvDGZK5WKkyIdkeJMbW4eXC4L7pPGXg7gG1Ght Izriqo2dpETi6FDQ2yBoq3BA5NjKQTmXII6uSeNl5R2tR8lGPUYpcHlee9yr+BSepX1j fn6hzzOoOaSyLUrF1UY8wreI6bbQaBsXm7PzS8U/jVT79Qg8+KMnydKlbD8yyHY/5tYL qlv6i/sMOBjDAaBNZIwf1pf3aS/G4bHqtT90k+co4BSbSmftHdRkUHv3vhe5nSVxODtu j8X45k5ZHrrMTNvkDh0GzYzrlq7zV1YnvJYcoapuYyIzAE/byQL2Y9m4x7kyRdcGvnBF ThzQ== X-Gm-Message-State: AOJu0YwwhE2uHtNeOe0xO5LnyX2lTZlRseS2gA0W4xDtH7k6u/CM5aa6 2nnmWzLoYvgt1lVz3g/9GVhHjW+li5FsxDRgonY= X-Google-Smtp-Source: AGHT+IEogdxR304DrQGk9Z6lnMtv8xh5PTDcZpFtXmcSWVlN5QSxoCn9NIsiNt0XFzDYqk8P85a6FSHtMNRYHagsWHA= X-Received: by 2002:a05:651c:1072:b0:2cd:2463:8972 with SMTP id y18-20020a05651c107200b002cd24638972mr344925ljm.48.1704551789259; Sat, 06 Jan 2024 06:36:29 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 6 Jan 2024 14:36:17 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jan 6, 2024 at 4:08=E2=80=AFAM Stefan Monnier wrote: > Other example: keys as they go through `keyboard-coding-system`, > `input-decode-map`, `function-key-map`, `key-translation-map`. Here we > decided to keep the type the same. As much as I want to believe these arguments for the conceptual solidity of this "extra-parents" idea, I still think this is burdensome. As a data point, I've had a fair number of Eglot users confused about single simple inheritance as it stands. > The same happens with Debian package names and Debian package features: > package `emacs` implicitly provides the feature `emacs`. [I don't find this model simple either, not as a casual Debian user. But at least there they have clear separate concepts of "package" and "feature", which seems to hint at my "mode family" or "file type" idea] > I'm not sure which modes might be affected (beside Eglot, YASnippet, > and CEDET). I presume many others outside of Emacs are, since > `derived-mode-p` is used very often out there. Personally, I think if Eglot, YASnippet and CEDET are all we actually know about, I think it's very simple to fix 2 out of three (even _without_ the "base mode"). And the 3 out of 3 I _think_ I can fix once someone points me to what exactly it should do. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 09:55:14 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 14:55:14 +0000 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 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 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) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> In-Reply-To: <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 6 Jan 2024 14:54:49 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Yuan Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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". From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 10:51:07 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 15:51:07 +0000 Received: from localhost ([127.0.0.1]:60166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM8x1-0004Yg-GK for submit@debbugs.gnu.org; Sat, 06 Jan 2024 10:51:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM8x0-0004Y9-4J for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 10:51:06 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A5A85441726; Sat, 6 Jan 2024 10:50:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704556254; bh=JSr+aTGTFtTPetHApBRAnnp22FySJRJ3NcPclnmTjNg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oxqlbqUjR0bvvjI00PY+XoscpzF2ey06evD/BOcyPK1UVeI6NUBnW64WG1TmEOlmR 3HhFQiCrYRk+BWEDSgVENaqcnyQ99ImgcbnlzgZ46Mr8wMju96q24ktESYLpvpjve4 QeydykjY61IBPHgorKkYNI5qdbUMOcBrmBbcsLEQjvoAboffoPn/c1+2sM/iNYZ6nr mn36WNo4nSKIXnhWR8gLGPRU2vzoB3+XH2pHT7rHWfRBKKhcdVR/jrdyAhNcjAS0zx M2gBx47F0KD6p6pQEo+5zLJNE4DBI8vz86IqKl8VPZrOYoYdyzYIH0BBCew0tfphDZ 9VP8Sr8uanofg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6849E4416FC; Sat, 6 Jan 2024 10:50:54 -0500 (EST) Received: from milanesa (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 34D371203F3; Sat, 6 Jan 2024 10:50:54 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Sat, 6 Jan 2024 14:36:17 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Sat, 06 Jan 2024 10:50:53 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.140 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Personally, I think if Eglot, YASnippet and CEDET are all we > actually know about, I think it's very simple to fix 2 out of three (even > _without_ the "base mode"). And the 3 out of 3 I _think_ I can > fix once someone points me to what exactly it should do. I don't think embedding (repeatedly) in YASnippet, CEDET, Eglot, ffap, lsp-mode, (and all the others that I don't happen to know offhand) the knowledge that `FOO-ts-mode` is used for the same files as `FOO-mode` qualifies as "fixing". Instead, I'd call it "working around the lack of info which should be provided by the mode". The way my patch does it may not be The Right Way (tho the jury is still out on this), but at least it provides the info at the right place. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 06 17:23:15 2024 Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 22:23:15 +0000 Received: from localhost ([127.0.0.1]:60376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMF4V-00063O-7y for submit@debbugs.gnu.org; Sat, 06 Jan 2024 17:23:15 -0500 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:47536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMF4T-00062v-G3 for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 17:23:14 -0500 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cd1eac006eso6022241fa.3 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 14:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704579782; x=1705184582; 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=cEVB2m+0/K5ByPhVLII9X2jCjVYdrnqOv8OCt95VFao=; b=BZzyeY/KzP+MwIz8Z4u7mgu/4nZ1MR/IaGh6skYDXmWep4GdSH6SPljRo6XmmCZbZt cwks+2x9mcvvz5oaFQsMbtXKa46LQR5j00CBXWZ90g+A29rQGHaltv/SNwS5JrLVN/R6 mhPckUkQiLYfYv1Zb5oJptFDDylTPgzSg7cJTmA6GPzP5DbOjuZ+p/PybVipp+7Sdohf 4S9f5dT/5JK3X7oeg58GYRTM9odPUc9wje89oQcTNnVG9LQZOQXHhvCoTVrWv7/r3/No L/6007wETtHb8JVFDKRbEyP8cKqFW2esRkoVkuC+k2In2jLgREUo6kDQobnOhM1QReJG Ocow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704579782; x=1705184582; 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=cEVB2m+0/K5ByPhVLII9X2jCjVYdrnqOv8OCt95VFao=; b=pWxJdqDkON36Gi5yLX12DIggmKVppUhveYma1jEPBQDxb1YHw4o2agDFK7R8pxcD9u jqMj6eSnPzM4JKvsgcJ6jlpIjH0FJGtrLa2Pyn6oQzwwGiqRhI+HC6W7MMfGI6ObRlYI q/vgg+q0B2n8c5lE96wYEWxGJxteihwwPPmvJl3DJcP/usQ/ow2RdFnjumHkxcm5AQLs XtPYAuYlMLNopDjcVNFprNijLPVBNAVtifglZiMlJZ+j9r5/8M4xjL1+/pU42Zv+eZ1v QjN1dOZAUU7JpOsbjpgdR/gsrD7mdK1AIoRAf+xA/n+g1CJl0QD6ykejXSv8MftKk4qY zAHA== X-Gm-Message-State: AOJu0YzWRNqEhXETZJio4os9ptaweI9YPmB4ZzxyolHkeF9p8DAFa9zy UiNvdAKZJMjlx7KLM2SoRO1k6XhFRH/rZaSw5js= X-Google-Smtp-Source: AGHT+IEw+lAsiN3tPNdm1bSOZHVjTnE+T7pQezgNTOb3hF5oXb+2s6Be+gKQ6YQBtlGGTq9LAKDkY8JxukK8rOqf+jg= X-Received: by 2002:a2e:8555:0:b0:2cd:22e8:a71b with SMTP id u21-20020a2e8555000000b002cd22e8a71bmr393657ljj.85.1704579781612; Sat, 06 Jan 2024 14:23:01 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 6 Jan 2024 22:22:49 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jan 6, 2024 at 3:50=E2=80=AFPM Stefan Monnier wrote: > > > Personally, I think if Eglot, YASnippet and CEDET are all we > > actually know about, I think it's very simple to fix 2 out of three (ev= en > > _without_ the "base mode"). And the 3 out of 3 I _think_ I can > > fix once someone points me to what exactly it should do. > > I don't think embedding (repeatedly) in YASnippet, CEDET, Eglot, ffap, > lsp-mode, (and all the others that I don't happen to know offhand) the > knowledge that `FOO-ts-mode` is used for the same files as `FOO-mode` > qualifies as "fixing". Not ideal, yes. Depends on what needs to be done for each package. It would be good if we knew that. I'll only speak for Eglot, YASnippet and possibly for lsp-mode. These 3 packages need to know the language of the buffer they are operating on. That's ultimately and definitely what they want. They do that with major-modes, because that has very often been a good correspondence, often a 1-to-1, but not always. The N-to-1 problem is not new with ts modes, it has long existed (Yasnippet is turning 15!). > Instead, I'd call it "working around the lack of info which should be > provided by the mode". The way my patch does it may not be The Right > Way (tho the jury is still out on this), but at least it provides the > info at the right place. Yes. If by "at the right place" you mean "nearby the major modes definitions themselves", yes I agree. If you want to solve this problem cleanly, or more cleanly than it is also solved now, I'm all for it. I just think "extra parents" is a clumsy a abstraction, though it can be used as an implementation aid. For simplifying the existing ways these 3 packages already solve the problem, I propose that instead of calling 'derived-mode-add-pare= nts' directly near the mode definitions, we instead do something like: (set-language-for-mode 'foo-ts-mode 'foo) As a first implementation, this might just as well expand to (derived-mode-add-parents 'foo-ts-mode 'foo-mode) I.e. it will be 100% your solution. `derived-mode-p` will be affected as you want and hopefully everything will keep working as usual (not necessarily "start working" except for packages not aware of TS modes at all). But of course that's not all, because with very little work it also provides for: (get-language-for-mode 'foo-ts-mode) ; =3D> 'foo And _that's_ when Eglot, Yasnippet, very likely lsp-mode and possibly many others will see actual simplifications. If we like this idea, I also think supporting a :language keyword to 'define-derived-mode' is natural. Obviously, it would just expand to that 'set-language-for mode' and default to whatever comes before the "-mode" in the symbol. So in summary this is what I think -- from the perspective of these 2/3 minor modes. Yes this introduces the concept of "language", but I think -- in fact I'm sure given the interactions I've had with new Eglot users -- that "language" is a much simpler concept to grasp than "extra parents". Finally, how to give this to packages outside the tree? The usual route: do it in core and package it either in compat.el or in a :core GNU Elpa package, like we did for external-completion.el. Keep the derived-mode-add-parents (and add a "remove" counterpart), but suggest them as last resort options/hammers. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 07 01:55:54 2024 Received: (at 68246) by debbugs.gnu.org; 7 Jan 2024 06:55:55 +0000 Received: from localhost ([127.0.0.1]:60582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMN4c-0007A1-JA for submit@debbugs.gnu.org; Sun, 07 Jan 2024 01:55:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMN4a-00079h-Cp for 68246@debbugs.gnu.org; Sun, 07 Jan 2024 01:55:52 -0500 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 1rMN4O-0007qF-Pi; Sun, 07 Jan 2024 01:55:40 -0500 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=RMfo8R+w+N4D0H/6DBrN7BF5LPCZnHKwcR6jUUphr/A=; b=gRWJe8gUby/qvkPkCYbD gSrAZDRJF0h2o8n3XeuB/aJE6edWEuYNxlahGrcnh7+pXBIvlIIh78TwN9EFz60b7u/xvYjNRFKZs Pkil3HE5to+s9vm0Rm2F+qeghTkZRE/v7cepPuwjUnm5tV598TUh3d+tCf1Pp6wHHYJzF2HCn7yop W/TPNtqaDVRUshUoMUdsDOZqCDZWRsQKZs40SIa5rAb+7B+Uwnxs21qjrjlQ90VTcrNZWHRH7rBFa brk5EaLmerCDBfAfYPsRpN/Tn7OjwQ1zEK1ERlgAhTcv28KWaA+5sobYsMTcls9N6Zfmp2i/cDZti loXk4kEVSCfCtQ==; Date: Sun, 07 Jan 2024 08:55:34 +0200 Message-Id: <83a5phskd5.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 6 Jan 2024 22:22:49 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes 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: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Sat, 6 Jan 2024 22:22:49 +0000 > Cc: Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org > > On Sat, Jan 6, 2024 at 3:50 PM Stefan Monnier wrote: > For simplifying the existing ways these 3 packages already > solve the problem, I propose that instead of calling 'derived-mode-add-parents' > directly near the mode definitions, we instead do something like: > > (set-language-for-mode 'foo-ts-mode 'foo) This assumes that the only important aspect of a major mode that transcends the "normal" ancestry is the language that the mode supports. But that is not necessarily true in all cases. Also, some major modes don't have a "language" attribute, in the usual sense of that word. IOW, this is IMO an even more leaky abstraction than what we get with derived-mode-add-parents. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 07 02:00:24 2024 Received: (at 68246) by debbugs.gnu.org; 7 Jan 2024 07:00:24 +0000 Received: from localhost ([127.0.0.1]:60587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMN8x-0008Gc-Ab for submit@debbugs.gnu.org; Sun, 07 Jan 2024 02:00:24 -0500 Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]:56518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMN8v-0007zz-Az for 68246@debbugs.gnu.org; Sun, 07 Jan 2024 02:00:22 -0500 Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-3606e11d9cbso6576445ab.0 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 23:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704610810; x=1705215610; darn=debbugs.gnu.org; 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=H5D5ZVbNKeYu+v11bDR8T2bHvzaHJOBZ3Tp6dkOh4xg=; b=T/NdedZZKuZTr5oCVywbINtLnEoT4gN5rC6Zb3HqffxpN64Ihd0fmeWKEzWH3s7fbq kjloD2opicjfq9ML1pgc4mFQI0oFnvquhMLb6evx8aWAxftma5U2Z80TAcW0d98fB5qn KmY0dbL0zSShRgyBAt6nekNB8hWFruB77ccpgMN+BMaL2MxCp2n7xJcn0EUVO/ezu76V 7vf/6xx7dwZZBJp4CuJMxUMZRbLgIPxEo9T+RlG9SqDPrtN0YatuCxZHwaHPUQQ5CSjh 6BXUTeUt+irVX5hDeFH/MNE+gQV5tcUmybm6fePkSneA1dyBZBFMexms8Vqa7HKttYxv aS4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704610810; x=1705215610; 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=H5D5ZVbNKeYu+v11bDR8T2bHvzaHJOBZ3Tp6dkOh4xg=; b=ZtcfACUU6vJj8x444VzXpe/KiXT4pcCF1Y1/i8A7TSinjUmufpUySccb1YJiEafcJZ H0TQMIwpb9FVqhIA9J01YHDHPLhv5cBhGVcjB4Rnf+S/kf/HPSn5X10HGy9RNZOEp0LK e44duPzZ2shTM7ILFnWyHh6UYNQCSmF/7cNjC7pymCvIAo5G+AYcL5dI35Opmghnv8Ci U06rATeaSNb3var2VY2Y83nEUa1KbJ5eBIXSVF0ZGqzFb2qaPXwHKMBNi79q86s66kEK wBnQnb99f4M4Dl/KLGqvwk6vPHRiioepVDMif5NGTa6GENm6FZ8fLYnRjEpI/de/0AZx zI6w== X-Gm-Message-State: AOJu0YyVhez+xjFjDSQpcrajdqVmz9nFOeB3/DfTX1ygApiVfUwhsJGI QZucsfkUe4j9e6LyhaxO6EE= X-Google-Smtp-Source: AGHT+IFxm7buApVd3vbF4k4vKQtKYSIGS8Id3AcJAE8WnAsZ0TegMIbJygWcsPLPowkBv9IG4n0yAA== X-Received: by 2002:a92:c54e:0:b0:35f:eaab:ab1 with SMTP id a14-20020a92c54e000000b0035feaab0ab1mr3834980ilj.15.1704610810185; Sat, 06 Jan 2024 23:00:10 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id j9-20020a17090276c900b001d362b6b0eesm3973004plt.168.2024.01.06.23.00.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2024 23:00:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: Date: Sat, 6 Jan 2024 22:59:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <82856630-162E-4A90-A74C-568B53A8F2EF@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 5, 2024, at 8:16 PM, Stefan Monnier = wrote: >=20 >> Then there is the problem Eli pointed out, base-mode hooks runs = before child >> major mode body does. >=20 > [ Side note: This is not relevant to the present suggested patch. ] >=20 > No, all the mode hooks are run at the end of the major mode body, > i.e. you get the following order: >=20 > fundamental-mode body > prog-mode body > FOO-base-mode body > FOO-ts-mode body > fundamental-mode-hook > prog-mode-hook > FOO-base-mode-hook > FOO-ts-mode-hook Ah, yes, of course! We talked about this before and I completely forgot. >=20 >> (Arguable a niche use-case, but my point is base-mode hooks have >> their limits.) >=20 > It was sufficiently "not niche" that I fixed that problem in Emacs-22 > (according to `C-h v delay-mode-hooks`) :-) And I thank you for that :-) Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 07 19:13:17 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 00:13:17 +0000 Received: from localhost ([127.0.0.1]:34085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMdGW-0004Ic-Pr for submit@debbugs.gnu.org; Sun, 07 Jan 2024 19:13:17 -0500 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:43312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMdGV-0004IO-4w for 68246@debbugs.gnu.org; Sun, 07 Jan 2024 19:13:15 -0500 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2cd04078ebeso20305151fa.1 for <68246@debbugs.gnu.org>; Sun, 07 Jan 2024 16:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704672783; x=1705277583; 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=D9acduHLhXD4qkhTWAlLkwL3jxXUWOcu8/nONW1MWRs=; b=aNzFgnbKGlOf5FJCdt63Cpj0KDmyD+wN8DsLh3bt0YJNiaFco5N8as6C1mFgj8foAq A8m48BInGcCeBSaaqUQt1Uf0hyVv6MwWOGV4pMpb4ZbzmKwti9UyGAXe7OhdG1iFU7K2 0Iy5/YCcwwVGn4RJtrw+pxWHPtQhl4NVscA7M/dyaL5hf8zwao+ujtstRBnzfmcib7/c A5cGe/4qALJQavuahm/ph9bcq65gB5Qo3TQNb/iTZWNqIKwt7R/Zt8CGS73AiS8BcWPe QrLsL/Fx8V5B3v8PIbaOtdB+AeFe59HYsguTBJrTmKV5mlqNbD+TvPMWf0aitNnA5S5V 25QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704672783; x=1705277583; 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=D9acduHLhXD4qkhTWAlLkwL3jxXUWOcu8/nONW1MWRs=; b=CPAOSlmCMKMHqEy6WJXy9OtFa37s8YDaVB+2zeezTkNu4/3L4Qm7bVUOK/LalMXVwX 8Ssd3lSmTbU9b+lhpJFjvIKFcYEZ9jf9MwmZxWBC46V3MKZjMvkBqwKX8ytVnMaqSKKW en3z8bYoR43XRszX7bScFE+53EYXAZ1IRMSyhVWbjN4B4lWEZId06dA+mr3p4EKM0kdN Lybi64sOFB0n7i6kgtDWj88tgzDs41tCr9Taq7oiUDiMJXvUnNTiNGlJ3R4aPNtH04H0 a+St1Bk6idKePZaJLb89XdAenLS0nrkaP0kH+eTzdzACuOZMX+4TjPn2qc+AxGO8mx6+ 2YJQ== X-Gm-Message-State: AOJu0YwzWA+dtjluLXIBxr935b0Kush/60o7eCeKlFobla7xt3eKt4BU C3GIGkk72V4QKmI3tjYPnSxLyKMTeOZbZ/2HWEU= X-Google-Smtp-Source: AGHT+IFV7dYIgVyLxOWhQqWjsA4JOLcXDbcThnFnCHpMGbck3XDzKq9y55nA3P2EeZDDypdsoIoLzFoYbJ4bCjJHZ3w= X-Received: by 2002:a2e:3c04:0:b0:2cc:f41d:9805 with SMTP id j4-20020a2e3c04000000b002ccf41d9805mr1412117lja.7.1704672782991; Sun, 07 Jan 2024 16:13:02 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> In-Reply-To: <83a5phskd5.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 8 Jan 2024 00:12:50 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Jan 7, 2024 at 6:55=E2=80=AFAM Eli Zaretskii wrote: > But that is not necessarily true in all cases. I specifically said I was speaking for 2 packages I created, Eglot and Yasnippet, and possibly for lsp-mode how is facing the same problem, which is answering the question: what, if any, is the language/file type for a given major mode? I can't speak to those other cases unless someone bring them forth. > Also, some major modes don't have a "language" attribute, in > the usual sense of that word. Then I guess "nil" would be a fine default for anything not inheriting from "prog-mode"? Or s/language/filetype if you prefer. Dmitry said a language database is missing. Stefan mentioned the problem of conflation of file ty= pes and major modes in Emacs. I agree with both, so I thought of a simple solution composed of a getter and a setter. > IOW, this is IMO an even more leaky abstraction than what we get with > derived-mode-add-parents. We don't seem to share the same concept of what a "leaky abstraction" is. In my world, it's an abstraction that exposes details of the thing it's supposed to abstract away. Unless we're trying to abstract away lisp symbols, I don't see how set/get-language-for-mode is leaky. But if Stefan's patch is supposed to also abstract away the language-mode correspondence, it's definitely exposing details of how it does it, which is via "extra parenting". Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 07 22:34:34 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 03:34:34 +0000 Received: from localhost ([127.0.0.1]:34804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMgPK-0004MN-9P for submit@debbugs.gnu.org; Sun, 07 Jan 2024 22:34:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMgPH-0004M9-OD for 68246@debbugs.gnu.org; Sun, 07 Jan 2024 22:34:33 -0500 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 1rMgP4-0006RS-6m; Sun, 07 Jan 2024 22:34:18 -0500 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=9KndzNQL0pwdkdsYzNOAzI5ulVumj0B9JTarNzmU3LY=; b=P+9Nfh+JMHT9lAOs+uLJ A+cGQ9Idyhbl3qyzFn+dRK17x6pk5U+l48C5YO0uCixSzblliaPuMjZni6a/udjjpswvD7HosoB4U J4VnqENI1hB7oqUf/HDLzqkyLtGVLNQUFuCfwUZB/iFbRjdQdU/zBe6+klhZEjfUydeqjBjemS9VB iWlh2M3y0t4d8o5pDuMhGm3frIiWlIIZjqGCgHhFJWsd2qpdtfFAMZUtcmJqShLblJdtNUvKdGgKd 6j6cx1ZQlRV46z0NH4kFJIRify0x89Iy9y4bM48BiDCoGWaZGkNhU+gM4Hu680pPz+GaIHv6TtsHn 6k+7dxThN+72AQ==; Date: Mon, 08 Jan 2024 05:34:10 +0200 Message-Id: <83h6joqz0t.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Mon, 8 Jan 2024 00:12:50 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Mon, 8 Jan 2024 00:12:50 +0000 > Cc: monnier@iro.umontreal.ca, casouri@gmail.com, 68246@debbugs.gnu.org > > On Sun, Jan 7, 2024 at 6:55 AM Eli Zaretskii wrote: > > > But that is not necessarily true in all cases. > > I specifically said I was speaking for 2 packages I created, > Eglot and Yasnippet, and possibly for lsp-mode how is facing the same > problem, which is answering the question: > > what, if any, is the language/file type for a given major mode? > > I can't speak to those other cases unless someone bring them forth. A generalization should be based on as many use cases as possible. > > Also, some major modes don't have a "language" attribute, in > > the usual sense of that word. > > Then I guess "nil" would be a fine default for anything not inheriting from > "prog-mode"? That's not useful, since, for example, TS and non-TS mods for those "no-language" modes will still want to be treated the same in some situations, like .dir-locals.el. > > IOW, this is IMO an even more leaky abstraction than what we get with > > derived-mode-add-parents. > > We don't seem to share the same concept of what a "leaky abstraction" is. > In my world, it's an abstraction that exposes details of the thing > it's supposed to abstract away. That's the sense in which I'm using it. > Unless we're trying to abstract away lisp symbols, I don't see how > set/get-language-for-mode is leaky. It attempts to abstract a trait that isn't abstract, by going in the opposite direction of that used for abstractions. > But if Stefan's patch is supposed to also abstract away the > language-mode correspondence It isn't, AFAIU. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 07 23:11:16 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 04:11:16 +0000 Received: from localhost ([127.0.0.1]:34815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMgyq-00029l-CI for submit@debbugs.gnu.org; Sun, 07 Jan 2024 23:11:16 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMgyo-00029W-EZ for 68246@debbugs.gnu.org; Sun, 07 Jan 2024 23:11:14 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DA3DA44254D; Sun, 7 Jan 2024 23:11:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704687061; bh=K78VUHqI/p1NUAvea8hySQ6krDGDn8a1NnJtWfCabvs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kgMtM1hdO5fl9WgTH+W20gBUckeRQXrMU9PeoFT1+xKfFLC+VLk9IiAYsX4XoflqP 1/bWoJz61DYCEqOMBBfskst0l7Kw/iI/VD3fuDLyZs2Bgyp8LiJe5oOhQB4kbIX8W4 eI3QfzMsHXUFx7ssomVQ7ZPSo1qscJJiE5cI7CYra0iz5O4lQ5QKcYQMbE7cIpBs9R 3R50/gwcFf3zQ/zUDUrNfGnew+1yPitYPY9nPTyZ5qSdDWQYglMKWaL5DA+LL5hhKV jY0M9XVHXxTg6K+xcdr2ksB5rkCxLcFI9vlRScOVrzwV8XqkjTswnLNMZmP/N2SeGH 3Mz3gGI5g2e3Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 88E83442531; Sun, 7 Jan 2024 23:11:01 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 558F0120429; Sun, 7 Jan 2024 23:11:01 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Sat, 6 Jan 2024 22:22:49 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Sun, 07 Jan 2024 23:11:00 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.106 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (set-language-for-mode 'foo-ts-mode 'foo) Maybe we want to introduce this concept, indeed. maybe we want to that notion of "language" from elsewhere, such as the one used in LSP? Or maybe we want to take it from MIME types? I'm sure there are other options out there. Problem is: they come with their own complexities and corner cases. After all, this is inevitable when you create a taxonomy. IOW, while we *may* want to add support for an explicit notion of "file type", it's a whole problem in itself and it will not solve all our problems either. In the mean time, I think `derived-mode-add-parents` is worth a try. As mentioned in some message up-thread, I'm not 100% confident that it won't introduce serious breakage. But I think we do need more experience and installing my patch is a good way to do that. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 05:51:25 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 10:51:25 +0000 Received: from localhost ([127.0.0.1]:35299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnE4-0007ND-TQ for submit@debbugs.gnu.org; Mon, 08 Jan 2024 05:51:25 -0500 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]:43065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnE1-0007Ma-Jr for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 05:51:22 -0500 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ccc6e509c8so23609271fa.0 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 02:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704711069; x=1705315869; 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=pv2FP9pHKWznrLnnt0hfwN9F+UhDvUWPFogBRky2Hcs=; b=G8WzrVm+3rYfRTIBBhNpGcEibQ2kbV08txAqAEsP920hVUFcHRJIYOmkbmIozXSgh2 PK10GAuYTU+qFHsUxopHhw0N4TaWGZslzvP/pMvWJbXekzGuV7AJnY4sl00xFgRGfNMO 1FJsmm6PGLCp/2U+BiaOEDYzIRlmBF2F6mFEIHd8NHrK6W+Puej2/Eh0cW3Hmk475thO 6YzQXhBCM20si3kZXODUi38w9kn1QIUnQrvi4NN6gtlrbMiV2gGvKHwksYiTPenSH3G4 4xmjyRx0rGoOVmYYt2Ky/+do4zviZrIjjGcaD5gKZkRDutQypl5JPpgDCuVlNw4ttCq/ CFbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704711069; x=1705315869; 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=pv2FP9pHKWznrLnnt0hfwN9F+UhDvUWPFogBRky2Hcs=; b=QEyFtwV3iJGl0Txh9YhTzqLwicHuZhk3rZ4UmBZR8zjwWTiZUYD+nWXooQ7mporcMy lFg17k8bH6zd0+xAT/paQvbt1BsXEH5hzg097DikgCb0ja9OMCqc9Olzs2GCpmPnb0Wv g9d3BqZneK2MU4lmuS/LZkC+XjNgQ04XF6kePBQ7ioPYIf1unN5DUG3nniq+GGbkYLby wKqkEgoPxYNG+wWu0y7A3BLfMPzVMs2z9ZrWImo35TRpGNOhvhl4KhzfjrlvpN6HPJW4 gzEP4DKxVZmkl0f4tDiqa1yiZjVBzxA19L4tfgqJ0anVO3nx2ZDyh5Dv9ooqVmeIT62l 4b/Q== X-Gm-Message-State: AOJu0YxInGEl4KeYn/ED7U4LtZlJ2bPlaEtEt+KZ+1bbaDs97264jqw1 iPbHLQj1h85HY8fylq4o1n988wTiZuoUp+ArBCY= X-Google-Smtp-Source: AGHT+IFE7Kx3w9u0LsUCFZRw+qbTkgMso4ht+1U9z2uEmvpT8w2nwGXixM9/ZgAZ4jBXsjj0z/VEiPwrPRueBwSpjME= X-Received: by 2002:a2e:870c:0:b0:2cd:1993:e5e2 with SMTP id m12-20020a2e870c000000b002cd1993e5e2mr3320432lji.16.1704711068863; Mon, 08 Jan 2024 02:51:08 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> In-Reply-To: <83h6joqz0t.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 8 Jan 2024 10:50:57 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 8, 2024 at 3:34=E2=80=AFAM Eli Zaretskii wrote: > That's not useful, since, for example, TS and non-TS mods for those > "no-language" modes will still want to be treated the same in some > situations, like .dir-locals.el. Yup, so pass them same :language to them and call `get-language-for-mode` somewhere in the .dir-locals.el machinery? Else suggest to use the base mo= de, if it exists. If it doesn't exist, create it? > It attempts to abstract a trait that isn't abstract, by going in the > opposite direction of that used for abstractions. It's interesting how you state a simple get/set is a "leaky abstraction", but then also not an abstraction at all. Let's put it like this: Eglot should probably fix this actual code: (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym)) to find the language to report to the server. Users should also be relieve= d to write or read :languageId in complicated fashion in eglot-server-program= s. Stefan's doesn't really address this. Fine. But it _will_ affect eglot-server-programs. In fact someone (TM) should come up with a docstrin= g change to e-s-p that at least hints at this concept of "extra parents", since it will start taking effect immediately for some modes, for some Emacs versions. What if an Eglot users wants some server just for the non-TS mode? Or a Yasnippet user some snippets for such a mode? Or even just regular user some directory-local variable value? The fact is that Eglot users, who are sometimes are surprised by mode inheritance as it is will see a more complicated concept come into force (in some Emacs versions, not all). This concept will apply to the python-mode/python-ts-mode pair but not the clojure-mode/clojure-ts-mode one. The following becomes harder to decipher: (add-to-list 'eglot-server-programs (foo-mode "Fooey" "stdio")) It may or may not go together with the typical: (add-hook 'foo-mode-hook 'my-foo-eglot-config) depending on whether the user has Stefan's patch, whether it patches "foo-ts-mode" and depending on the mode the user is running. The more I think about this, the more I think this is problematic. But if you guys are so confident, sure, let's try it. If nothing bad happens great, else I guess I'll refer users to this thread. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 06:11:57 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 11:11:57 +0000 Received: from localhost ([127.0.0.1]:35334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnXw-00023i-K3 for submit@debbugs.gnu.org; Mon, 08 Jan 2024 06:11:57 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:51306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnXv-00023R-NT for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 06:11:56 -0500 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2ccbbb5eb77so18211291fa.2 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 03:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704712303; x=1705317103; 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=/h4oGHKucrF8D/B6bkdqJUI9s0YwckqzGVRBScfq2a8=; b=cm82UAjtCqTleI+7pur2kI2JcaMuFbxMTj9HAYoBaDwAMpEfiBvAmuL1BOyZ+dNkAX gSRYgty+0POSBLbzcyCYhgnvyIKTYEE7JxK658UnDqEGGjCiwAUF+Bpz3tR+0iHFAl+X nVJ8UIJTsLEKl6cllHwHOUVVWznI1u4AGBdw59SSbXxGA/KEDOfKr2Cx6sSvD0E6/OFl yZb/uCnsU4gY12Dawo2VHbn5omhOujr2wo8LWM/DjfZhJrk2sZD8yNJE02evho7FDHC7 YApFGr7xR7ZH6kK31h+xxIN60sLRQjb/+xwGKNFSnv4Y3qd9a8FmPywx2RYOAgl4uLOR iigQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704712303; x=1705317103; 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=/h4oGHKucrF8D/B6bkdqJUI9s0YwckqzGVRBScfq2a8=; b=F5L2jO13CpNxf8oNf2Vmo7KQfZkDTcRsEq6zwYyazMPkKttZiDF/J2YTHmV6RO5nAX bugUBcTxJon1TYWMalTVhoQ9Pi4bxtSkeEjGlVaJ0qc32bd/mJ3wsp8zp3pNtoW6nW3h +AW56cieVSQoaKL2UWh44JPo6UshciriyzQ+Q+Qrq3OQ7qrNKewlp5XZoB0R8iyQzPu3 HyxceL+mKHHMaCNKJEX9dMLHJU8OY2aYhE2x6HBDjYKoQNCTFoARbNsJLODfFlVsH5k1 DxP/6KEcuAtcAV56Iqt+GGgp6ZOm+9YHlOd+X6TOWOjNwbAyTFb5T9zgpcvcrbc0T/p/ jK0A== X-Gm-Message-State: AOJu0YyMoEw9MsOonWf4w9rR1hngjzXnCNdGuw5sF2Me6UYAz995r+Yu blJaQIZwCkFedg9nFBZHtzJ+vox+piTW2dss97Q= X-Google-Smtp-Source: AGHT+IHYjEpkKjOekKrRx8uZORZOmrVE+Hv7L7ZMvnGz8hdBIXFFEOI01rSWul41gT6VqwKlrn91POeUg5+ZyhQ8ac0= X-Received: by 2002:a2e:be08:0:b0:2cd:56d9:762c with SMTP id z8-20020a2ebe08000000b002cd56d9762cmr552451ljq.66.1704712303432; Mon, 08 Jan 2024 03:11:43 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 8 Jan 2024 11:11:31 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 8, 2024 at 4:11=E2=80=AFAM Stefan Monnier wrote: > > > (set-language-for-mode 'foo-ts-mode 'foo) > > Maybe we want to introduce this concept, indeed. > > maybe we want to that notion of "language" from elsewhere, such as > the one used in LSP? > Or maybe we want to take it from MIME types? > I'm sure there are other options out there. I've seen the LSP list gain traction lately, granted in the M$ orbit. I don't think MIME would be a bad choice either, we should definitely use that if we s/language/file-type. > Problem is: they come with their own complexities and corner cases. > After all, this is inevitable when you create a taxonomy. Yes, sure. But they have they have the fundamental property of simpler graphs (trivial in the case the LSP list). No "extra parents" there :-) IOW they solve the fundamental conflation problem. > IOW, while we *may* want to add support for an explicit notion of "file > type", it's a whole problem in itself and it will not solve all > our problems either. I think it would solve the ones I found. Say if set/get-mode-file-type is added, it may just return a string designating a MIME type. We don't necessarily have to give it special interpretation anywhere but where we feel it's useful. > In the mean time, I think `derived-mode-add-parents` is worth a try. > As mentioned in some message up-thread, I'm not 100% confident that it > won't introduce serious breakage. But I think we do need more > experience and installing my patch is a good way to do that. I presume you've understood my misgivings, so go ahead. I'll leave it up to you guys to decide if docstring changes are needed in e-s-p or *Help* as someone suggested. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 07:46:02 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 12:46:03 +0000 Received: from localhost ([127.0.0.1]:35409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMp10-0005Xa-9w for submit@debbugs.gnu.org; Mon, 08 Jan 2024 07:46:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMp0v-0005Hy-9Y for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 07:46:01 -0500 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 1rMp0i-0001ER-U0; Mon, 08 Jan 2024 07:45:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Bzkddz+Mm0KlEqRKGk0cYX+mlounwnqJ2wHMqQZpgzo=; b=b+d2pD4PkaB7 lQPg0IqcSiYU7GT18RtlCH6PqYy7ESJhIfPrU0yL/Ft7rZ79CsQp01B+sHuuMNeLPwEdSQGJFm91a FL0TcoFhqAQBSKuEpiPCrASm+ecahCEnO/wLYGMtHY6HLfeF5eEPIA1CdjkVc3v5WiG+motT56eWR BNa+Ukwio7dxMOu33gLCE6XgxJ/DyMOm2CaipRBjciGdCEKL+51bF7MQVTtUr9a2GZ5qe6aSOU+S+ coURLgnZWEnBxnT71fg/ZOfU51ch7KtW+k0Vb+iIrNvEjxcjJlL0QksO5pmlQL77L3IKk2+6gYGeo iO6tF0y8n1t+b6I/Q30Muw==; Date: Mon, 08 Jan 2024 14:45:39 +0200 Message-Id: <83bk9wq9ho.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 07 Jan 2024 23:11:00 -0500) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org > Date: Sun, 07 Jan 2024 23:11:00 -0500 > > > (set-language-for-mode 'foo-ts-mode 'foo) > > Maybe we want to introduce this concept, indeed. > > maybe we want to that notion of "language" from elsewhere, such as > the one used in LSP? Please don't call it "language". That'd be confusing. LSP is about programming languages, so "language" is natural there. But in Emacs, a major mode is more general than that. For example, it is not unthinkable to consider mail-mode to be the extra-parent of message-mode (or vice versa) -- but what is the "language" in that case? > Or maybe we want to take it from MIME types? > I'm sure there are other options out there. > > Problem is: they come with their own complexities and corner cases. > After all, this is inevitable when you create a taxonomy. > IOW, while we *may* want to add support for an explicit notion of "file > type", it's a whole problem in itself and it will not solve all > our problems either. File types also have problems: Emacs modes are sometimes defined for buffers that don't visit files. > In the mean time, I think `derived-mode-add-parents` is worth a try. > As mentioned in some message up-thread, I'm not 100% confident that it > won't introduce serious breakage. But I think we do need more > experience and installing my patch is a good way to do that. Yes, I think we should try it and see what we learn. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 08:14:19 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 13:14:19 +0000 Received: from localhost ([127.0.0.1]:35484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMpSM-00019r-Ut for submit@debbugs.gnu.org; Mon, 08 Jan 2024 08:14:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMpSK-00019d-Mn for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 08:14:17 -0500 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 1rMpS3-0008BZ-AC; Mon, 08 Jan 2024 08:13:59 -0500 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=Q0Mwpnbl5UGjRGsmCOQDwI+e35+C8w9okYwMkFCMrxQ=; b=PpzDln24w3E3RYoYh2YI 2HSYqCGHCPHFokmpDQ/H5OZaLICgryk5LUsA2SeD87RT8mjozNnY3/OxDm/ns/+kYFC90EzeXQW5W jIwnZqzY+dp3Z/o/RahLCuORDn7GcceAQUpLA8TqB03ERikPvqKwWXsjv02o3HUvn/7L5C0+1esEP iYZrFPetuv02a598tPEdtceRB0B+umklvUaZ/6hv7p5raMa25MSB12uYM3R5P3XZUU++fCTvKFwT8 QaScOIplaqNO+/f7qvj6x14q1xsxCzxA39tzwSCyf9tXdfGXCn86oikHJURC03+KyXZwwp+yuqClD 2ANS6BUDDAO89g==; Date: Mon, 08 Jan 2024 15:13:53 +0200 Message-Id: <834jfoq86m.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Mon, 8 Jan 2024 10:50:57 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Mon, 8 Jan 2024 10:50:57 +0000 > Cc: monnier@iro.umontreal.ca, casouri@gmail.com, 68246@debbugs.gnu.org > > On Mon, Jan 8, 2024 at 3:34 AM Eli Zaretskii wrote: > > > That's not useful, since, for example, TS and non-TS mods for those > > "no-language" modes will still want to be treated the same in some > > situations, like .dir-locals.el. > > Yup, so pass them same :language to them and call `get-language-for-mode` > somewhere in the .dir-locals.el machinery? Else suggest to use the base mode, > if it exists. If it doesn't exist, create it? There's no "language" here. Calling things by names they aren't is not useful. All it does is create confusion. > > It attempts to abstract a trait that isn't abstract, by going in the > > opposite direction of that used for abstractions. > > It's interesting how you state a simple get/set is a "leaky abstraction", > but then also not an abstraction at all. It's "leaky" because it "leaks" the idea that it should be a "language". > Let's put it like this: Eglot should probably fix this actual code: > > (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym)) > > to find the language to report to the server. Eglot should not rely on the assumption that the "language", whatever it is, is included verbatim in the mode's symbol name. Neither should Eglot assume anything else about the name of the mode. > What if an Eglot users wants some server just for the non-TS mode? Or a > Yasnippet user some snippets for such a mode? Or even just regular > user some directory-local variable value? Eglot provides hooks to do that. > The more I think about this, the more I think this is problematic. > > But if you guys are so confident, sure, let's try it. If nothing bad > happens great, else I guess I'll refer users to this thread. Yes. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 09:45:59 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 14:45:59 +0000 Received: from localhost ([127.0.0.1]:35644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMqt4-0004ET-Li for submit@debbugs.gnu.org; Mon, 08 Jan 2024 09:45:59 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:57386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMqt2-00042T-Jo for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 09:45:57 -0500 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cce6c719caso19905141fa.2 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 06:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704725144; x=1705329944; 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=6gfEcqvawwJ3kUqnOI6nwLO/5t6So0AfaJZXt4GfGQA=; b=KdMog+QHCO3twG3fIti39bFQtQd48kXyCfElN+Ae6zVh/FH913rI1s5pxwO8HCz6dl kM1LsHV478VOdXwUD/PAA2mZfXqteUCgOztjsyfK7+fNPltZrWv+6L83ww2XnBbLByhi gC9zsuX0BBAY4i2DOuofqHWMNgKB7RWTbdX0VS6RZ75o1mamiSdLhgLCKuENSVueHKeA CZluZAch99q6G7x8uwQESDvO1T6R8Df/qvHyrbBqlKVojQRMH2ixpkdFRlVIvI44/u6X lTK0nzz5ke3TjFjYpKm1t5rXFwRw921GPRrwE+O8Abjyx9mNK3D0GU62PejN8sGmKJuq MOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704725144; x=1705329944; 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=6gfEcqvawwJ3kUqnOI6nwLO/5t6So0AfaJZXt4GfGQA=; b=FQnnycP+kp0yxbFnzUR63eoOgl14E3UKNj3oHBxtq62k0oCtEEchv581AFvXZm/9k6 lS+6VXVKZy2Rqb+SQLO9sMDCzZVDJ3gpwiQPJkNxoEz3Yld3EwovnRXgD8u0PhQ3Uex1 Y/VoM2/Pu/zELAQkc7979Y/4ZD9vCXnitbUclKc3b/sFBhZICooM7jcXjgtMxXvPJXzZ KTxwdeUu/wE8Tzd5aOjFDRcFJKw60mt+IMJBT+KlhCSgt1OpOwYxxe/6v10ETOuJu/Pp PAxkKku2e9TiPsExwdAxii0kvyBmMKl2kQf6BJVMPsdxX7t0Su/ptB2DtzAF4xY12vHn kFqg== X-Gm-Message-State: AOJu0YzXLbjAd17nHuKohFQA25kqA701xwJBV0fsMtOxqcku2akNIXvN Dt8wLSCQGyvIbvQOF7DOIE0RrIiteL8/vMHYraE= X-Google-Smtp-Source: AGHT+IFUtXBfPLvEpFlL/wFo2gHlmzwOo085XTqDQlSd9zfP7/mEp/eiBpSHApjWYoZ7UeQJAZhpicuBJZ+XQkb3UPY= X-Received: by 2002:a2e:be8d:0:b0:2cd:4c5c:7b8b with SMTP id a13-20020a2ebe8d000000b002cd4c5c7b8bmr1251231ljr.34.1704725144066; Mon, 08 Jan 2024 06:45:44 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> In-Reply-To: <834jfoq86m.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 8 Jan 2024 14:45:31 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 8, 2024 at 1:14=E2=80=AFPM Eli Zaretskii wrote: > > > It attempts to abstract a trait that isn't abstract, by going in the > > > opposite direction of that used for abstractions. > > > > It's interesting how you state a simple get/set is a "leaky abstraction= ", > > but then also not an abstraction at all. > > It's "leaky" because it "leaks" the idea that it should be a > "language". Oh right, of course. Who came with this "leaky" idea that there are programming languages are all? > > Let's put it like this: Eglot should probably fix this actual code: > > > > (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym)) > > > > to find the language to report to the server. > > Eglot should not rely on the assumption that the "language", whatever > it is, is included verbatim in the mode's symbol name. Neither should > Eglot assume anything else about the name of the mode. You could have capped it off with "neither should it work" for maximum consistency. Else, it has to have this database itself. And so does Yasnippet and likely others. This is what Stefan had to say about it: > > I don't think embedding (repeatedly) in YASnippet, CEDET, Eglot, ffap, > > lsp-mode, (and all the others that I don't happen to know offhand) the > > knowledge that `FOO-ts-mode` is used for the same files as `FOO-mode` > > qualifies as "fixing". So that's why I formalized what others had already proposed, but you bash it with whatever random CS adjectives you find at hand. > > What if an Eglot users wants some server just for the non-TS mode? Or = a > > Yasnippet user some snippets for such a mode? Or even just regular > > user some directory-local variable value? > > Eglot provides hooks to do that. ??? I think it's better to not answer when you don't have an answer. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 12:16:13 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 17:16:13 +0000 Received: from localhost ([127.0.0.1]:37444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMtEM-00014v-5E for submit@debbugs.gnu.org; Mon, 08 Jan 2024 12:16:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMtEK-0000uK-6s for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 12:16:04 -0500 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 1rMtE7-0008TY-Qz; Mon, 08 Jan 2024 12:15:51 -0500 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=q1IfWIsFn2rAXQwIm85LphrmwZaReSJqC1yls8DZ/sk=; b=SRfZWGG2T4dS1U0HYBcu mCn6FLqVHDJ2db/yHV901kqfJCP7uHjMwRg9S4L5q6+/gZDW3DDToEHVz9jEH7PNB3smw2lUGyn1h W5EWYszP/J9binmsvqLML7VBh3WUCAKZkWeay9ZzzHLoW91JsxYbTu5VebHWqIuE3bInHjUnSRhWu Bp2UAXobrRGH6M8rYaoowY7GsjxZUlNSha5WMYMP3wEOun7BjaImc+KRlRBsAGQHpAUFdfkTULS0H /IvLmAJacJB3bsS6jCi8j2YkTSm0Wl75PIADQIW5aM8cBrAGmVWO1dmNW+xmJ8htu+DRfAYn5ev9m 0xj7FGGrVjffxA==; Date: Mon, 08 Jan 2024 19:15:46 +0200 Message-Id: <831qarrbjx.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Mon, 8 Jan 2024 14:45:31 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Mon, 8 Jan 2024 14:45:31 +0000 > Cc: monnier@iro.umontreal.ca, casouri@gmail.com, 68246@debbugs.gnu.org > > On Mon, Jan 8, 2024 at 1:14 PM Eli Zaretskii wrote: > > > > > It attempts to abstract a trait that isn't abstract, by going in the > > > > opposite direction of that used for abstractions. > > > > > > It's interesting how you state a simple get/set is a "leaky abstraction", > > > but then also not an abstraction at all. > > > > It's "leaky" because it "leaks" the idea that it should be a > > "language". > > Oh right, of course. Who came with this "leaky" idea that there > are programming languages are all? For some reason, once any discussion with you got past some number of messages, it always deteriorates into a stream of ad-hominem and sarcastic nonsense. I'm outta here. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 13:17:15 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 18:17:15 +0000 Received: from localhost ([127.0.0.1]:37543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuBV-00054v-LG for submit@debbugs.gnu.org; Mon, 08 Jan 2024 13:17:15 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuBS-00054h-O3 for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 13:17:12 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6BB1110009F; Mon, 8 Jan 2024 13:16:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704737816; bh=OaCT08l05f7kJuEql6McTvakMhclAApg5tyMpJADwGA=; h=From:To:Subject:In-Reply-To:References:Date:From; b=HZxaSTEYOG3A2jYH/smdzWThwZpgp1e7zqoDyI+EQjq6LNXUzAavne4LCcUn6Txkh oymUBxxDLMyuEStPcQUbaRvrsuYAlcEj+5/knb5DMNJA0tTPnX7gHNQzJoeKJ3j1r8 ieIMaHOEfqwbNposTOQBWiWrrt8b40Xz+/l1SzdvsxBMfXjjE/i0Vt7qQ05DVVsNYY laAPPVTo31tCJhMGgWe/FS4eOc4/iH0sStKcQXzEONvkOMl7wWsAFhJvUcm9chmsfS EVK0EWMXybsJzVSzfPhVuU6RJYUWoZjHdHabQgHj/Pv4ZXo3cBXSG7onyP+MjZnAJ5 fL0MBJfPlPZtw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5135B10004C; Mon, 8 Jan 2024 13:16:56 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 21D541202CB; Mon, 8 Jan 2024 13:16:56 -0500 (EST) From: Stefan Monnier To: 68246@debbugs.gnu.org Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Stefan Monnier's message of "Thu, 04 Jan 2024 18:18:30 -0500") Message-ID: References: Date: Mon, 08 Jan 2024 13:16:48 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.249 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Here's an updated version of my patch, which tries to simplify some of the code in the generic packages. I also added `perl-mode` as parent to `cperl-mode`, following the same reasoning, which helped me find other generic packages affected. Still no doc updates included. Stefan --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=ts-parents.patch Content-Transfer-Encoding: quoted-printable diff --git a/.dir-locals.el b/.dir-locals.el index ce7febca851..4edcad458a4 100644 --- a/.dir-locals.el +++ b/.dir-locals.el @@ -27,9 +27,7 @@ (electric-quote-comment . nil) (electric-quote-string . nil) (mode . bug-reference-prog))) - (c-ts-mode . ((c-ts-mode-indent-style . gnu) - (indent-tabs-mode . t) - (mode . bug-reference-prog))) + (c-ts-mode . ((c-ts-mode-indent-style . gnu))) ;Inherits `c-mode' setting= s. (log-edit-mode . ((log-edit-font-lock-gnu-style . t) (log-edit-setup-add-author . t) (vc-git-log-edit-summary-target-len . 50))) diff --git a/lisp/align.el b/lisp/align.el index fa95f24fa02..81ccc4b5e2d 100644 --- a/lisp/align.el +++ b/lisp/align.el @@ -181,13 +181,12 @@ align-large-region :type '(choice (const :tag "Align a large region silently" nil) integer) :group 'align) =20 -(defcustom align-c++-modes '( c++-mode c-mode java-mode - c-ts-mode c++-ts-mode) +(defcustom align-c++-modes '( c++-mode c-mode java-mode) "A list of modes whose syntax resembles C/C++." :type '(repeat symbol) :group 'align) =20 -(defcustom align-perl-modes '(perl-mode cperl-mode) +(defcustom align-perl-modes '(perl-mode) "A list of modes where Perl syntax is to be seen." :type '(repeat symbol) :group 'align) @@ -576,13 +575,13 @@ align-rules-list "=3D" (group (zero-or-more (syntax whitespace))))) (group . (1 2)) - (modes . '(conf-toml-mode toml-ts-mode lua-mode lua-ts-mode))) + (modes . '(conf-toml-mode lua-mode))) =20 (double-dash-comment (regexp . ,(rx (group (zero-or-more (syntax whitespace))) "--" (zero-or-more nonl))) - (modes . '(lua-mode lua-ts-mode)) + (modes . '(lua-mode)) (column . comment-column) (valid . ,(lambda () (save-excursion diff --git a/lisp/cedet/semantic/symref/grep.el b/lisp/cedet/semantic/symre= f/grep.el index 83e3bc36073..cc4d1546c85 100644 --- a/lisp/cedet/semantic/symref/grep.el +++ b/lisp/cedet/semantic/symref/grep.el @@ -44,9 +44,7 @@ semantic-symref-tool-grep =20 (defvar semantic-symref-filepattern-alist '((c-mode "*.[ch]") - (c-ts-mode "*.[ch]") (c++-mode "*.[chCH]" "*.[ch]pp" "*.cc" "*.hh") - (c++-ts-mode "*.[chCH]" "*.[ch]pp" "*.cc" "*.hh") (html-mode "*.html" "*.shtml" "*.php") (mhtml-mode "*.html" "*.shtml" "*.php") ; FIXME: remove ; duplication of @@ -55,12 +53,8 @@ semantic-symref-filepattern-alist ; major mode definition? (ruby-mode "*.r[bu]" "*.rake" "*.gemspec" "*.erb" "*.haml" "Rakefile" "Thorfile" "Capfile" "Guardfile" "Vagrantfile") - (ruby-ts-mode "*.r[bu]" "*.rake" "*.gemspec" "*.erb" "*.haml" - "Rakefile" "Thorfile" "Capfile" "Guardfile" "Vagrantfile= ") (python-mode "*.py" "*.pyi" "*.pyw") - (python-ts-mode "*.py" "*.pyi" "*.pyw") (perl-mode "*.pl" "*.PL") - (cperl-mode "*.pl" "*.PL") (lisp-interaction-mode "*.el" "*.ede" ".emacs" "_emacs") ) "List of major modes and file extension pattern. diff --git a/lisp/emulation/viper.el b/lisp/emulation/viper.el index 83fcdf89375..287292a24dc 100644 --- a/lisp/emulation/viper.el +++ b/lisp/emulation/viper.el @@ -388,7 +388,6 @@ viper-vi-state-mode-list idl-mode =20 perl-mode - cperl-mode javascript-mode tcl-mode python-mode diff --git a/lisp/files.el b/lisp/files.el index 8b4e4394e5a..e546e9473a3 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -4414,6 +4414,12 @@ dir-locals-collect-variables (funcall predicate key) (or (not key) (derived-mode-p key))) + ;; If KEY is an extra parent it may remain not loaded + ;; (hence with some of its mode-specific vars missing their + ;; `safe-local-variable' property), leading to spurious + ;; prompts about unsafe vars (bug#68246). + (if (and (symbolp key) (autoloadp (indirect-function key))) + (ignore-errors (autoload-do-load (indirect-function key)= ))) (let* ((alist (cdr entry)) (subdirs (assq 'subdirs alist))) (if (or (not subdirs) diff --git a/lisp/htmlfontify.el b/lisp/htmlfontify.el index 6b9c623f31f..89c2bee2204 100644 --- a/lisp/htmlfontify.el +++ b/lisp/htmlfontify.el @@ -586,6 +586,7 @@ 'hfy-colour-vals (defvar hfy-cperl-mode-kludged-p nil) =20 (defun hfy-kludge-cperl-mode () + ;; FIXME: Still? "CPerl mode does its damnedest not to do some of its fontification when = not in a windowing system - try to trick it..." (declare (obsolete nil "28.1")) diff --git a/lisp/info-look.el b/lisp/info-look.el index da7beafe500..cd59fdf17d7 100644 --- a/lisp/info-look.el +++ b/lisp/info-look.el @@ -985,9 +985,8 @@ info-complete finally return "(python)Index"))))) =20 (info-lookup-maybe-add-help - :mode 'cperl-mode - :regexp "[$@%][^a-zA-Z]\\|\\$\\^[A-Z]\\|[$@%]?[a-zA-Z][_a-zA-Z0-9]*" - :other-modes '(perl-mode)) + :mode 'perl-mode + :regexp "[$@%][^a-zA-Z]\\|\\$\\^[A-Z]\\|[$@%]?[a-zA-Z][_a-zA-Z0-9]*") =20 (info-lookup-maybe-add-help :mode 'latex-mode diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index e5835bdb62d..461218cbb7d 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -1314,6 +1314,8 @@ c-ts-mode (lambda (_pos) 'c)) (treesit-font-lock-recompute-features '(emacs-devel))))) =20 +(derived-mode-add-parents 'c-ts-mode '(c-mode)) + ;;;###autoload (define-derived-mode c++-ts-mode c-ts-base-mode "C++" "Major mode for editing C++, powered by tree-sitter. @@ -1357,6 +1359,8 @@ c++-ts-mode (setq-local add-log-current-defun-function #'c-ts-mode--emacs-current-defun-name)))) =20 +(derived-mode-add-parents 'c++-ts-mode '(c++-mode)) + (easy-menu-define c-ts-mode-menu (list c-ts-mode-map c++-ts-mode-map) "Menu for `c-ts-mode' and `c++-ts-mode'." '("C/C++" diff --git a/lisp/progmodes/cmake-ts-mode.el b/lisp/progmodes/cmake-ts-mode= .el index d933e4ebb81..2a185fb0aa2 100644 --- a/lisp/progmodes/cmake-ts-mode.el +++ b/lisp/progmodes/cmake-ts-mode.el @@ -261,6 +261,8 @@ cmake-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'cmake-ts-mode '(cmake-mode)) + (if (treesit-ready-p 'cmake) (add-to-list 'auto-mode-alist '("\\(?:CMakeLists\\.txt\\|\\.cmake\\)\\'" . cmake-ts-mod= e))) diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el index 9f7f29b8182..2496100c21c 100644 --- a/lisp/progmodes/cperl-mode.el +++ b/lisp/progmodes/cperl-mode.el @@ -1922,6 +1922,8 @@ cperl-mode ;; Setup Flymake (add-hook 'flymake-diagnostic-functions #'perl-flymake nil t)) =20 +(derived-mode-add-parents 'cperl-mode '(perl-mode)) + (defun cperl--set-file-style () (when cperl-file-style (cperl-set-style cperl-file-style))) diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el index 7bf57bcbe21..18114d08528 100644 --- a/lisp/progmodes/csharp-mode.el +++ b/lisp/progmodes/csharp-mode.el @@ -998,6 +998,8 @@ csharp-ts-mode =20 (add-to-list 'auto-mode-alist '("\\.cs\\'" . csharp-ts-mode))) =20 +(derived-mode-add-parents 'csharp-ts-mode '(csharp-mode)) + (provide 'csharp-mode) =20 ;;; csharp-mode.el ends here diff --git a/lisp/progmodes/dockerfile-ts-mode.el b/lisp/progmodes/dockerfi= le-ts-mode.el index 334f3064d98..618082cfe7a 100644 --- a/lisp/progmodes/dockerfile-ts-mode.el +++ b/lisp/progmodes/dockerfile-ts-mode.el @@ -190,6 +190,8 @@ dockerfile-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'dockerfile-ts-mode '(dockerfile-mode)) + (if (treesit-ready-p 'dockerfile) (add-to-list 'auto-mode-alist ;; NOTE: We can't use `rx' here, as it breaks bootstrap. diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index ba2cc72a6b4..7007e71713b 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -226,90 +226,101 @@ eglot-alternatives when probe return (cons probe args) finally (funcall err))))))) =20 -(defvar eglot-server-programs `(((rust-ts-mode rust-mode) . ("rust-analyze= r")) - ((cmake-mode cmake-ts-mode) . ("cmake-lang= uage-server")) - (vimrc-mode . ("vim-language-server" "--st= dio")) - ((python-mode python-ts-mode) - . ,(eglot-alternatives - '("pylsp" "pyls" ("pyright-langserver= " "--stdio") "jedi-language-server" "ruff-lsp"))) - ((js-json-mode json-mode json-ts-mode) - . ,(eglot-alternatives '(("vscode-json-la= nguage-server" "--stdio") - ("vscode-json-la= nguageserver" "--stdio") - ("json-languages= erver" "--stdio")))) - (((js-mode :language-id "javascript") - (js-ts-mode :language-id "javascript") - (tsx-ts-mode :language-id "typescriptrea= ct") - (typescript-ts-mode :language-id "typesc= ript") - (typescript-mode :language-id "typescrip= t")) - . ("typescript-language-server" "--stdio"= )) - ((bash-ts-mode sh-mode) . ("bash-language-= server" "start")) - ((php-mode phps-mode) - . ,(eglot-alternatives - '(("phpactor" "language-server") - ("php" "vendor/felixfbecker/languag= e-server/bin/php-language-server.php")))) - ((c-mode c-ts-mode c++-mode c++-ts-mode ob= jc-mode) - . ,(eglot-alternatives - '("clangd" "ccls"))) - (((caml-mode :language-id "ocaml") - (tuareg-mode :language-id "ocaml") reaso= n-mode) - . ("ocamllsp")) - ((ruby-mode ruby-ts-mode) - . ("solargraph" "socket" "--port" :autopo= rt)) - (haskell-mode - . ("haskell-language-server-wrapper" "--l= sp")) - (elm-mode . ("elm-language-server")) - (mint-mode . ("mint" "ls")) - (kotlin-mode . ("kotlin-language-server")) - ((go-mode go-dot-mod-mode go-dot-work-mode= go-ts-mode go-mod-ts-mode) - . ("gopls")) - ((R-mode ess-r-mode) . ("R" "--slave" "-e" - "languageserver::r= un()")) - ((java-mode java-ts-mode) . ("jdtls")) - ((dart-mode dart-ts-mode) - . ("dart" "language-server" - "--client-id" "emacs.eglot-dart")) - ((elixir-mode elixir-ts-mode heex-ts-mode) - . ,(if (and (fboundp 'w32-shell-dos-seman= tics) - (w32-shell-dos-semantics)) - '("language_server.bat") - (eglot-alternatives - '("language_server.sh" "start_lexic= al.sh")))) - (ada-mode . ("ada_language_server")) - (scala-mode . ,(eglot-alternatives - '("metals" "metals-emacs")= )) - (racket-mode . ("racket" "-l" "racket-lang= server")) - ((tex-mode context-mode texinfo-mode bibte= x-mode) - . ,(eglot-alternatives '("digestif" "texl= ab"))) - (erlang-mode . ("erlang_ls" "--transport" = "stdio")) - ((yaml-ts-mode yaml-mode) . ("yaml-languag= e-server" "--stdio")) - (nix-mode . ,(eglot-alternatives '("nil" "= rnix-lsp" "nixd"))) - (nickel-mode . ("nls")) - (gdscript-mode . ("localhost" 6008)) - ((fortran-mode f90-mode) . ("fortls")) - (futhark-mode . ("futhark" "lsp")) - ((lua-mode lua-ts-mode) . ,(eglot-alternat= ives - '("lua-languag= e-server" "lua-lsp"))) - (zig-mode . ("zls")) - ((css-mode css-ts-mode) - . ,(eglot-alternatives '(("vscode-css-lan= guage-server" "--stdio") - ("css-languagese= rver" "--stdio")))) - (html-mode . ,(eglot-alternatives '(("vsco= de-html-language-server" "--stdio") ("html-languageserver" "--stdio")))) - ((dockerfile-mode dockerfile-ts-mode) . ("= docker-langserver" "--stdio")) - ((clojure-mode clojurescript-mode clojurec= -mode clojure-ts-mode) - . ("clojure-lsp")) - ((csharp-mode csharp-ts-mode) - . ,(eglot-alternatives - '(("omnisharp" "-lsp") - ("csharp-ls")))) - (purescript-mode . ("purescript-language-s= erver" "--stdio")) - ((perl-mode cperl-mode) . ("perl" "-MPerl:= :LanguageServer" "-e" "Perl::LanguageServer::run")) - (markdown-mode - . ,(eglot-alternatives - '(("marksman" "server") - ("vscode-markdown-language-server" = "--stdio")))) - (graphviz-dot-mode . ("dot-language-server= " "--stdio")) - (terraform-mode . ("terraform-ls" "serve")) - ((uiua-ts-mode uiua-mode) . ("uiua" "lsp")= )) +(defvar eglot-server-programs + ;; FIXME: Maybe this info should be distributed into the major modes + ;; themselves where they could set a buffer-local `eglot-server-program' + ;; instead of keeping this database centralized. + ;; FIXME: With `derived-mode-add-parents' in Emacs=E2=89=A530, some of + ;; those entries can be simplified, but we keep them for when + ;; `eglot.el' is installed via GNU ELPA in an older Emacs. + `(((rust-ts-mode rust-mode) . ("rust-analyzer")) + ((cmake-mode cmake-ts-mode) . ("cmake-language-server")) + (vimrc-mode . ("vim-language-server" "--stdio")) + ((python-mode python-ts-mode) + . ,(eglot-alternatives + '("pylsp" "pyls" ("pyright-langserver" "--stdio") + "jedi-language-server" "ruff-lsp"))) + ((js-json-mode json-mode json-ts-mode) + . ,(eglot-alternatives '(("vscode-json-language-server" "--stdio") + ("vscode-json-languageserver" "--stdio") + ("json-languageserver" "--stdio")))) + (((js-mode :language-id "javascript") + (js-ts-mode :language-id "javascript") + (tsx-ts-mode :language-id "typescriptreact") + (typescript-ts-mode :language-id "typescript") + (typescript-mode :language-id "typescript")) + . ("typescript-language-server" "--stdio")) + ((bash-ts-mode sh-mode) . ("bash-language-server" "start")) + ((php-mode phps-mode) + . ,(eglot-alternatives + '(("phpactor" "language-server") + ("php" "vendor/felixfbecker/language-server/bin/php-language-se= rver.php")))) + ((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode) + . ,(eglot-alternatives + '("clangd" "ccls"))) + (((caml-mode :language-id "ocaml") + (tuareg-mode :language-id "ocaml") reason-mode) + . ("ocamllsp")) + ((ruby-mode ruby-ts-mode) + . ("solargraph" "socket" "--port" :autoport)) + (haskell-mode + . ("haskell-language-server-wrapper" "--lsp")) + (elm-mode . ("elm-language-server")) + (mint-mode . ("mint" "ls")) + (kotlin-mode . ("kotlin-language-server")) + ((go-mode go-dot-mod-mode go-dot-work-mode go-ts-mode go-mod-ts-mode) + . ("gopls")) + ((R-mode ess-r-mode) . ("R" "--slave" "-e" + "languageserver::run()")) + ((java-mode java-ts-mode) . ("jdtls")) + ((dart-mode dart-ts-mode) + . ("dart" "language-server" + "--client-id" "emacs.eglot-dart")) + ((elixir-mode elixir-ts-mode heex-ts-mode) + . ,(if (and (fboundp 'w32-shell-dos-semantics) + (w32-shell-dos-semantics)) + '("language_server.bat") + (eglot-alternatives + '("language_server.sh" "start_lexical.sh")))) + (ada-mode . ("ada_language_server")) + (scala-mode . ,(eglot-alternatives + '("metals" "metals-emacs"))) + (racket-mode . ("racket" "-l" "racket-langserver")) + ((tex-mode context-mode texinfo-mode bibtex-mode) + . ,(eglot-alternatives '("digestif" "texlab"))) + (erlang-mode . ("erlang_ls" "--transport" "stdio")) + ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio")) + (nix-mode . ,(eglot-alternatives '("nil" "rnix-lsp" "nixd"))) + (nickel-mode . ("nls")) + (gdscript-mode . ("localhost" 6008)) + ((fortran-mode f90-mode) . ("fortls")) + (futhark-mode . ("futhark" "lsp")) + ((lua-mode lua-ts-mode) . ,(eglot-alternatives + '("lua-language-server" "lua-lsp"))) + (zig-mode . ("zls")) + ((css-mode css-ts-mode) + . ,(eglot-alternatives '(("vscode-css-language-server" "--stdio") + ("css-languageserver" "--stdio")))) + (html-mode . ,(eglot-alternatives + '(("vscode-html-language-server" "--stdio") + ("html-languageserver" "--stdio")))) + ((dockerfile-mode dockerfile-ts-mode) . ("docker-langserver" "--stdio"= )) + ((clojure-mode clojurescript-mode clojurec-mode clojure-ts-mode) + . ("clojure-lsp")) + ((csharp-mode csharp-ts-mode) + . ,(eglot-alternatives + '(("omnisharp" "-lsp") + ("csharp-ls")))) + (purescript-mode . ("purescript-language-server" "--stdio")) + ((perl-mode cperl-mode) + . ("perl" "-MPerl::LanguageServer" "-e" "Perl::LanguageServer::run")) + (markdown-mode + . ,(eglot-alternatives + '(("marksman" "server") + ("vscode-markdown-language-server" "--stdio")))) + (graphviz-dot-mode . ("dot-language-server" "--stdio")) + (terraform-mode . ("terraform-ls" "serve")) + ((uiua-ts-mode uiua-mode) . ("uiua" "lsp"))) "How the command `eglot' guesses the server to start. An association list of (MAJOR-MODE . CONTACT) pairs. MAJOR-MODE identifies the buffers that are to be managed by a specific diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mo= de.el index b493195eedd..9a819f5df0c 100644 --- a/lisp/progmodes/elixir-ts-mode.el +++ b/lisp/progmodes/elixir-ts-mode.el @@ -745,6 +745,8 @@ elixir-ts-mode (treesit-major-mode-setup) (setq-local syntax-propertize-function #'elixir-ts--syntax-propertize)= )) =20 +(derived-mode-add-parents 'elixir-ts-mode '(elixir-mode)) + (if (treesit-ready-p 'elixir) (progn (add-to-list 'auto-mode-alist '("\\.elixir\\'" . elixir-ts-mode)) diff --git a/lisp/progmodes/go-ts-mode.el b/lisp/progmodes/go-ts-mode.el index 65adc1c55ea..e16459cd975 100644 --- a/lisp/progmodes/go-ts-mode.el +++ b/lisp/progmodes/go-ts-mode.el @@ -261,6 +261,8 @@ go-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'go-ts-mode '(go-mode)) + (if (treesit-ready-p 'go) (add-to-list 'auto-mode-alist '("\\.go\\'" . go-ts-mode))) =20 @@ -437,6 +439,9 @@ go-mod-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'go-mode-ts-mode '(go-mod-mode)) + + (if (treesit-ready-p 'gomod) (add-to-list 'auto-mode-alist '("/go\\.mod\\'" . go-mod-ts-mode))) =20 diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el index be6357f4139..8b911918e86 100644 --- a/lisp/progmodes/gud.el +++ b/lisp/progmodes/gud.el @@ -3673,6 +3673,9 @@ gud-tooltip-mode (defcustom gud-tooltip-modes '( gud-mode c-mode c++-mode fortran-mode python-mode c-ts-mode c++-ts-mode python-ts-mode) + ;; FIXME: Currently the check is made via + ;; `(memq major-mode gud-tooltip-modes)' so it doesn't pay attention + ;; to the mode hierarchy. "List of modes for which to enable GUD tooltips." :type '(repeat (symbol :tag "Major mode")) :group 'tooltip) diff --git a/lisp/progmodes/heex-ts-mode.el b/lisp/progmodes/heex-ts-mode.el index 7b53a44deb2..702610bc1eb 100644 --- a/lisp/progmodes/heex-ts-mode.el +++ b/lisp/progmodes/heex-ts-mode.el @@ -177,6 +177,8 @@ heex-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'heex-ts-mode '(heex-mode)) + (if (treesit-ready-p 'heex) ;; Both .heex and the deprecated .leex files should work ;; with the tree-sitter-heex grammar. diff --git a/lisp/progmodes/hideshow.el b/lisp/progmodes/hideshow.el index b181b21118f..b47a505f64f 100644 --- a/lisp/progmodes/hideshow.el +++ b/lisp/progmodes/hideshow.el @@ -254,6 +254,9 @@ hs-isearch-open =20 ;;;###autoload (defvar hs-special-modes-alist + ;; FIXME: Currently the check is made via + ;; `(assoc major-mode hs-special-modes-alist)' so it doesn't pay attenti= on + ;; to the mode hierarchy. (mapcar #'purecopy '((c-mode "{" "}" "/[*/]" nil nil) (c-ts-mode "{" "}" "/[*/]" nil nil) diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el index 0b1ac49b99f..51e0eeef79a 100644 --- a/lisp/progmodes/java-ts-mode.el +++ b/lisp/progmodes/java-ts-mode.el @@ -401,6 +401,8 @@ java-ts-mode ("Method" "\\`method_declaration\\'" nil nil))) (treesit-major-mode-setup)) =20 +(derived-mode-add-parents 'java-ts-mode '(java-mode)) + (if (treesit-ready-p 'java) (add-to-list 'auto-mode-alist '("\\.java\\'" . java-ts-mode))) =20 diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el index 0115feb0e97..2420bdde50a 100644 --- a/lisp/progmodes/js.el +++ b/lisp/progmodes/js.el @@ -3898,6 +3898,8 @@ js-ts-mode (add-to-list 'auto-mode-alist '("\\(\\.js[mx]\\|\\.har\\)\\'" . js-ts-mode)))) =20 +(derived-mode-add-parents 'js-ts-mode '(js-mode)) + (defvar js-ts--s-p-query (when (treesit-available-p) (treesit-query-compile 'javascript diff --git a/lisp/progmodes/json-ts-mode.el b/lisp/progmodes/json-ts-mode.el index 32bc10bbda9..1fb96555010 100644 --- a/lisp/progmodes/json-ts-mode.el +++ b/lisp/progmodes/json-ts-mode.el @@ -164,6 +164,8 @@ json-ts-mode =20 (treesit-major-mode-setup)) =20 +(derived-mode-add-parents 'json-ts-mode '(json-mode)) + (if (treesit-ready-p 'json) (add-to-list 'auto-mode-alist '("\\.json\\'" . json-ts-mode))) diff --git a/lisp/progmodes/lua-ts-mode.el b/lisp/progmodes/lua-ts-mode.el index 3b600f59521..e81f05ff3cb 100644 --- a/lisp/progmodes/lua-ts-mode.el +++ b/lisp/progmodes/lua-ts-mode.el @@ -757,6 +757,8 @@ lua-ts-mode =20 (add-hook 'flymake-diagnostic-functions #'lua-ts-flymake-luacheck nil 'l= ocal)) =20 +(derived-mode-add-parents 'lua-ts-mode '(lua-mode)) + (when (treesit-ready-p 'lua) (add-to-list 'auto-mode-alist '("\\.lua\\'" . lua-ts-mode))) =20 diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el index 1148da11a06..94a133b0688 100644 --- a/lisp/progmodes/python.el +++ b/lisp/progmodes/python.el @@ -6995,6 +6995,8 @@ python-ts-mode (add-to-list 'auto-mode-alist '("\\.py[iw]?\\'" . python-ts-mode)) (add-to-list 'interpreter-mode-alist '("python[0-9.]*" . python-ts-mod= e)))) =20 +(derived-mode-add-parents 'python-ts-mode '(python-mode)) + ;;; Completion predicates for M-x ;; Commands that only make sense when editing Python code. (dolist (sym '(python-add-import diff --git a/lisp/progmodes/ruby-ts-mode.el b/lisp/progmodes/ruby-ts-mode.el index 598eaa461ff..7282d43e091 100644 --- a/lisp/progmodes/ruby-ts-mode.el +++ b/lisp/progmodes/ruby-ts-mode.el @@ -1196,6 +1196,8 @@ ruby-ts-mode =20 (setq-local syntax-propertize-function #'ruby-ts--syntax-propertize)) =20 +(derived-mode-add-parents 'ruby-ts-mode '(ruby-mode)) + (if (treesit-ready-p 'ruby) ;; Copied from ruby-mode.el. (add-to-list 'auto-mode-alist diff --git a/lisp/progmodes/rust-ts-mode.el b/lisp/progmodes/rust-ts-mode.el index c5fc57cc374..c67ac43e4d0 100644 --- a/lisp/progmodes/rust-ts-mode.el +++ b/lisp/progmodes/rust-ts-mode.el @@ -474,6 +474,8 @@ rust-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'rust-ts-mode '(rust-mode)) + (if (treesit-ready-p 'rust) (add-to-list 'auto-mode-alist '("\\.rs\\'" . rust-ts-mode))) =20 diff --git a/lisp/progmodes/sh-script.el b/lisp/progmodes/sh-script.el index 0562415b4e5..e7e08fba1c9 100644 --- a/lisp/progmodes/sh-script.el +++ b/lisp/progmodes/sh-script.el @@ -1638,6 +1638,8 @@ bash-ts-mode (setq-local treesit-defun-type-regexp "function_definition") (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'bash-ts-mode '(sh-mode)) + (advice-add 'bash-ts-mode :around #'sh--redirect-bash-ts-mode ;; Give it lower precedence than normal advice, so other ;; advices take precedence over it. diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescri= pt-ts-mode.el index e9c6afff440..83a3baaf5ef 100644 --- a/lisp/progmodes/typescript-ts-mode.el +++ b/lisp/progmodes/typescript-ts-mode.el @@ -491,6 +491,8 @@ typescript-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'typescript-ts-mode '(typescript-mode)) + (if (treesit-ready-p 'typescript) (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))) =20 @@ -548,6 +550,8 @@ tsx-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'tsx-ts-mode '(tsx-mode)) + (defvar typescript-ts--s-p-query (when (treesit-available-p) (treesit-query-compile 'typescript diff --git a/lisp/textmodes/css-mode.el b/lisp/textmodes/css-mode.el index 425f3ec8a30..f5a20e0ca0e 100644 --- a/lisp/textmodes/css-mode.el +++ b/lisp/textmodes/css-mode.el @@ -1830,6 +1830,8 @@ css-ts-mode =20 (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))) =20 +(derived-mode-add-parents 'css-ts-mode '(css-mode)) + ;;;###autoload (define-derived-mode css-mode css-base-mode "CSS" "Major mode to edit Cascading Style Sheets (CSS). diff --git a/lisp/textmodes/html-ts-mode.el b/lisp/textmodes/html-ts-mode.el index 301f3e8791c..bf6c1307e96 100644 --- a/lisp/textmodes/html-ts-mode.el +++ b/lisp/textmodes/html-ts-mode.el @@ -123,6 +123,8 @@ html-ts-mode '(("Element" "\\`tag_name\\'" nil nil))) (treesit-major-mode-setup)) =20 +(derived-mode-add-parents 'html-ts-mode '(html-mode)) + (if (treesit-ready-p 'html) (add-to-list 'auto-mode-alist '("\\.html\\'" . html-ts-mode))) =20 diff --git a/lisp/textmodes/toml-ts-mode.el b/lisp/textmodes/toml-ts-mode.el index 1ba410045f5..1b621032f8a 100644 --- a/lisp/textmodes/toml-ts-mode.el +++ b/lisp/textmodes/toml-ts-mode.el @@ -153,6 +153,8 @@ toml-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'toml-ts-mode '(toml-mode)) + (if (treesit-ready-p 'toml) (add-to-list 'auto-mode-alist '("\\.toml\\'" . toml-ts-mode))) =20 diff --git a/lisp/textmodes/yaml-ts-mode.el b/lisp/textmodes/yaml-ts-mode.el index 08fe4c49733..dc702dff790 100644 --- a/lisp/textmodes/yaml-ts-mode.el +++ b/lisp/textmodes/yaml-ts-mode.el @@ -165,6 +165,8 @@ yaml-ts-mode =20 (treesit-major-mode-setup))) =20 +(derived-mode-add-parents 'yaml-ts-mode '(yaml-mode)) + (if (treesit-ready-p 'yaml) (add-to-list 'auto-mode-alist '("\\.ya?ml\\'" . yaml-ts-mode))) =20 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 13:57:32 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 18:57:32 +0000 Received: from localhost ([127.0.0.1]:37578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuoW-0002tK-5N for submit@debbugs.gnu.org; Mon, 08 Jan 2024 13:57:32 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:48837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuoT-0002t6-RO for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 13:57:31 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 58D125C0161; Mon, 8 Jan 2024 13:57:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 08 Jan 2024 13:57:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704740238; x=1704826638; bh=hQUK7j/YDwQ/vmrkl/CBTGjoeXuLFFTfE+FA+czkXJ4=; b= jJjDM5Zf8yVTNxcfTcKYi2SLXCzBWi95ydCaXJgw3gLlYoTM+48rvseVYQOrJwj5 zU5GK4WkLHfXeHnWXIUESpR8/zQrVp2uFzB28/666FmYxRrcPRqmji4JcSDsNcIb m7V15gEze0eB/M6OrsCtZP2ywgnvOoWqfPWqofjgJtQm3qsMZRspMa1uh7r9sr4B fe6jwKz787iciQ/xKK4cHr99RHbZrFN8/Z9AmyoCRV61FX6DZILS0FTqClQwrQh4 ceWuk7iWfesByd5j9rvQHR2TPB34L9EpVkbz8YK9IPUtBSPJXRlqVWN3JruK/7Xt KvKQH76yD2zKO2T0ERLNTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704740238; x= 1704826638; bh=hQUK7j/YDwQ/vmrkl/CBTGjoeXuLFFTfE+FA+czkXJ4=; b=O ng61xh6QL+QNMth5C5Q/OAcHjchPPkzb2ae8ptyfU8cYZhvTa8gE/sN90OeUYiq6 NqTIakvY9dGhjmB9sM0OD4g1NvVcMf9LFMBBB9h70bo+xkABxiUX9xCRI1TqrXlv efQ85Rj0K7p8GvCrC+nGHWDLYDBYXZSfPIjxOxdXTNKhdxBf1MprQgkqfa1c6+KG g3Wvrtr/KXXK8s7ZR/l9pGJrg/7AcpP+qJYdT+oXlNs+l7zkrdMOOZpbCNMo+SLs jKn9FW2XR7klRjzDQ8jC/NqWsWv01gzcUtyYM2+OAHsXeNTXyP66y3s7l2YNPj51 ZXAN3gmemtakr708LTzug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehjedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jan 2024 13:57:16 -0500 (EST) Message-ID: <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> Date: Mon, 8 Jan 2024 20:57:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii , Stefan Monnier References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83bk9wq9ho.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/01/2024 14:45, Eli Zaretskii wrote: >> From: Stefan Monnier >> Cc: Eli Zaretskii,casouri@gmail.com,68246@debbugs.gnu.org >> Date: Sun, 07 Jan 2024 23:11:00 -0500 >> >>> (set-language-for-mode 'foo-ts-mode 'foo) >> Maybe we want to introduce this concept, indeed. >> >> maybe we want to that notion of "language" from elsewhere, such as >> the one used in LSP? > Please don't call it "language". That'd be confusing. LSP is about > programming languages, so "language" is natural there. But in Emacs, > a major mode is more general than that. For example, it is not > unthinkable to consider mail-mode to be the extra-parent of > message-mode (or vice versa) -- but what is the "language" in that > case? > >> Or maybe we want to take it from MIME types? >> I'm sure there are other options out there. >> >> Problem is: they come with their own complexities and corner cases. >> After all, this is inevitable when you create a taxonomy. >> IOW, while we*may* want to add support for an explicit notion of "file >> type", it's a whole problem in itself and it will not solve all >> our problems either. > File types also have problems: Emacs modes are sometimes defined for > buffers that don't visit files. Even if we call non-file-visiting buffers' contents "languages", I don't think anyone will have a heart attack or something. But the "languages" thingy will mostly be useful when there can be several different major modes that can work on a given buffer contents. In most/all such cases, we would probably come up with a language name. E.g., for example, we have message-mode, but if we wanted to support alternatives, we could call the base "email-message". Or for different major modes to edit VC commit messages, we could call the language "vc-log-message". From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 14:04:48 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 19:04:48 +0000 Received: from localhost ([127.0.0.1]:37583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuvY-0005fU-3x for submit@debbugs.gnu.org; Mon, 08 Jan 2024 14:04:48 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:49103) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMuvV-0005fE-0n for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 14:04:45 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 46C8B5C0775; Mon, 8 Jan 2024 14:04:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 08 Jan 2024 14:04:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704740673; x=1704827073; bh=S9jhgwK19aIZMEl0qL3Fi8dizO4ypb4wDWSjtvtyujU=; b= JQOyGMmNxDRj5FBrmmPvn+yJdo/0cXpRFLhsEJAL/gB+H93BzONSQJMqrJ9XbHr3 LMoUkgWhVP4vfm7jadagirPDJlJaaxhj9uhRMDOsJs7CZV/cCyeRqUCsmm18Jhg2 RZ47/Y1G54WKKrYK/0fhyG5MZVu/dZtedkCMTWeHLI42bgERuXFYPRS3+YDokeve ZxmYtb+Q+JUlvn0Pag8dKyqnEKH2/cXbfPgJx+szk1YM1Qcenfwrq2Sok9XB/WrZ SCL+vmIIdP3GHbOU3umB2B4/a7g05Gb93NT+X9vFxeS0KOa8FeJDEr2gxTwE4ZL0 UrKHoAoZOKWtSEb/CUo4mw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704740673; x= 1704827073; bh=S9jhgwK19aIZMEl0qL3Fi8dizO4ypb4wDWSjtvtyujU=; b=L D9VEa7mMsNVQQZEy3a+2WoZZLggJuYH3ehqw4QB5sMISWZcgqnCYsjjSZhTRyPfk hwkhhOSMcVahET7am7yT1vjtMc/oNz4G/QrJvbQC0Tz3fh4ljvvBGAvglgi0EDOc uI9+U7K2Omig3qa2/c+AHRlEju4ASMxToo9++gDCs6yJN04Wel9p5pupH9MPLBeL nbLXIGAiHELzfWc0PWjX8GEG3sIa/cqBVCBTkkeNswPoKU89oHdRzea9yPVVFPjx f+NADgbucp1/mLB+9XwBx75f0PIR+aqznDZoIcs9HCiqBN6n1+cJYK3PiEF+moki 2QfVcFYY/c1/gbQnshfFg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehjedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jan 2024 14:04:31 -0500 (EST) Message-ID: Date: Mon, 8 Jan 2024 21:04:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/01/2024 06:11, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> (set-language-for-mode 'foo-ts-mode 'foo) > > Maybe we want to introduce this concept, indeed. > > maybe we want to that notion of "language" from elsewhere, such as > the one used in LSP? > Or maybe we want to take it from MIME types? > I'm sure there are other options out there. I think the precise source of the mapping is not that important. We might as well continue maintaining auto-most-alist, interpreter-mode-alist and magic-mode-alist by hand. Or indeed learn to populate them from the MIME database later. What we have, though, it different major modes duplicating auto-mode-alist entries even inside the core Emacs. Such as c-ts-mode having modified copies of forms that originate from CC Mode. Or ruby-mode and ruby-ts-mode using two copies of the same regexp. Etc. Instead, we could have a mapping of files to "languages" and a separate one from languages to major modes. And one could fetch the "language" for the current buffer using 'rassoc'. > Problem is: they come with their own complexities and corner cases. > After all, this is inevitable when you create a taxonomy. > IOW, while we *may* want to add support for an explicit notion of "file > type", it's a whole problem in itself and it will not solve all > our problems either. > > In the mean time, I think `derived-mode-add-parents` is worth a try. > As mentioned in some message up-thread, I'm not 100% confident that it > won't introduce serious breakage. But I think we do need more > experience and installing my patch is a good way to do that. This would've worked better inside the Emacs 29.1 release (which contains a few other "expedient" solutions). I'm guessing it won't get into 29.2 either. So the users of such versions would have to deal with the existing taxonomy anyway, and half-measures might also serve to make people more confused about what works in which version and why. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 14:18:57 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 19:18:57 +0000 Received: from localhost ([127.0.0.1]:37592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMv9E-00009J-Uz for submit@debbugs.gnu.org; Mon, 08 Jan 2024 14:18:57 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:55640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMv9C-000095-OE for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 14:18:55 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-555f581aed9so2517765a12.3 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 11:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704741522; x=1705346322; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=B6FCbZNMvx0fe3A9DuC9yu1wMvqIbZbKM7s/rCQmAJw=; b=DKOan81HpFtFhu0yYg1I0CFpeEQdhOIeKjC5fFJvzerrVMalcodPHic4hODEn9PwPv yvYUhyWN68h/m519t9ijlr7ihlv0qqlchFLUguttG50E5hJCLa3FAw4Xnu5oYXvGc6yV 8UJQ5YOU9UaHgC4qKiYbfRQpPTnsvR7agyM3sWgrBt74ex7X8CptgJR3xUnIxANrqubo INkhfaagSf58Q0cG5ExasuCrHOr2qWOfGBI/UrFC8huQ4Lhc7Uw50aaXxkFs6ReX5Rbz cZV6nQ+PnlZoFaWcZ7n9gQFhHg5htboaBTgBJRc5aJGWc8fw6vzEz+jOUDNKk29Cnt3E 1f/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704741522; x=1705346322; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B6FCbZNMvx0fe3A9DuC9yu1wMvqIbZbKM7s/rCQmAJw=; b=ZOMWVhTEWQlycq0MWlYQke8ke2KgBg9EdcjdRirM/oLAhS2tdOAjAFVPuuCytR8quv RLvANkcVKlIWuVTBGkiMek3KEmNhdk6aesXa0GT/JsPtre3+3bHfCd1GAwoT/o3xZYm/ sUKhUPtRv+zi3dy18ntpn5MF6kwtBBut4mpA8vlNFQDgKBcLyPLOlDtQfqyzhccZidx5 FCtHFFkx70MiLP3EkYTTHJvDZyu1+mDMwCpplUm/Ard2BPvty+RVW1sbr7YTI/N1whFU bZHZ+GqKbmc0O6JcklPFqxPY+LffDfNRzjj7fqGg2T7TGs9nF57Sdly/DNqCCunWVAM1 ZudA== X-Gm-Message-State: AOJu0YzL2rKeXa+2KwpKBZeXArd+j394SgvOuexzf0B9ZEdS0QCzGc3u sHcSsNAeRqGQ1kVvnfT+ej+ZrX9R8I+oaXoKEr4= X-Google-Smtp-Source: AGHT+IEf/MPzg/jk8TP3UcnDwJbMdTR0HxID6YCafEnqU/3x1YuK1/hDO+otD9BpYmjX4vfXrYLp0kw6RCqf6zb6WfI= X-Received: by 2002:a05:6402:22a7:b0:557:1267:e380 with SMTP id cx7-20020a05640222a700b005571267e380mr2105562edb.77.1704741522269; Mon, 08 Jan 2024 11:18:42 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 8 Jan 2024 11:18:41 -0800 From: Stefan Kangas In-Reply-To: <83bk9wq9ho.fsf@gnu.org> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 8 Jan 2024 11:18:41 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii , Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Please don't call it "language". That'd be confusing. LSP is about > programming languages, so "language" is natural there. But in Emacs, > a major mode is more general than that. For example, it is not > unthinkable to consider mail-mode to be the extra-parent of > message-mode (or vice versa) -- but what is the "language" in that > case? Isn't the language for such modes in this paradigm just the empty set? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 14:56:02 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 19:56:02 +0000 Received: from localhost ([127.0.0.1]:37668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvj7-0006R0-ML for submit@debbugs.gnu.org; Mon, 08 Jan 2024 14:56:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvj2-0006QY-Hj for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 14:56:00 -0500 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 1rMvin-0000vV-9J; Mon, 08 Jan 2024 14:55:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Zjg/1FPS7oX03g1DtcZkyjjhwYC7T5sI8ndR737bqWM=; b=IBm7LQpWvmVN zrQCxMNQ+ukEUoRjL3az+krefO/rDjLqgCo1VCGSn+AZ0k3vxBA6zcUvZKlPRK4+nyNGRy9ukP/9T HlBL/5dH7vmHvC/lMQSfs6TzLe35LRbLtHQw2E/UROKEPLfOSeTAFv97VcLKm+k3S1GMgl2UsxDlG polZJlb9A/UnCf6HBApltM1ICl1Rh1fS/HXCVvR1Avt7X5Ps0Q0BQs7fsbHMglGtHCVJoMUhoiLbm hvT87H2aNBqVOZ8vRl9KgC7Ecgdon41aYo5UQWPzi+LMHe0C3Zrykzm8XwNAS+OBmX1+qLtwqV55h 0sbAcMYDvEveaDwQ7i+KFg==; Date: Mon, 08 Jan 2024 21:55:15 +0200 Message-Id: <83y1czpplo.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> (message from Dmitry Gutov on Mon, 8 Jan 2024 20:57:13 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 8 Jan 2024 20:57:13 +0200 > Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com > From: Dmitry Gutov > > Even if we call non-file-visiting buffers' contents "languages", I don't > think anyone will have a heart attack or something. "No heart attack" is a poor criterion for good parameterization and consistent terminology. Confusing terms will spread confusion and bugs. There's no reason for us to settle for sub-optimal terminology. > E.g., for example, we have message-mode, but if we wanted to support > alternatives, we could call the base "email-message". Or for different > major modes to edit VC commit messages, we could call the language > "vc-log-message". Those are not "languages", so let's not call them that. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 14:57:31 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 19:57:31 +0000 Received: from localhost ([127.0.0.1]:37673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvkZ-0006TM-E9 for submit@debbugs.gnu.org; Mon, 08 Jan 2024 14:57:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvkY-0006TB-F4 for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 14:57:30 -0500 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 1rMvkM-0001QW-PU; Mon, 08 Jan 2024 14:57:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dYxZgJMA31DJiocDRjlKOgK95Adw25qRdyoZG4wjRcQ=; b=qs+n6o3ztF8h BwNMXcKyk8V2yLS14A7Z8a/0VWA3F2Pfktt3aAqWqtM4jF+WLgfHdLeEUmMhwQ0yyN9aiefXDujRW P5Y2JrQ7KJM88vTLbW0EMzTKa6fOmyw829UwHZ9aUIsQegvht46MFuEgQoO0IqdnvH9ewasUZJm4n PzzPqascHA3eSFDexvDW4AYn0J5pLXuz00lBjQXgOKbUZ6Exa2HV8Ykbe1xfMdmz0MvSbyUHOYZv4 BGPjvKVj94Go/yaFIbVfzsPGBkBm6JeHF2pcmWjkZCRdFi9H/DQXbwkCtcO0aBkANSX/j2KlzoUhA 6cV0ySzeDr1QlvcindJSnA==; Date: Mon, 08 Jan 2024 21:57:10 +0200 Message-Id: <83wmsjppih.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Mon, 8 Jan 2024 11:18:41 -0800) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Mon, 8 Jan 2024 11:18:41 -0800 > Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com > > Eli Zaretskii writes: > > > Please don't call it "language". That'd be confusing. LSP is about > > programming languages, so "language" is natural there. But in Emacs, > > a major mode is more general than that. For example, it is not > > unthinkable to consider mail-mode to be the extra-parent of > > message-mode (or vice versa) -- but what is the "language" in that > > case? > > Isn't the language for such modes in this paradigm just the empty set? No. The "language" there is "text", except that it's silly to call that "language". From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 15:06:02 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 20:06:02 +0000 Received: from localhost ([127.0.0.1]:37687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvso-0000px-HG for submit@debbugs.gnu.org; Mon, 08 Jan 2024 15:06:02 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:38659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvsm-0000pT-3l for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 15:06:01 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8DF0F5C05F9; Mon, 8 Jan 2024 15:05:47 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 08 Jan 2024 15:05:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704744347; x=1704830747; bh=B5L6pmZ3DFlOVU+yrnTwWDHw7VQFbw0ZC34uwW5/Pw4=; b= d/SUZI1sjyvURG89gbSHAYhJObSXD8ahR4Ut4u8vwJfHqc1eubiIzlayKK3QVXfa QTv0WjpNSvcmW5J1deikqEP0miURgrirTSH+p6UyMFgu45odE8vH0sDGk59O21mU KnJVpfBfgUcavfbf4BVn5Obqd1GAl1/OFAxkq4JlQhUqvGBs419+2rD5A8L7Y56x DCjtnKmtUJF4ffUULGWxOpevbK+MbdM7rcprlE1B1t9AiYaIHAd8fJjiI1e4jied xwnJiU8BcNiophAnwIIf4MX5YvVLTqmwc4du/XdG9BSSTEdb4O4jqFxXLaHW9ncC YHujmv5i13PW7gswwLnggg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704744347; x= 1704830747; bh=B5L6pmZ3DFlOVU+yrnTwWDHw7VQFbw0ZC34uwW5/Pw4=; b=i o9kDiNX+iv/YbJ4GOgJ+rwRU7c4EgjwmXqwHTbyy648mwQMIYBgRs2G+6UhgXLsf 4qk4L9s0VGNGNnr5YPqK2d/rbQDv+IAGO0GGcYCA8VwvtAO+eoaHrFEdHBYHMqV2 fPNfLOVcjVHjDITQyaOqxtxATyZAyNB4SDyuiPV8ZecqYw60u58kUtcHB70d7oH8 k4FiBnRyoSsj/ML5kUNScMMxam84V9WT071iT76SoDX8Nxx8KytM7byY0XcGm4bX xywskmF+iLIiAAE+NHxjlHpWp8Mz/KRV3ryRBgMRhRJeDdQyYpFSyW+HSxZTTFR9 eMCLVGvyF3klidevqVqJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehjedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jan 2024 15:05:45 -0500 (EST) Message-ID: Date: Mon, 8 Jan 2024 22:05:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii , Stefan Kangas References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <83wmsjppih.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83wmsjppih.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/01/2024 21:57, Eli Zaretskii wrote: >> From: Stefan Kangas >> Date: Mon, 8 Jan 2024 11:18:41 -0800 >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com >> >> Eli Zaretskii writes: >> >>> Please don't call it "language". That'd be confusing. LSP is about >>> programming languages, so "language" is natural there. But in Emacs, >>> a major mode is more general than that. For example, it is not >>> unthinkable to consider mail-mode to be the extra-parent of >>> message-mode (or vice versa) -- but what is the "language" in that >>> case? >> Isn't the language for such modes in this paradigm just the empty set? > No. The "language" there is "text", except that it's silly to call > that "language". If it was just "text", we wouldn't need different highlighting rules in message-mode or log-edit-mode, would we? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 15:07:12 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 20:07:12 +0000 Received: from localhost ([127.0.0.1]:37692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvtv-0000rp-VA for submit@debbugs.gnu.org; Mon, 08 Jan 2024 15:07:12 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:57191) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMvtt-0000rZ-PK for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 15:07:10 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 366195C0054; Mon, 8 Jan 2024 15:06:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 08 Jan 2024 15:06:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704744418; x=1704830818; bh=7vExGQOI9L5q3eacR5dX/efEwFs0tVCWj95oaAxa85s=; b= IfDwRsaqoLLojuL/ixxODA7kse8xzDHKJjt8QWUziOTrIozLTvD2/O0V42AVfF3m ekGmxqZJS6HHjiOoIvbAf26pwDzns9IfbSrH58j6Utdp0tl1ZiXbVzshDTw/eAtO xqFxKNMiAH+ZTiKL0bznvO8PUqz1b9YMxFvWgy/ZNyVOD7XQljW3tXG8WdIMphBJ 5PXTQmNYR8FPqYQfbfq1cRniZCb8Z8AyjlJ9GU/KRlogFlTRc9EFR5vXUZ3okB25 O1z12uMUMkFEb/U58OPkgWxL0yVd5KpkKwV2pY5H1YBae2OdyWZr3w3nhaGOvCwf mm0o9zkB8pBo9DSiAOuvXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704744418; x= 1704830818; bh=7vExGQOI9L5q3eacR5dX/efEwFs0tVCWj95oaAxa85s=; b=8 +/xZpnWT8aGyRwa26g+mft3Bloi7XoJpMRwoZVZBPxUSA3bpkpNlU90oP9Kh/ih1 PIiN3q0AfMhoicXJlw+Jd+2lWPnICrqHMF43iaHPOchtBJf98ZoL39BN798lHoce VYMKSxOeuQfnwZK1L0UC3xxmt/cPytjWNRTDp7IsOLuVY3OCi39vsJXqXZJUWg7a VbnCJ8kJyWpNOW3566JssPM8fWjAejNf8ghIDtJHRuSxKHfFfzcgSY0q7ebDOpM7 Xd/ALG0yGlybsBnGUDmynb7IKjp0VYZGXpBtWoPP2ZSJK11SXh1wqZdw2bFfkU9f 2TRvQqvUb5Rq1Zuem6eNA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehjedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jan 2024 15:06:56 -0500 (EST) Message-ID: Date: Mon, 8 Jan 2024 22:06:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> <83y1czpplo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83y1czpplo.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/01/2024 21:55, Eli Zaretskii wrote: >> Date: Mon, 8 Jan 2024 20:57:13 +0200 >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com >> From: Dmitry Gutov >> >> Even if we call non-file-visiting buffers' contents "languages", I don't >> think anyone will have a heart attack or something. > "No heart attack" is a poor criterion for good parameterization and > consistent terminology. Confusing terms will spread confusion and > bugs. There's no reason for us to settle for sub-optimal terminology. > >> E.g., for example, we have message-mode, but if we wanted to support >> alternatives, we could call the base "email-message". Or for different >> major modes to edit VC commit messages, we could call the language >> "vc-log-message". > Those are not "languages", so let's not call them that. I'm not married to the term (have there been alternatives suggested?), but I do believe that having a notion distinct from "major modes" would bring more clarity in this area. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 17:12:31 2024 Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 22:12:31 +0000 Received: from localhost ([127.0.0.1]:37805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMxrC-0007qx-NR for submit@debbugs.gnu.org; Mon, 08 Jan 2024 17:12:31 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:56520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMxr9-0007qi-VV for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 17:12:28 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cd0c17e42bso25457701fa.0 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 14:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704751935; x=1705356735; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RpomdPqKWi4YToZLj9U6AYGfI8egpwBEUMz8FXyQ2Qg=; b=MucfHsnt7SqCvG+CNJPgpRwDwSkGCD8IW2rkIRR9C8mVFcp6Anp2465TTx5KWeo6SV gF8Qs4Ia00t8P5ekJ0RFxGPkiljt5dS8BY+B5ZShJGfTpJdwdnjpuFFYKAGujkZgy5hl NKt9w4rIxW4jAZXp8uRPcRIs1iQwDG6RblZZIKqWw9dMXrwkYZ1LFwEOThF08P0LjV2l ah/SBlOw0Maunv4unm+TvT8Q9lD3ytipofo/7wcqoa56dFldxKmoyIaHYIq33/aK0Asf NGfVnf6ELvRuV7YQGV8WaokNJp3FNxNnyRJ2NEL+v+RCzWYaJIEt4tW5i2NxTy2fu+4i TVrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704751935; x=1705356735; h=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=RpomdPqKWi4YToZLj9U6AYGfI8egpwBEUMz8FXyQ2Qg=; b=LNHIWd1IlG4965cKsHZxUkFDo9bQi18XjA194dDG84EYAtIkN/vBqfvDtvav+9ktCh TJg4ey11NIVEymmrOtUiIBlxVzDMXZn0HXfXEOOjUeEMoz2vY8ZpCMpB50BQ18Rirsm4 Ne/OcwEdcVT+5b1Ix4f8EAGXJFsuXEUK2APlraPjdtrYTQBdbTzrqTm4+9NxDFgXwfVd Qsp4wbLaJ1x3/1fqjYpfYjk1YK04SU0y6OHhyRe/XRNwO/Lz3Ow0RdsWiYIPiRgvjj8A hPaYbPDYrRe3C1Jh1hmg7DHQEu39JZmghVoQTrjgNJkIoFCMrAzyOvh+CiJAf5wR1CgE /+tA== X-Gm-Message-State: AOJu0Ywv1WCqJvxUp5b47dl4pij9jEgx3sn//jnsctCGA2qBuDGtLKlK aSpHu2okpFDY1oApuS0du1clCH61OdVfEu8MiYE= X-Google-Smtp-Source: AGHT+IHYHjxKqKgJaQ7xxwdRlIrppDMiui/uLg9jB9iM8oF8n7OXwPyI3ZNP63Gqjep6hMIDyvDHqomSm0joQsV0vGQ= X-Received: by 2002:a2e:7408:0:b0:2cc:e386:3772 with SMTP id p8-20020a2e7408000000b002cce3863772mr1669090ljc.29.1704751934881; Mon, 08 Jan 2024 14:12:14 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> <83y1czpplo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 8 Jan 2024 22:12:03 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: multipart/alternative; boundary="0000000000008244c9060e767d88" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008244c9060e767d88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mon, Jan 8, 2024, 20:08 Dmitry Gutov wrote: > > > >> E.g., for example, we have message-mode, but if we wanted to support > >> alternatives, we could call the base "email-message". Or for different > >> major modes to edit VC commit messages, we could call the language > >> "vc-log-message". > > Those are not "languages", so let's not call them that. > > I'm not married to the term (have there been alternatives suggested?), Neither am I btw. Naming is hard, but it shouldn't be _this_ hard. I think editors where you can't write emails, list processes or chat in IRC do use "language" or "file format" In Emacs, it'd make sense to me to give this to at least those modes derived from prog-mode also maybe some more (org, markdown, etc). Other modes would return nil to mean "nope, not a language per se" But if "language" or "file format" is still contentious, browser's use of "content type" seems adequate. Browsers don't always server files after all. Then probably the new getter would return non-nil in even more modes, and coverage would keep growing to theoretically 100%. Jo=C3=A3o --0000000000008244c9060e767d88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Mon, Jan 8, 2024, 20:08 Dmitry Gutov <dmitry@gujutov.dev> wrote:
>
>= ;
> >> E.g., for example, we have message-mode, but if we wante= d to support
> >> alternatives, we could call the base "em= ail-message". Or for different
> >> major modes to edit VC= commit messages, we could call the language
> >> "vc-log-= message".
> > Those are not "languages", so let'= ;s not call them that.
>
> I'm not married to the term (hav= e there been alternatives suggested?),

Neither am I btw. Naming is h= ard, but it shouldn't be
_this_ hard.

I think editors where = you can't write emails, list processes
or chat in IRC do use "= language" or "file format" In Emacs,
it'd make sense= to me to give this to at least those modes
derived from prog-mode also= maybe some more (org, markdown, etc).
Other modes would return nil to m= ean "nope, not a language per=C2=A0
se"

But if &= quot;language" or "file format" is still contentious, browse= r's
use of "content type" seems adequate.=C2=A0 Browsers d= on't always
server files after all.=C2=A0 Then probably the new gett= er would
return non-nil in even more modes, and =C2=A0coverage would ke= ep
growing to theoretically 100%.

Jo=C3=A3o
--0000000000008244c9060e767d88-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 19:11:05 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 00:11:06 +0000 Received: from localhost ([127.0.0.1]:37887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMzhx-0006UL-KY for submit@debbugs.gnu.org; Mon, 08 Jan 2024 19:11:05 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMzhu-0006Tq-Uv for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 19:11:04 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3FA1180DDB; Mon, 8 Jan 2024 19:10:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704759049; bh=ETuhaHYjjKY00i45nPMnZeVyQDWB7yYMr/uhxWJNDIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MVwnltsvBdKasENG9FFQhtXaB1vJMikB2FMvEzCgmOeF9TQj2qTKtpeOQwGL1CPTd jBM1JwU59ZZ3Jp8jnoqLeE3+W3GMHenEq6zzKWpa1gPz9hdc+rAazAf2Fe8fNExtMs kugnI3yevcdpMolObz44GLCkQnm+AgvKUO4WoZOyH8S2GmJIjbCUvai2vRmYBK1Hut JPt6QtwIyDmRIpYhyP/7dBgdSUlESDiGIWjODCQAVYRA65pZa+cF9nEQ4NTeSPM0CQ QFAu/OgtRKweENMrCiI9xmJuGvwIAavc8G+iL3kF7ypCj/b/8pkd/NjOnAeS2sAdHx 6ciXNNvSo5qVA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 00B5480CC9; Mon, 8 Jan 2024 19:10:49 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C2FC1120EC5; Mon, 8 Jan 2024 19:10:48 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Dmitry Gutov's message of "Mon, 8 Jan 2024 21:04:30 +0200") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 08 Jan 2024 19:10:46 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.001 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Instead, we could have a mapping of files to "languages" and a separate o= ne > from languages to major modes. Indeed. I called this one `major-mode-remap-alist`. =F0=9F=99=82 Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 19:36:36 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 00:36:36 +0000 Received: from localhost ([127.0.0.1]:37909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN06e-0003vf-FS for submit@debbugs.gnu.org; Mon, 08 Jan 2024 19:36:36 -0500 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:58567) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN06c-0003vO-AS for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 19:36:34 -0500 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2cd17a979bcso25855031fa.0 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 16:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704760582; x=1705365382; 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=+WxCc5fp7NdNDlKUGi4i85jy7SydiPgoDqcxcD83ncA=; b=kHNKfFzBt/TRjY37MPyikJDqkzZQkytzgUUSa6ARLjj8tQQ9tAAMiVNA/m36fUjOPg f1aUjPkf+D0lMcZlIJcBfdAUeBWs6+mSFCjC2Lx3uSYiFcLLWJg8BI4WnataVX5shxpS N61Mbzoq0kFjl0fvA6iebKWqZms19aoV8oAufCnv+K/ol0WLdnLC4wGYpNPUlg6TIxgU UqcMdgJnfOlb70FEBgBDcnRQafdmF3jKiiRiU0NOLirHYPt6KjXrhb9KoHKvQ4Oq+3GP 2yeiuc14lLjfDV6youNci/1EAw8MxS7Ad6T2xx26rx/wXzl1X8yVZOPgESl9J5jd93wM xB/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704760582; x=1705365382; 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=+WxCc5fp7NdNDlKUGi4i85jy7SydiPgoDqcxcD83ncA=; b=Eg/8NugBKMjI4hp8ZpE/Cn/DjY+cmMG9ui/7D8OxghpsB5I9C1eiYFN6I+5EKTM+2h ZA1OSjnDK4EmuaMgFiUWT8rrSzLNJI+BHH+MNMXDl4fYYYGIQdh9CDH/wkh5kB8sbbeN mkxkUUlT4UPHR/9EOY3rnsQQ2axE4uQZkoRlSV3/Pq2ul8Hvgr48zF+N6IZ+8vXLT6Xd NEGsaYuvOXNciw3z/JfDpWZ+Qyg63RFd07pW5LYoWOOFG3DaNaw7eLHQ+HXK0OxAYn4T LCKCKqr45/j799t9nT+jhvSmKT2Ti1syojifvkqB2cZRrsa5fs9gpLkA/Vp4Sa84+FZk kVjg== X-Gm-Message-State: AOJu0YxMXjoazubEkPNnKeMZaL3sh9aK+zGzYYmPcHAAkYXfoI9kScy/ UGiK3+PdX0e+4Q/yCuMEnj4bIFR/vYtZzxXuanI= X-Google-Smtp-Source: AGHT+IH2Jw1+DwFANT0cOkLocMCcvpGpfSSv8f77sCScH0wZGR9uAUtO4B0dfvco8/Kxav+QzvcyTHH7SmIDokGCFrg= X-Received: by 2002:a2e:b17c:0:b0:2cd:1d5d:3238 with SMTP id a28-20020a2eb17c000000b002cd1d5d3238mr963537ljm.43.1704760581447; Mon, 08 Jan 2024 16:36:21 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 00:39:40 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 12:10=E2=80=AFAM Stefan Monnier wrote: > > > Instead, we could have a mapping of files to "languages" and a separate= one > > from languages to major modes. > > Indeed. I called this one `major-mode-remap-alist`. =F0=9F=99=82 "Called"? Couldn't find this in your latest patch. Can you elaborate on this alist's structure? Does it let one write {eglot|yasnippet}--get-language-for-mode like Dmitry's "languages to major modes" suggests? Jo=C3=A3o BTW, in your patch, can you keep the whitespace of eglot-server-programs or, alternatively, change that whitespace in a separate commit that changes nothing else? I understand the current indentation is awful but I rely on Git history/vc-region-history a lot in the whole of eglot.el From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 19:52:25 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 00:52:25 +0000 Received: from localhost ([127.0.0.1]:37916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0Lx-00077D-0c for submit@debbugs.gnu.org; Mon, 08 Jan 2024 19:52:25 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53645) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0Ls-00076u-Vj for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 19:52:24 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A67AD10009F; Mon, 8 Jan 2024 19:52:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704761523; bh=r2BF6KyVuSHY6jptlQ3J7b52TTdM7Tm+Ix0c+yJoY18=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hT3Clj/8YdoUcbXDO78Uad+Vvexvd2bcS46efCgNnMDh2xfte9qztrr9opVg/uLab V3McZnjLEaAdvChwNaBGwTsWZTQpM/ohMWwBPFhoJrGFPYeUMdK0L2NcI5WiH+QnVP mkQnI3siTD4NC6oHfE5h/9hdx+dFGWOXkLYiv4qBpSJAsRKZCrwnY40NHnipMtnzNK HOl1ZCyPT/bYvMvkVUFIKlW03BYlA50bBjiWIkT8RDmEH5Q7M8jasnG2QoM9Q3OrWf +q0pZGIzGPHjd3xoDJjC1FcCeejG7OTF7FpJbDtaueVNAs/vwCsGdDA4v6tb4HhI4b /hoSs/jI0/M+A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8610B10004C; Mon, 8 Jan 2024 19:52:03 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5443E120866; Mon, 8 Jan 2024 19:52:03 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 9 Jan 2024 00:39:40 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 08 Jan 2024 19:52:01 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.239 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > BTW, in your patch, can you keep the whitespace of eglot-server-programs > or, alternatively, change that whitespace in a separate commit that changes > nothing else? I understand the current indentation is awful Exactly, it's awful and goes against our convention to stay within 80 columns. I'll make it a separate commit. > but I rely on Git history/vc-region-history a lot in the whole of > eglot.el Not sure how making it a separate commit will help. But following the conventions from the get-go would have avoided this specific instance of the problem :-) Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 20:02:09 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 01:02:09 +0000 Received: from localhost ([127.0.0.1]:37925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0VM-0001YW-Jm for submit@debbugs.gnu.org; Mon, 08 Jan 2024 20:02:08 -0500 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:60451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0VI-0001Xm-5G for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 20:02:06 -0500 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2ccec119587so27716121fa.0 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 17:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704762112; x=1705366912; 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=6EyusYbg5EBvAKzfg3F96IJIsUAIFyAUPU6K2bRJNmg=; b=EZxaLhzPd1Ysx9fpv9zwuHrX3h89Tqr+qnMOe7SBEuyVRBGnu3jif0iXroJD1M+TEx 4UmuoTKHyHEakXHA851gHyQVotUr1byS5xQ8BgFmHleVIeWOxVfgHsZcJbjnffHJBlKR 9fUcSp3PfI8mdDn2f5lHFTzt5y1R1SUuRcmlZTznEq4dC1VRC/+9EUW9mNRexUwl0iRD c8lCbXnoV37Wsh+okoRze8DKJop9b8tPqbqZ3FYQjdTw3jDioXTWqI2bLPg6MuQCHDG2 IgrvS9m7zpjySVgI2Q9rUoJTTHLduBn55ueLDzjaKI56HjS4WqTY4coiC/gp8DaiLeaM 627w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704762112; x=1705366912; 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=6EyusYbg5EBvAKzfg3F96IJIsUAIFyAUPU6K2bRJNmg=; b=RVYMbks/tE6ykHcDfWb5ytDti0BHn14qFNjZdb45POBAg+gO9CcWTt8rcsPdPRTHq+ NsyELSp42DOnrQmWrPNM4f35pxfg0CenptOkfozVs54uSkoTHyLTWg9XOC1EtyMIqjLJ +tyvIIbpLuduOZ6F4dHhG5i80u0iwh4m2HQ6tcMVcOrxIM0SJdcM25QcNJWCHxEr0Apy A0CKJgVM5BbvC4h1Rkn7LaNSgAJGWnNxqw4TAATLjuXMZC5ubW4bzw0kXTCLl4l+C+P4 wHxEzklCzhL34lzPDz75gW5I0gSfWlTJ7Uccp/O8KvmB4i8nNP4oMLQOPK6kXzRHcQXA iDMA== X-Gm-Message-State: AOJu0YwpEvwTVjfk0ydDfoo63YfSqmMfQuGwyp/5QSDl7QyO7XbOJqay dtklPF+h1QTZN4+QLM/h0cyykq+HoiG2R8ptm7x1BHWZIRQ= X-Google-Smtp-Source: AGHT+IGKfCrztteNYN6M5p5Px4/iwxfauYR8/GvPINsq40W2qMKjr67LO3ciP0eebm9RiRRdY+8Hauh9OKMUkNa6hTQ= X-Received: by 2002:a2e:9bc6:0:b0:2cd:54d:482f with SMTP id w6-20020a2e9bc6000000b002cd054d482fmr1919181ljj.35.1704762111379; Mon, 08 Jan 2024 17:01:51 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 01:05:10 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 12:52=E2=80=AFAM Stefan Monnier wrote: > But following the conventions from the get-go would have avoided this > specific instance of the problem :-) They were, just look at e36892ef513 :-) But then at a certain point I got a many pull requests requests to add stuff there, no time to bother everyone with indentation (which likely would have been off anyway), the commit message looking decent is a Eeglot. Eglot-alternatives made things worse, with people adding more servers on the same line, and I think this isn't always being enforced by people installing these patches (I don't). > Not sure how making it a separate commit will help. It will say "Stefan Monnier: reformat things", and i will trust that commit changes nothing functionally. Also, git log -L is pretty smart. But you didn't comment on the topic at hand. What does your major-mode-remap-alist look like? Can you write one or two entries of this alist? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 20:04:17 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 01:04:17 +0000 Received: from localhost ([127.0.0.1]:37930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0XR-0001cI-5w for submit@debbugs.gnu.org; Mon, 08 Jan 2024 20:04:17 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0XQ-0001c3-42 for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 20:04:16 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 36D3580D32; Mon, 8 Jan 2024 20:04:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704762243; bh=iTtiNTKdUzrVr20k1COqUNPUxvuUFgj3RHN4wCVEih0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VLorvzTDcAFuJFg8O6BRGIkzUIIipVSo5ttaUxCudAebHejih4CPIUGs+NTFPLsTn +JFLNtq7s4I5BW4MxMBnp3zSLINJw9U7EiWFExlT7xq9EhrD3xjWjyRrH79vPuOIaI Kr3ayBblpNpLZbLvLGuJ0UsLToVIzhyjx6EW2JwT7CXdvs4WiGi1do48Ck84yyFGWt USBa8HW0h7sCNeqMNt6iYS2dw+n2pIdSv6kMvSIKlzl/RE9vC0pVlhaKL8vRPmyHTv td+g+66vqvDOiaH1lBwCczC3yy8Tn0A12n358Kywyw92Z2UNwGgESjPE65yHH7erGg IX5S6WA5/+ATA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4051D80426; Mon, 8 Jan 2024 20:04:03 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EDE21120B70; Mon, 8 Jan 2024 20:04:02 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 9 Jan 2024 01:05:10 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 08 Jan 2024 20:04:02 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.006 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > But you didn't comment on the topic at hand. What does your > major-mode-remap-alist look like? Can you write one or two entries > of this alist? See commit 59f8c56d9e71a1b61ca8cc0794a6de4aa2f240e4 Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 20:08:04 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 01:08:04 +0000 Received: from localhost ([127.0.0.1]:37934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0b5-0001ir-OG for submit@debbugs.gnu.org; Mon, 08 Jan 2024 20:08:04 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:46456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0b3-0001iJ-PO for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 20:08:02 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2ccb923c4d2so25391181fa.1 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 17:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704762469; x=1705367269; 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=lvSpX8hdR801Xh59NuArQJYjhMy84wKndEKK9e8FU3M=; b=TIYYwlNOt065UsbWcPjm35xeOfrUdxk9D7GdC1Hb7PaXQlSDFiOomNmZ+uWxkdCqmF wc3Ozns5UxUsWdKLne0NZFTkgV+LLu9d1hU5YfC+ygH11oMYbdYE6Q1tZrubH/PuON9M H0izgUObyJ4DYc4ghBMjJvEo0O3pftYnI2tnCrCUch8kkv4NcAw9nJ/WdvKxUqOQsQzq 35Gw2V29Xy45S1nq1R0QTtPH81b/fLhp79T7BAjwMP3UTF+kq46hiJbINR9vNgiDsNf1 QoMN2RKM0Akr14yZF1zDrUQH7lgqsI2m7UlK4KpYvijJN20zp/1bbYZ0K0D0tC06aA9H 6kfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704762469; x=1705367269; 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=lvSpX8hdR801Xh59NuArQJYjhMy84wKndEKK9e8FU3M=; b=P2uSzN3xJtfRVNgounOIBp9KVEiWe3UmoflREH9eWkN3g1wsmz01EakiyZywMJLdCQ 6U9JYL2mmmxJvIaUy8CzA6dA8eKQOgG8nEEnfVwNrXDQDMrBLmk52ZMJWh1r3IRbxgYO vVMa0ttyjwLrukT/OIZT/Fl4mWtjExD7UtVjwCb8TGtfzzFwW1fLHcFVi6xF5kobfYBv cl8s+CKBqzRFjr009hp6Xs0XEp69vJYUAo6TnSdS+trKDhxIN2Up2jWrQVpIRQe9hbd4 rRNmYxm7+3gW43H0HGzaCAeT22mPkoJCgY+dCV76IWpO0QYxH1faYalnJJPNTAqlyxvg igQg== X-Gm-Message-State: AOJu0YxpMjgX46ZhRKdWf0Kj4rsD+PfR50fLs4cqMPHMs2Mxp8iCOxaX 0r1UI6pfkD7VPgf3SYxAgwAyK1QOrQwd/Yo9yhU= X-Google-Smtp-Source: AGHT+IGHjL9yR7EAKUbXQLl4MhB3umElC71EctIRO87tytoi4l2Z7xQ1quIyyQFAkFRVg64+WpfEIV8+cEUYDbjMgeE= X-Received: by 2002:a2e:90ce:0:b0:2cc:eb2a:4542 with SMTP id o14-20020a2e90ce000000b002cceb2a4542mr1377261ljg.69.1704762469062; Mon, 08 Jan 2024 17:07:49 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 01:11:08 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 1:04=E2=80=AFAM Stefan Monnier wrote: > > > But you didn't comment on the topic at hand. What does your > > major-mode-remap-alist look like? Can you write one or two entries > > of this alist? > > See commit 59f8c56d9e71a1b61ca8cc0794a6de4aa2f240e4 So, it's nothing like Dmitry's idea: > > Instead, we could have a mapping of files to "languages" and a separate= one > > from languages to major modes. Or were you joking? Or am I missing something obvious? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 20:09:30 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 01:09:30 +0000 Received: from localhost ([127.0.0.1]:37939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0cU-0001lM-6Y for submit@debbugs.gnu.org; Mon, 08 Jan 2024 20:09:30 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:54797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0cR-0001l2-CB for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 20:09:29 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id 8F1153200A81; Mon, 8 Jan 2024 20:09:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 08 Jan 2024 20:09:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704762554; x=1704848954; bh=bUmmIyvFmQUsWHc3lwSSHbJgowrklkikj5KV/VfetvQ=; b= YK2KlqOJWhjAYWuKvS361tPtDBMYe7l57SvNoGdp+GPEgG3ZMTLdzVoZ7QJWKsxl mZMiPrL1+C4/sqm6Guqe+E7Ld/+oQZsj9ghKZ5qxWHg+dUY4vp5RumSd9JPkhE5w rFQWPkVs8uFZL72EgeDdmECHnHkJJtwzM+TUzL6XvApzn/FNnUEniTEyVMsgiPRC X1L5uXN8AAUksdplr2NyfKA1yG1Z+xLfQVc6SVO28iaq3pRQDiRpqYnakVo+aHXL o1c1UnYcflcJZtoOkpMjQn95xCwoJh5mlvBqdsZ31bmz5rn8GN8NCte/+CeR4NL4 EGWyOtIM75w31nAb90eJNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704762554; x= 1704848954; bh=bUmmIyvFmQUsWHc3lwSSHbJgowrklkikj5KV/VfetvQ=; b=Y YC3A3ZofZpZFu5Zry2t19olLv6t8/cCXSLjLMugdCojNtlGi3DivYjbGaeL0ox6g BIrxZ76sdwBBAf9rVo/tu6rRmg2Xvel9fohOdbdr06+fr7flz54N3pqAGbRWzqlw Dwdm80F4PpJT9OCkwoWc/YTmxF/xLK2NduyUPf+MDv57lVvS1Itb2CgIaxr19tVx +Y+SThtC9OmgA7P5Mlirojsehu0wrGefWLUIFfAb/5sWjWg+8aVzBFJ4F0w6TZ62 ndqO2YxfnncSbyvjIXSj5Pw5pBhAC5wdoiHZlXAbhKeklOOK9mweuyUby3btk0eK BkAZWsW0cdAOovIOHlYfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehkedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jan 2024 20:09:12 -0500 (EST) Message-ID: Date: Tue, 9 Jan 2024 03:09:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 09/01/2024 02:10, Stefan Monnier wrote: >> Instead, we could have a mapping of files to "languages" and a separate one >> from languages to major modes. > Indeed. I called this one `major-mode-remap-alist`. 🙂 Good point. I think it's unfortunate that it isn't used more. The good side is that even if "languages" are introduced, this var won't necessarily need renaming. Perhaps we should have entries like ("\\.js\\'" . 'js-lang) in auto-mode-alist and then map the symbol to the specific major mode in major-mode-remap-alist. But for this to be useful to determine the language of a major mode via reverse lookup, all/most programming language modes will need to be featured there, rather than this being optional and used only for custom overrides. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 20:28:25 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 01:28:25 +0000 Received: from localhost ([127.0.0.1]:37951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0um-0004pn-U2 for submit@debbugs.gnu.org; Mon, 08 Jan 2024 20:28:25 -0500 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:55386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN0uh-0004pV-Nk for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 20:28:23 -0500 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cd61dd39d9so4841781fa.2 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 17:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704763687; x=1705368487; 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=kIsdbmscgHeUWa/I0ahtAZnxaW0ml1rep80t+uUgEG8=; b=VQ4TCTXBy51X2fYhp4Q74BIpwhCfYwViRJ1KV+Tflh86pm/KgdcIZhyw3qu36IcL7L nOjYGSB+k6CQmnhbDTUpMG+zDBr2YCzxXoHx9dRZcJ8NRoK+ADnYXBHDNK8JjwMqrySP M6uwfowCGlBHtm71UqEU5Tl5nhSPIUtr0Aj115/u7hURb9SP1UMaZL0weylXN/vnA7YL 6ySWxgdrSzAqlRNr6bZgF7AIu77uss/xk6Ev3SUONKL+Y3b0piK0VvgG+GP4c7ZyFtBa u7HNPOOMrXR+WEHYzVu3vwOqQKXKU5AD5sy02QRTlfu08lPQkTw4VT7xfjEUCsuoboj7 Mo6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704763687; x=1705368487; 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=kIsdbmscgHeUWa/I0ahtAZnxaW0ml1rep80t+uUgEG8=; b=EE0J47IguxXJcowwj1KhadRbqMEiiO/4VkokYbcgGFgh36EupMlq+U8Z4h3UNx+WbZ A0DLo71iE1VMz1UrKue/t+Y37OTNad5Nd5uFzgAfVL1ozFsmHcPNSI/8LvzokE2BTWiK F4M6o/OHKpX2bxK2dYERON/HBMpxi1BHZfBGxSvEE+Uf89sUXSAWfGIHK8RpGQjB+Uft THfd5/Xgq41umx/pmLbZ1TJvgBOoJaoq++8wqeMu88ZT4bwqnBz7uC+eBqiVclRBRuON gwVvFWihejFiRUeVTuCKaLil9iCg3YOL0uIoBSOTRAQPMRcXc8rGeAdJJL0t9M7g8sEv y9XA== X-Gm-Message-State: AOJu0YzjXBcsx73OhQ5XVKCkk4599Qxr3PdohtSugmHSog3R3fFgw9rE 2X18gerRVqNQt4qbyQd7nV6RHaUaXUG+Rc9ag3w= X-Google-Smtp-Source: AGHT+IE499V6SzuaWCzp9IvN2T5W8ZsZt7BL17maABG6k9V2BfbcLbim+eVu/ar9CBJicrbJ1GtLfoBbkF90uw76GFs= X-Received: by 2002:a2e:b384:0:b0:2cd:57ba:b4f2 with SMTP id f4-20020a2eb384000000b002cd57bab4f2mr957722lje.79.1704763687062; Mon, 08 Jan 2024 17:28:07 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 01:31:25 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 1:10=E2=80=AFAM Dmitry Gutov wrot= e: > Perhaps we should have entries like ("\\.js\\'" . 'js-lang) in > auto-mode-alist and then map the symbol to the specific major mode in > major-mode-remap-alist. But for this to be useful to determine the > language of a major mode via reverse lookup, all/most programming > language modes will need to be featured there, rather than this being > optional and used only for custom overrides. That clarifies how it would be used, thanks. But in addition to the problem you note, there's the fact we would have many new foo-lang functions and the cdr of that m-m-r-alist is specified to be a function object, while major-mode is supposed to be symbol, so a bit brittle for reverse lookup. The simplest way to do that reverse mapping is still just adding an optional entry to a mode symbol's plist. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 22:28:15 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 03:28:15 +0000 Received: from localhost ([127.0.0.1]:37976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN2ml-0003cC-0m for submit@debbugs.gnu.org; Mon, 08 Jan 2024 22:28:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN2mg-0003bw-DC for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 22:28:14 -0500 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 1rN2mT-00025X-PZ; Mon, 08 Jan 2024 22:27:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0bb4Z5fHzRExrA3lQB5ap4rvecY2bTPP0q2nWPnb82s=; b=qfKworkZ9xZW Z42J0r1HMzyEDoMLV45U02/hsuH4Mb/HZ2zVmK2IPtIXGK4wUIJakTNwJfhBsEwPw+fOtaKgJwNQf v3ktWdZzFiRtq34x5fFmSUK75oPNSIbusgAvZCoS1mFbORg1lhd0E/LQueKgiUEqJVVOlPNYS9u5s NtwDkAgyXJPnRL4SRp3NTarQ6Emh3vVqzlrHv1vJQP2btdXRo29yjhXr28/OkGAbo1QXMpBQdZUB0 J7GGomH0BaF2LNvRaUBW3oSI/1vM1ZewnxKx4X+5J6qSwcYYrKwSkYgiCr274FsuvstAnXaYtmIdH iIdiG45jyOwkETKYtuaLHQ==; Date: Tue, 09 Jan 2024 05:27:40 +0200 Message-Id: <83v883p4nn.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 8 Jan 2024 22:05:43 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <83wmsjppih.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: joaotavora@gmail.com, 68246@debbugs.gnu.org, casouri@gmail.com, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 8 Jan 2024 22:05:43 +0200 > Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, > joaotavora@gmail.com > From: Dmitry Gutov > > On 08/01/2024 21:57, Eli Zaretskii wrote: > >> From: Stefan Kangas > >> Date: Mon, 8 Jan 2024 11:18:41 -0800 > >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com > >> > >> Eli Zaretskii writes: > >> > >>> Please don't call it "language". That'd be confusing. LSP is about > >>> programming languages, so "language" is natural there. But in Emacs, > >>> a major mode is more general than that. For example, it is not > >>> unthinkable to consider mail-mode to be the extra-parent of > >>> message-mode (or vice versa) -- but what is the "language" in that > >>> case? > >> Isn't the language for such modes in this paradigm just the empty set? > > No. The "language" there is "text", except that it's silly to call > > that "language". > > If it was just "text", we wouldn't need different highlighting rules in > message-mode or log-edit-mode, would we? Why don't you ask the same about perl-mode and cperl-mode? Or about c-mode and c-ts-mode? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 22:29:02 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 03:29:03 +0000 Received: from localhost ([127.0.0.1]:37981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN2nW-0003dw-HO for submit@debbugs.gnu.org; Mon, 08 Jan 2024 22:29:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN2nU-0003dH-Ds for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 22:29:00 -0500 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 1rN2nI-0002WI-I3; Mon, 08 Jan 2024 22:28:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6aK8aG2WD4vU5TeCgsvIP7JDI34ArB4Ftz+6stUjjyY=; b=dj0j+qWQ6cR7 ffHZimBB+iUCMZSGa7SUwKVZLdOuiHegz8HNM7FNqGNidv9+YS5GDK/rRUa/kZ2PaFn+KL6SQUnj0 uuDmdB5ISRA7TIYON/soKfNWEMLMR/YD0LfAUKL+/gfGwJRU8LIMM3g8fFD3QwNAYreqTWMbTSW7j Dp8jzPHm6YMDe9dUVpWn7TOdGQzbAqeO66y/xJ70NbdEV/0C5fBeVRRwG/ql1XRV9W5pnn+tzKcYp SWlWdb/LLYhcry+yeOvDSdzHIVEIwlSJsdSFimAyZutFy8way3dfVKEEez60vrqR87XhNNCFZ3XEX RQ6V+7rh+m5KggfulFGeEg==; Date: Tue, 09 Jan 2024 05:28:32 +0200 Message-Id: <83ttnnp4m7.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 8 Jan 2024 22:06:56 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <49cd2601-5579-4871-a694-42f767dbf2fd@gutov.dev> <83y1czpplo.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 8 Jan 2024 22:06:56 +0200 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org, casouri@gmail.com, > joaotavora@gmail.com > From: Dmitry Gutov > > On 08/01/2024 21:55, Eli Zaretskii wrote: > >> Date: Mon, 8 Jan 2024 20:57:13 +0200 > >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com > >> From: Dmitry Gutov > >> > >> Even if we call non-file-visiting buffers' contents "languages", I don't > >> think anyone will have a heart attack or something. > > "No heart attack" is a poor criterion for good parameterization and > > consistent terminology. Confusing terms will spread confusion and > > bugs. There's no reason for us to settle for sub-optimal terminology. > > > >> E.g., for example, we have message-mode, but if we wanted to support > >> alternatives, we could call the base "email-message". Or for different > >> major modes to edit VC commit messages, we could call the language > >> "vc-log-message". > > Those are not "languages", so let's not call them that. > > I'm not married to the term (have there been alternatives suggested?), > but I do believe that having a notion distinct from "major modes" would > bring more clarity in this area. If we can come up with some sane terminology, let's do that. But adopting incorrect one just because we need some name is not TRT. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 22:49:27 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 03:49:27 +0000 Received: from localhost ([127.0.0.1]:38005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN37G-000139-Qs for submit@debbugs.gnu.org; Mon, 08 Jan 2024 22:49:27 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN37B-00012s-HD for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 22:49:25 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F34B680426; Mon, 8 Jan 2024 22:49:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704772147; bh=bZhXcMxzdEJNrfwB6muXZFTna23qwyCHbub/kiV3IGc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f88aLgMxsI579bA2YGrsldOahn+xMQh7ECBeP2cntky88VoadGB+DXlIydbuhBCl8 fgv6MQL/gFS3eRlpbdHGLNdt3kTJQH/2aJAigQ5sSAUGxz1aEe2AimBqBeS2RcEYMA +t0qoXIS1lDuV7CH12eV/nwSSPf1Hzt88VgK9Cy8Lrf1SDILEKie9RFM1sjnnkqV5f GCiPRGXDMWPgjzY5AR32R/qh4/4of7EqH15EVOHs8ANds9/Ln//nNOmRxcjUUOCAzv v57lMU40NZm2yuJKSxPZDGbl8CU9+jV8Mumvfx/jV/WyEl4FD5hmostWq4wu4cid2/ iO0SWZtT8omSg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E1DC1809A5; Mon, 8 Jan 2024 22:49:07 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB20B12012E; Mon, 8 Jan 2024 22:49:07 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 9 Jan 2024 01:11:08 +0000") Message-ID: References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 08 Jan 2024 22:49:06 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.006 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> See commit 59f8c56d9e71a1b61ca8cc0794a6de4aa2f240e4 > So, it's nothing like Dmitry's idea: Of course it is. >> > Instead, we could have a mapping of files to "languages" and a separate one >> > from languages to major modes. `auto-mode-alist` maps from file names to languages/filetypes (where "major-mode like" symbols are typically used to represent languages/filetypes), and then `major-mode-remap-alist` maps from those languages/filetypes to actual major modes. Of course, if you want to use other symbols for the content types, that works as well, e.g.: emacs --eval '(progn (add-to-list `auto-mode-alist `("\\.myf$" . text/html)) (add-to-list `major-mode-remap-alist `(text/html . html-mode)))' ~/tmp/foo.myf -- Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 22:55:43 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 03:55:44 +0000 Received: from localhost ([127.0.0.1]:38010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN3DL-0001D7-Lu for submit@debbugs.gnu.org; Mon, 08 Jan 2024 22:55:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN3DJ-0001Ct-7d for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 22:55:41 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3676744093F; Mon, 8 Jan 2024 22:55:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704772528; bh=PU2Z35OhJYTZ0Cfv5IGIHFOHJBoFvNwQk9uBE2ui4+4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VfzSZXWIH2Ukgz1Ktw2sN85Ma/sjhYQ0De9pQSEmOMxTg1ADk2jjyBZbYIRrTIcMV BlbxAoC+OqUeKPtbNA/qb/VRyxK6Brx4coddXXaZ1BJlPmkDuxD7KlsoCXlIMLfESQ QTkeneRDA+YrA3L1SEByFcFJRjoTwGRw5LgO/w1zRqQJhINFtahcAzR5375C2nxZsL YCaymehxIIlvfyzaCBFH9Ucq+sigX3y+p1grjS0yIO5TM/WzlVXdpRJP1Nuj/ltPtL MGcPcD17fD2UYJEIHXrlgba727u5F4VIJPb9PCw8KGKdShAvz1vNrT3/8DChcZw+0C cJv/xHWxzGSOA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EE43944067E; Mon, 8 Jan 2024 22:55:27 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B9C46120BA0; Mon, 8 Jan 2024 22:55:27 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Dmitry Gutov's message of "Tue, 9 Jan 2024 03:09:08 +0200") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 08 Jan 2024 22:55:27 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.098 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > But for this to be useful to determine the language > of a major mode via reverse lookup, Define "the language". The mapping from "language" to major mode can't be always reversible, so `major-mode-remap-alist` works to map "language" to "major-mode" but not the other way. The current bug-report *is* about "finding the language" but the code that needs that info luckily doesn't need "the language" it just needs to know "does the current buffer contain language FOO", which is an easier problem, which I propose to solve with `derived-mode-p`, since that's what we've been using all these years. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 08 23:50:12 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 04:50:12 +0000 Received: from localhost ([127.0.0.1]:38063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN444-0004m0-GD for submit@debbugs.gnu.org; Mon, 08 Jan 2024 23:50:12 -0500 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:50613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN442-0004lf-No for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 23:50:11 -0500 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2cd1a1c5addso29331921fa.1 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 20:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704775798; x=1705380598; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=xDuL0q1xiyNu0ztUH7UA6SEpQDVz0ucerAFD8IEf1nY=; b=DfnfmB+L2PDqKz4nrJM6SgyeYm9LZPdEjc1jTOwwi+Cg5QUQIPob70HXm0my838sVQ 6bt70K7CGEN0OLFZUeS7N/sAiZ40u4Xv9ZiZAMmGhkmyVLmEUDzItXzFsR28nEx9xJx4 sepv/iYbaqJidDlp8/1cIfAkpPL+hhQbRSNYh1dJLDn4XtOti8amCDOvph9aYMXtxmna C82gtulVuEZaiamsNkTVCrHq9zq7EAVYH9EzokznlYkUe5s92Uet++6fHjppQokJj0l+ og9qp6ztGjinvDo5gfrwiPbXM+tkBn6D+nfF86gHfQ8y9crUWVm2LMd2PXySdgpvAFlg 9Vcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704775798; x=1705380598; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=xDuL0q1xiyNu0ztUH7UA6SEpQDVz0ucerAFD8IEf1nY=; b=lUdbjHcWbc8cAdlKIU+Tnx+YENkEWPiwV3FFCviW279xOjoicz0BcNTpbnHGDDy8cQ QAZPrUXzOU5BrXpTsScRvk5rQvzNbhA+jQXw5kNInI7yMVV2bdcbROqwDUJhpSQF6XgK bOjOnVQFhCEc3NdQywh8v3e3X5g7dCN7hGQJp/GnFpyg+eT6dcP35Si+dAhk5+RWK7Pl JiTUrrYdR3HLy6vRj6mOQaDIBM1dHKK7jJnmNv61ER77OBmjhwiwqyHq8fkExiRFS9K6 PadWEbFfV4tBKNK7h4xpwRkHqzzjgW5MVsc1eGzEG3mXMoAx6hsIfVMRAYI/x5cCXmLy KwrA== X-Gm-Message-State: AOJu0YzHFweCPXDUG6DgSo56MfiqvkNpawEKy5/BwyjzxrSF36wbh0Td k2FlF4RuJYQYV3tqje9VXwUncKZmvYlhrp/Ygsk= X-Google-Smtp-Source: AGHT+IGAgLIWI8Ss8eHocEgrCRvPPWMkHSTNnbfqDsp9MVuy4/zHOIIknHoUNotokztOceCbF34NuQaPZ/1vbRiEfaQ= X-Received: by 2002:a2e:a7cc:0:b0:2cd:360:135f with SMTP id x12-20020a2ea7cc000000b002cd0360135fmr2635822ljp.73.1704775797969; Mon, 08 Jan 2024 20:49:57 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 8 Jan 2024 20:49:57 -0800 From: Stefan Kangas In-Reply-To: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 8 Jan 2024 20:49:57 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: >> Not sure how making it a separate commit will help. > > It will say "Stefan Monnier: reformat things", and i will trust that > commit changes nothing functionally. Also, git log -L is pretty smart. Making cleanup type changes is useful for git spelunking, but more importantly it simplifies reviewing. You do not have to manually separate the functional changes from the non-functional ones every time you look at some commit in the future. I'd certainly encourage that practice. Git commits are cheap. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 02:25:14 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 07:25:14 +0000 Received: from localhost ([127.0.0.1]:38192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN6U6-0001Go-5e for submit@debbugs.gnu.org; Tue, 09 Jan 2024 02:25:14 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:49362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN6U4-0001GZ-MQ for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 02:25:13 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40e43e48a16so21985605e9.2 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 23:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704785100; x=1705389900; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=L1UE1bvf1Bxf9VNE4VtmXtpskIU+gxnT5wyqjuQVPQc=; b=Snyfj97YnYPYtn8cx3FACLKdco/1UIaZhNAvdzZmeLfy8FK6jM90NkJ53HBnuDpF6y 9yE4EBF6GjuIBHzBKq8/K223IKyCpwvtidsE7opRxYEzmN0ur/YWsAxt187/lIhCHaOb uADfg2Am/S/Q6cypBvde5eAScwaVE7hlusIsn2dnckeJldfu+1OFOTwGCMEtYL28pVoD wQHS/r48o6K7ZHaxSMlcgXOd9yWmKKDfUX2Z0nO6Idn6fjQKVQAw4jeqBa2Isfaqb3vh RzDaAvWAw+d3QUyDwsFQCGOdtXZRx4rOX1i2MFyPdW3x8WBNCddIbt5DAtjpVzO7jPlj tlOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704785100; x=1705389900; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=L1UE1bvf1Bxf9VNE4VtmXtpskIU+gxnT5wyqjuQVPQc=; b=DLyoMX8B6eFC5nPAGyAbNo5asPrEjQ08XSXVqrAzl1wx1pyw1G2e+6c8P1iEj70Yik 13zWkpTRsCGCySh+QBuQp4VxK9Jtk+CUZtn7GKDzXzni4ewETrAgOnpYmEVGmU0Ane44 RPbARe796uyHFGQ7OHbkRhOktE7+4tJNKv7WJEQ/dcBDDCPYuZrlN9Ezcpxfl2qvmpV5 YMUOfBAhBO3V+t2iB/tj7H0oD6+H1X1XnWz7nwz8nnZ/6oCMm07js60g1FxyylzRiP8C cvUCmJlgakCJYCLTsLallWFTlpFEqlRAwsSa6Ip8VN1WmZ5ugnRKAnLrwNI2vugMaAUo 7c/w== X-Gm-Message-State: AOJu0YyYpUizSmf/JMKC9eHP3OZo1BdkNphGsFoQdO0dAtFY5PDupH9W HzrZ+/04wVu5xR/6NTACzT4= X-Google-Smtp-Source: AGHT+IFpJnZJnue9XhCrjVBE/MXK+wWHRMIZUhi3P1s6iAnLfliGsBn4i8JSbjpNeS75WfuZZ3WPSw== X-Received: by 2002:a05:600c:1d16:b0:40e:4f71:250e with SMTP id l22-20020a05600c1d1600b0040e4f71250emr216679wms.27.1704785100026; Mon, 08 Jan 2024 23:25:00 -0800 (PST) Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id u2-20020a7bc042000000b0040d79997731sm5739687wmc.0.2024.01.08.23.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 23:24:59 -0800 (PST) From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 9 Jan 2024 01:05:10 +0000") References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Tue, 09 Jan 2024 08:24:58 +0100 Message-ID: <87mstfvuid.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: casouri@gmail.com, Dmitry Gutov , Stefan Kangas , 68246@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: >> Not sure how making it a separate commit will help. > > It will say "Stefan Monnier: reformat things", and i will trust that > commit changes nothing functionally. Also, git log -L is pretty smart. (Also=C2=B2, that singular cleanup commit can then be passed to git-blame v= ia --ignore-rev or blame.ignoreRevsFile for automatic skipping) From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 05:52:55 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 10:52:55 +0000 Received: from localhost ([127.0.0.1]:38451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN9j1-0001UC-S6 for submit@debbugs.gnu.org; Tue, 09 Jan 2024 05:52:54 -0500 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:48226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN9iw-0001Tt-Dv for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 05:52:50 -0500 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2cd0f4f306fso32553381fa.0 for <68246@debbugs.gnu.org>; Tue, 09 Jan 2024 02:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704797554; x=1705402354; 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=0GqK14glWh9QH523BdBg+cU0BLwY2MVgdCmOt31Fluc=; b=nEiyMTZ9MBtjKgvnqh16cwI4/tYncvuAQK02ImBrAc/gwsv3sYg6YumeyIZaSXjxyl tkDM4FGeMGih5rVN0LOYSoud3onoaBzWOAI18iNWrFZIRFbwuN8FDbhXqA6v57cnwm3H tLsZUgrpOZNcRUzcV7+lhVaw7rlKlnOehFzzjzd/7rGCE0DQilIG/FPpHgiAxIFTMvPp vQktydfVFUZNsDswqY5BZqbA3JN5F2LXBm8S0R/RYVRCraWivaxnLuhrqOPpEM6TD7GQ Zib4uSx1o2ldiXz5jF12YhepNt0ZUbUiPFQgTTVNjOUv/6zP0BwntaFxAqHtDsEr7mPP lY4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704797554; x=1705402354; 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=0GqK14glWh9QH523BdBg+cU0BLwY2MVgdCmOt31Fluc=; b=McP0G5jhVEs/5fhJ9BhRapTjbbn/+diYkgaf0I+1ITIx+FtxwIBlk8WEgN9DNQQFpg j75S5luy5+7oHj0T5E3c5PJYG/oC+wFnxemJie7voah8RMRbGl8AXYz7t5/cWFpVrQK/ UBtLhI8Zy1feePGuVhzQ+xbYIJb8INJK9aBOA/mFnAPmeZxQHttSkqtQbZEwQmsFtCsx t6H/pWg0zzhhMmvUueCLArmbhpvddIMYwBRwydOlKiGlYyOFlmMccMH58PcgqlF0Q2aR /PWpDCX3cquDEn3XaJJBHC5ren7LPWopAZEjDNKRUzZbrMuqrDhggsXYZe9uxqBJRXav dMiw== X-Gm-Message-State: AOJu0YxD51uBm4KwtiHYLdV6tTZ25vv0Kab3J80roG4AHE1ySAtDXKmY 6lEtRrew29ZGwKgKyIU+SV4ndkd7xr3RCx7PDBE3E6pJi7s= X-Google-Smtp-Source: AGHT+IHCT4CXhvL0RqW2fp4MUEYh/9yBveIiGx4YcX5E8VroFEKMT8GHMyNmVRwUbZ5+DB7xPAC5FHNVZSxYkAfFWeo= X-Received: by 2002:a2e:a555:0:b0:2cc:9860:e34e with SMTP id e21-20020a2ea555000000b002cc9860e34emr2696115ljn.56.1704797553459; Tue, 09 Jan 2024 02:52:33 -0800 (PST) MIME-Version: 1.0 References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 10:52:21 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 3:49=E2=80=AFAM Stefan Monnier wrote: > Of course, if you want to use other symbols for the content types, that > works as well, e.g.: > > emacs --eval '(progn (add-to-list `auto-mode-alist `("\\.myf$" . text= /html)) (add-to-list `major-mode-remap-alist `(text/html . html-mode)))' ~/= tmp/foo.myf OK, I get it. This form above is very elegant. I had already understood the gist from Dmitry's email and if more symbols are allowed there (notably symbols with names matching the MIME type hierarchy), then I think it's mostly fine. "Mostly" because of the fact that cdrs of entries in m-m-r-alist are supposed to be functions and major-mode is a symbol, which makes for brittle reverse lookups. And then there's still the work of filling it in and changing auto-mode-alist. This is mostly mechanical work though. I can volunteer if this approach is validated. Also, writing m-m-r-alist is not incompatible to passing a :content-type keyword arg to define-derived-mode, which I still think is the most natural way to maintain this database. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 06:06:23 2024 Received: (at 68246) by debbugs.gnu.org; 9 Jan 2024 11:06:23 +0000 Received: from localhost ([127.0.0.1]:38463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN9w6-0004Pf-OR for submit@debbugs.gnu.org; Tue, 09 Jan 2024 06:06:23 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:42149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rN9w4-0004PP-At for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 06:06:21 -0500 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2ccea11b6bbso26565201fa.0 for <68246@debbugs.gnu.org>; Tue, 09 Jan 2024 03:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704798367; x=1705403167; 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=U2TM8z0e2w0pKdMJE4x7wmdWcmLCwRa4T0FecaW8EOs=; b=ClmM4R36TGiFGkcosMRtHxBzZLPnJOpukis5t4pEFPN2j+JIVRPebdyJnzFserl4SF FTRr5kdOi2cJ4cVl3v71wvaUW5g1KhSuSYZUmLDbUSsslt20h8RKiQtaeP7zmnTkqchv JQ6icYiik6zEhSRVRTRxMCvoVJYuVnGKIJsaOhH09it1edIWGVl2CIN6NevnjMk4KM6A y13KALC9wxOY+O/qWS2zUtKaRpGN6TtH3fjlIYZupgpE/vFbkfr/eLxz1og2WnbDijqx DNT10h8edps0dSaojcpOWTWiUCITrYwYazi8UTO9sswXDI2rQTP47Q8ND04UrzDgyzZX NU1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704798367; x=1705403167; 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=U2TM8z0e2w0pKdMJE4x7wmdWcmLCwRa4T0FecaW8EOs=; b=fpg8jeVIfX7vszKGnqTPvM8B3INI5Idclvd9DOcu/L70tHCVUz4f971t96UBCgiYLI H8HpZbqHsiQnVVNmsyMXkEA1xt1hUAm6q/pEmJIQmw5qzE8SyuY/puY85HiZ2huTDvTD oDrOsYqIfCjg+8qgdvLjXexde+KMG6CzHUaYD4orz9+Ft85aNfnVh6YHdcsOijUW3QqW A07VM/XIp+Y5u1YJT0SWzemNCwQ7JqZqSL+g+Qhe9xglC0Bf5zH031x7AFoWc5W9NX61 f2Rqbt29H6x38RhtiFKl3X56JabGn6XPGCCSZExFTm9wp1rjrCQH4JPitQOBB7KY9t0O ybMQ== X-Gm-Message-State: AOJu0YxOrm+cjvJ0fANEFbfwwN9NINwYe9TS85Smtdi05fEM3on7evxJ +aGw981MuTJvIljdttwc34LQhSM3GsQFX13r7Wo= X-Google-Smtp-Source: AGHT+IEX/5B05TWz6fdeQOvevVZgLxFJMpXAiz35SbNemSSqyHRahx8OiOzZ2iKFn6GtCVC/zc9JVNNcOEaNilZgTew= X-Received: by 2002:a2e:a179:0:b0:2cd:23a7:a350 with SMTP id u25-20020a2ea179000000b002cd23a7a350mr347579ljl.22.1704798367336; Tue, 09 Jan 2024 03:06:07 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 9 Jan 2024 11:05:55 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 9, 2024 at 3:55=E2=80=AFAM Stefan Monnier wrote: > The mapping from "language" to major mode can't be always reversible, so > `major-mode-remap-alist` works to map "language" to "major-mode" but not > the other way. > > The current bug-report *is* about "finding the language" but the code > that needs that info luckily doesn't need "the language" I must be out of luck, because Eglot does need "the language" to send as the LSP "languageID" to the server. > which I propose to solve with `derived-mode-p`, since > that's what we've been using all these years. Even before your patch and before TS modes, derived-mode-p leads to exposing Eglot users looking to customize eglot-server-programs to much more complicated concepts. If I could reliably write `get-language-for-mode`, this is much closer to what they are really after: (ocaml "ocamllsp") (reason "ocamllsp") Instead of (((caml-mode :language-id "ocaml") (tuareg-mode :language-id "ocaml") reason-mode) . ("ocamllsp")) which is what is currently found in the Eglot database. In fact even if LSP languageID wasn't a thing, I still think it's easier to customize on those terms. It's also a fair bit simpler to. And it'd be much simpler for Yasnippet too. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 20:15:57 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 01:15:57 +0000 Received: from localhost ([127.0.0.1]:41397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNCH-0007If-1R for submit@debbugs.gnu.org; Tue, 09 Jan 2024 20:15:57 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:56575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNCE-00076P-MF for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 20:15:55 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 53A5E3200B42; Tue, 9 Jan 2024 20:15:41 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 09 Jan 2024 20:15:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704849340; x=1704935740; bh=NMXB9EKG1w6ct3d2fCJyZSox3zlBsQHteu5GyE+xk3I=; b= KSgPscQIgWkI+98XLTRpAKPiPGGSb6lOyNHk5dEDWTMN4eNWfU0O3ET+bOWVdSZl UZpeuZIOE2sWTRaNZDXtYnXCgyefW0hwOY4YEb6PFgdSqbrEZAmgaimFvLHR+WTQ C5hckuYKe+A8eexPd67apN5hTLJkvOIyxSQfoaYM3k8686vB6w9atLOqzZzpEm8E tH2nd37XFPtGcoLAL1haMTmYPPdhCdMeRv+c3z4WcOBSxKUhweiJXKSJnKkWVtVp fA1wKrzdWYAoVHYQeXQ6ASBy+djJ6pIqTlludug1cDnGlubQpJKzTlgvosHkYv9v YQw9lQ8N0siu+/Owxcwv+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704849340; x= 1704935740; bh=NMXB9EKG1w6ct3d2fCJyZSox3zlBsQHteu5GyE+xk3I=; b=f 13B+4oghptan/5qumLM+aC0hFzyvEkxLztzBJSPfBhKq+k6wmWtFeGDs9se2DmP4 QSYkFVFFf4TKBoOM5G8LCgFVpcDqfmeCZAtuCmBj9fPueleA14XCy7a+gK33bBHF vBlNda+pBOxAEAqkDkrAq7YgZ3MFUin2Yocp7RFJ/tuIyKnoUaOhDQ8LZabjKE5Z v3BTeZG0ZzByedHeb8CYFyFCYLuodqj8uO/etxWcoKVbgQ57vqG5E2apKlO52YCm GVF1e3eJV2jFGKVFRcfC3a8AyzS7hqClfBgkbxhW/cjDphn9dFuYTYZnbRairA/p pRWNDsAEZWP9DobzIHU/A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeitddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jan 2024 20:15:38 -0500 (EST) Message-ID: Date: Wed, 10 Jan 2024 03:15:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 09/01/2024 13:05, João Távora wrote: >> which I propose to solve with `derived-mode-p`, since >> that's what we've been using all these years. > Even before your patch and before TS modes, derived-mode-p leads > to exposing Eglot users looking to customize eglot-server-programs to > much more complicated concepts. > > If I could reliably write `get-language-for-mode`, this is much closer to > what they are really after: > > (ocaml "ocamllsp") > (reason "ocamllsp") In the end, this could be a reliable solution without fully committing that our language identifiers are fully synced to VS Code/LSP. Overrides would still be needed, but it could help shorten the list. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 20:19:07 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 01:19:07 +0000 Received: from localhost ([127.0.0.1]:41403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNFK-00083M-QZ for submit@debbugs.gnu.org; Tue, 09 Jan 2024 20:19:07 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:38243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNFH-00082r-Pm for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 20:19:04 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 92DE93200B13; Tue, 9 Jan 2024 20:18:50 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 09 Jan 2024 20:18:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704849530; x=1704935930; bh=EeZQA4hgLDWb8ic74qxa8FlpSGK6rIcsJLn5AKO349I=; b= WLmx6uWPpD+aICFY+J4rp5H7P3NAnes7ZXXO/eTzd7dQgW0zAtRzcKLwf+wmaUXe J3d+9SutYqUXMwt0l8Ogu4gr15+Tv/sfsqpQR3lDcjcqexu70YM4gkVMdieSzo8v 3q5NOeCPKvwOBtho590zdi5AHu5dIMcx8QbEAcwmzxUvt0WTWXV3VnjyN2tqIKrC enDlCIAa0xZeAEaD15tiVOqCeNz4Uem0gL6vEgKkXZuaN9FeyETO08co54TJJjSf +IKYTzMfjafP4zjs0RO7/fp3I64lF5pXE3d8PJ0fDvVT17gFHaNQuqZ3+hDC322x C9ZDhHSnaD8j+WXUopCghQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704849530; x= 1704935930; bh=EeZQA4hgLDWb8ic74qxa8FlpSGK6rIcsJLn5AKO349I=; b=p 0TppqC2mZsVm26DdrQNpsuqjStdeweKrWSZHbA/qHZO41IfdoL9dTSi2byUQallD iff9HCxu9sOjZqvSSCaO7dgo6DEy6avWcH1iX8iFDd98Y3zWTinYrbMoHb/3WLOn KDZl/VoXs5TRecHfZC4xjhFxLf0LXj6AjBfhx6tG+BCtkof6kjo3ZAgxt7Yl8vBR Pe55+LZTmA32a6H80qz1D3Mp+e3+vQWzJklmfpDoxtvWCOEVsUDd+BCdBn3cvJbo 8Ds3/b7zWFAqSb2JcemC4jFOXiJoMyC1l7Pxd4F5ujbUS0bMV1Y/d3jkOrC3Q25I PV1CylPWofwQx/+wMdS3g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeitddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jan 2024 20:18:48 -0500 (EST) Message-ID: <5ee1a261-0d5d-4567-b98a-5f8100b55b0c@gutov.dev> Date: Wed, 10 Jan 2024 03:18:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 09/01/2024 05:49, Stefan Monnier wrote: >>>> Instead, we could have a mapping of files to "languages" and a separate one >>>> from languages to major modes. > `auto-mode-alist` maps from file names to languages/filetypes (where > "major-mode like" symbols are typically used to represent > languages/filetypes), and then `major-mode-remap-alist` maps from those > languages/filetypes to actual major modes. > > Of course, if you want to use other symbols for the content types, that > works as well, e.g.: > > emacs --eval '(progn (add-to-list `auto-mode-alist `("\\.myf$" . text/html)) (add-to-list `major-mode-remap-alist `(text/html . html-mode)))' ~/tmp/foo.myf That's very nice and concise, but it still leaves the issue of users being able to use a common hook for a family of major modes (for the same language). So I guess some inheritance-based solution is needed? Or another integration for define-derived-mode which would run a hook with name derived from the name of the language. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 20:41:53 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 01:41:53 +0000 Received: from localhost ([127.0.0.1]:41422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNbM-0002lM-SE for submit@debbugs.gnu.org; Tue, 09 Jan 2024 20:41:53 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:59863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNbK-0002l4-K6 for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 20:41:51 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4229B3200B1B; Tue, 9 Jan 2024 20:41:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jan 2024 20:41:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704850896; x=1704937296; bh=htQ99Hi7jMOSyaX2foZsrSyd9F0xaBR2QYZjg5jp88w=; b= bc9Cf8dJQKCvcRvzxPEiiWzB3JMdDRPF+gkaR4GLQG2BpBtKwg9WCEFHsOWeTgM/ HUD7Ye5F7iDUpTzNWyoAcmpBYo8d46kjVPbw0arkMHM9Sw6+HQlMSzS4RZZ4kewA v8aT4UxulaSts2+SbshrqDIcfBmgw8B+0QEE2XpHaYlMtN/XYo7KXA2sYlwUcpbR UplzYdiU71AD97gPJMSwRt2L17cEacHjHaYeArCX6i91HfuEKe9T7MgYoZfa7Kf3 tEx3BEHFFzi3aS4QcM0Liw1aQjTCgZDGWYd/4sirmR1HQPJjz5pMSor0HU+wOmww iyMswnVm4mvckSJ95SnDFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704850896; x= 1704937296; bh=htQ99Hi7jMOSyaX2foZsrSyd9F0xaBR2QYZjg5jp88w=; b=B 6W4ii1Ww5S93cIwElmkOXNdr5V6llRQQYQbR6nX4UyKO+XGWfIn51M25A14p0GdL ZN89RqHjAY2nPW0/mPIlfl/S182sjUupmK4jBu3YiFvxS77afSG8vlZcRa00+d8k Xu/AbFDBkPfUhSoux+3jjYuj3oq/N4otH8WkQa5O3SuaoaAW072bjNXL865RYUOK vsFpzBUUefHo34aAE9mPMpoIG5MTg/49L2IbJUZP0d400BWfJTTrm27xr6yxRoGX No3Wj7f2r9N5JxyRgdYZI4UKEhJZ78b9CKJ7dwC6JNGNxhSwosXf/OlocM/8ypdz h6mrBAHxZIiQpAhGFUj1g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeitddgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jan 2024 20:41:34 -0500 (EST) Message-ID: Date: Wed, 10 Jan 2024 03:41:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 09/01/2024 05:55, Stefan Monnier wrote: >> But for this to be useful to determine the language >> of a major mode via reverse lookup, > Define "the language". > > The mapping from "language" to major mode can't be always reversible, so > `major-mode-remap-alist` works to map "language" to "major-mode" but not > the other way. But that's the point: to be able to find 'javascript' from both 'js-mode' and 'js2-mode'. Or 'ruby' from 'ruby-mode' and 'ruby-ts-mode'. major-mode-remap-alist could have several entries for the same language: 'assoc' will pick the highest priority (first) one, but 'rassoc' would be able to take advantage of every entry. > The current bug-report*is* about "finding the language" but the code > that needs that info luckily doesn't need "the language" it just needs > to know "does the current buffer contain language FOO", which is an > easier problem, which I propose to solve with `derived-mode-p`, since > that's what we've been using all these years. TBF, I don't quite like the "subtleness" of this solution. The inheritance hierarchy of the modes is an implicit thing, and the fact that js-mode-hook would run in js-ts-mode in Emacs 30 but not in Emacs 29 would likely trip over a lot of people. Especially those who read recipes on the Internet. Also, "what language is this" does happen to be a meaningful question. Eglot's example aside, we can have other tools, databases, etc. And what about the idea of TS modes becoming the "main" modes sometime, far in the future, if tree-sitter stays around long enough? At least for some languages, I mean. If the name of the "original" major mode stays synonymous with the file type, how do we migrate away from them? Create obsolete alias? Rename js-ts-mode to js-mode someday? Finally, if we did have "languages" as an entity, we could have some UI for the user to choose the mode for a language - something like Debian's 'update-alternatives'. And it would also serve to list the supported languages, I guess. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 09 20:59:42 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 01:59:42 +0000 Received: from localhost ([127.0.0.1]:41436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNsc-0005rn-DA for submit@debbugs.gnu.org; Tue, 09 Jan 2024 20:59:42 -0500 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:54349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNNsZ-0005rW-EI for 68246@debbugs.gnu.org; Tue, 09 Jan 2024 20:59:40 -0500 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2cd1232a2c7so42505451fa.0 for <68246@debbugs.gnu.org>; Tue, 09 Jan 2024 17:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704851966; x=1705456766; 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=OqrfkSPpxXY4VRp2BHcIeCXWWPRu9AHcnFrjdGhDmn4=; b=FSUagCjuGN995Vq3Cm/7j8vAJYhKN38OpXCk0+jFXHs5D5BqY+BY6dxcNOPEHkKL+9 njXAXKbILbkdBjo9lH+y365hMYi1yqw6hRa/JhDcLFI/uOi/6+hytt3soJRXrUyFLQyj FXdzjbiW3Wqp6gt6Hny7adTrZwUkkNcp1p7WHRQ0I6yjpLoj/JCDVyI2HtIb0RwMNQ/B 1tDCCe5GoGQ27zKa6qysrH8/NNlOQv3Beg/60Z1SsTyuOVp7LPRTBtZvCBQjGRnKKH7G QzLa3AddIPmNODYOd2vtDCnuiLR+XFw67RLuLfELioyv2+MbQ3IkYz6GSZUQ5KkA1Cjy ocTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704851966; x=1705456766; 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=OqrfkSPpxXY4VRp2BHcIeCXWWPRu9AHcnFrjdGhDmn4=; b=MYGcUfcmFap/sQxd5BGQeCFF/VV+qJOLHtCgZT1hbFmjIHkhDnycg8E/l30EsRbcc9 jahjy3vdvdjSNqHerU0FcLZ8MSN4tSIEtn7VN3FdjhBN85j7HIf4xUU3oFEarFuudtz6 qpl1Z6EHk5q7xnBJu3PF0DjJ+oMVDOwKOnOhVGZ3WX85H+sxY0ZJu4bO6S67BALZYlyv CQ6zcSEQtVRr3JlY96PfGo7FGoKSa9jJgvcG2Qo+eAC6KkVp0ssgPhtWu3RvZTjgVfkz V70a2ELu9FBBqteyryW68rrDhG6i+22L2iDmMJ8r0j6/1z9sSqDCn9xHc2FOCPTMwdJb RGyg== X-Gm-Message-State: AOJu0YzV1PBzDZY3mOXhMzvoPHx9XjDcI58T94thYKzCN7JfAZeBkbMH u/dZ/7D3LgE0uMm65gEjKE3xAkTMxs8myAdc6Pc= X-Google-Smtp-Source: AGHT+IE/OilYRb+rPMNJjC47jJ2j8R8b2VDVNKNQAk1iWvUkAKrQozuEc4kpTy0wplkddf4vBcSkXWalHqOMrWq4Ruw= X-Received: by 2002:a2e:a17a:0:b0:2cc:a596:836c with SMTP id u26-20020a2ea17a000000b002cca596836cmr123192ljl.48.1704851965946; Tue, 09 Jan 2024 17:59:25 -0800 (PST) MIME-Version: 1.0 References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 10 Jan 2024 01:59:12 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jan 10, 2024 at 1:16=E2=80=AFAM Dmitry Gutov wro= te: > > If I could reliably write `get-language-for-mode`, this is much closer = to > > what they are really after: > > > > (ocaml "ocamllsp") > > (reason "ocamllsp") > > In the end, this could be a reliable solution without fully committing > that our language identifiers are fully synced to VS Code/LSP. Yes, we needn't commit, though no reason to needlessly deviate from that list either. Note that the full list in the LSP spec isn't very long or complete. It's just a "recommendation". As I understand, it's rather servers themselves (particularly the ones who support more than one language, like typescript-language-server, ocamllsp, and others) who make this decision. So I guess the full list is the union of all supported identifiers , and there might be one or two conflicts there, but I would suspect not a lot. > Overrides would still be needed, but it could help shorten the list. Yes, I think I can realistically support this: (("ocaml" "reason") "ocamllsp") Note the strings in the car becasue symbols already mean major modes. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 01:25:13 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 06:25:13 +0000 Received: from localhost ([127.0.0.1]:41604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNS1Z-0001ES-Db for submit@debbugs.gnu.org; Wed, 10 Jan 2024 01:25:13 -0500 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:60510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNS1X-0001EB-Fd for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 01:25:12 -0500 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-55745901085so4686064a12.0 for <68246@debbugs.gnu.org>; Tue, 09 Jan 2024 22:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704867897; x=1705472697; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=j5iI09/l5MXMtLEEkzU4ObF1okRiBMIrRidsUcKzdHw=; b=fL3IXdORutvcbvHTE0Ekc81yAgQbnmqpPZ7hPojUOJ+T0EegGjOwQskqAWJ+5Tl5WW AkVaVRNwwSG5983iFoJdg007ovMb/WgmyGVDRCUvxbV7RnFnQz0BJvD1ghuU7afFxYCT VVFDDmWTtjnPmrPcPBCn9MfCnhWk/cHntPBw4w+BqcbVkQG30xXUf8aONNCN6VsTerim IvGz65pAL2VxUoeUZjryt6ncbljrfYMn+F5Bjc3LghlDK5nln9Hr0wcAmZ/kuzdAusIX 1hxZjUz+saK3977d6wUZB6uFo+Kwy7rOoKFwKGkquJFjAfJx1cPLCLEOcysaq64obIsS VthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704867897; x=1705472697; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=j5iI09/l5MXMtLEEkzU4ObF1okRiBMIrRidsUcKzdHw=; b=O7F4Yf+dAr1MkfxsWHHrFKYp7hltsW5YhcldySdCKDJZ/CtKawXhiaTO7FPQ9l1dQC W04NiWICqJjO+ygSRhw8pbZEVJcxt2ieGDykW8aSLcSeTpde3zvKpecv+NXxvlc4gj0i geXxflmkmWEI5B3qr1RuAe4i8Kk34wyJhLauHEL5gBemK9/iPRIs5C5IxH9UQdBpxKVH EkJpmLNtjC74RUHQV2MI3UiIuVGpO0weZ3fk0Vm9jnKYHBhWiC8g7c0Fix0NgTp0LaVY fRKzQQHftBuz1mCbfJdpkM0dtMNHXL/og+n2JlDfway6CNJweIPI1Jx0CWbkZLx9JMk1 xZXw== X-Gm-Message-State: AOJu0YzaE5NoJO+naCzH6lcPkkxrkRwggiBlV8gM7Y36QO3E+/TNFBPm JziYUMxTlYqYDFWCxPsnmgv0qxZ/o3ywQmJp/gM= X-Google-Smtp-Source: AGHT+IFz2NK2FpxgckqnS7yvLp+euE+++51h7zP2PgBkR97jBWnSUsQA6aeJXK1tZK56Y7RztnYN8lIlCHEZ9Oh/s9I= X-Received: by 2002:a50:96c1:0:b0:557:d5c1:a4ae with SMTP id z1-20020a5096c1000000b00557d5c1a4aemr112487eda.47.1704867897054; Tue, 09 Jan 2024 22:24:57 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Jan 2024 22:24:56 -0800 From: Stefan Kangas In-Reply-To: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> MIME-Version: 1.0 Date: Tue, 9 Jan 2024 22:24:56 -0800 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov , Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: >> The current bug-report*is* about "finding the language" but the code >> that needs that info luckily doesn't need "the language" it just needs >> to know "does the current buffer contain language FOO", which is an >> easier problem, which I propose to solve with `derived-mode-p`, since >> that's what we've been using all these years. I can see the logic in that, however recently the situation has changed such that many major modes will exist both in standard and treesitter variants. If there was ever a good time to take a step back and consider doing something differently, this would be it, I think. > TBF, I don't quite like the "subtleness" of this solution. The > inheritance hierarchy of the modes is an implicit thing, and the fact > that js-mode-hook would run in js-ts-mode in Emacs 30 but not in Emacs > 29 would likely trip over a lot of people. Especially those who read > recipes on the Internet. I also misunderstood this at first: the major mode hooks would not be run in Stefan M's proposal. Perhaps the fact that two of us have had the same misunderstanding tells us something about the complexity of that solution. > Also, "what language is this" does happen to be a meaningful question. > Eglot's example aside, we can have other tools, databases, etc. I can't speak for Stefan M but AFAIU he agrees that "which language corresponds to this mode" is something we want to answer. He just proposes using the taxonomy we already have for this, instead of adding a new one. 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. > Finally, if we did have "languages" as an entity, we could have some UI > for the user to choose the mode for a language - something like Debian's > 'update-alternatives'. And it would also serve to list the supported > languages, I guess. This is a good point. Also to install extensions for those languages. Or we could use it to implement the VSCode-like prompt "hey this seems to be language , do you want to install support for it?". At the same time, I don't think anything technically stops us from using `foo-mode' for this either. We would just have to be more careful in how we present it to users, to avoid any confusion. FWIW, I tend to slightly prefer the solution proposed by Jo=C3=A3o, since i= t makes things simpler and less confusing in some ways: (derived-mode-p 'foo-mode) does what you expect, and in every mode where that sexp evaluates to t, `foo-mode-hook' is also being run. It also has less potential for breakage, since only new stuff will use it. At the same time, I don't want to just discard the argument that simply sticking with what we have is even simpler. It obviously is in some ways. But I'm not convinced that this level of simplicity doesn't have a cost that rears its head in the form of complexity elsewhere. 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 ca= n call it that) vs "clean taxonomy". From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 10:51:59 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 15:51:59 +0000 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 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 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) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 10 Jan 2024 15:51:38 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Kangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Monnier , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 11:05:01 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 16:05:02 +0000 Received: from localhost ([127.0.0.1]:42551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNb4f-0006ST-EO for submit@debbugs.gnu.org; Wed, 10 Jan 2024 11:05:01 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNb4d-0006S9-TJ for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 11:05:00 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3BE3B10007D; Wed, 10 Jan 2024 11:04:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704902694; bh=eVorPMOp9gbmkABw2Ns6/rvTumWQxi16/pse6KJDNAk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I3BrQKQHM+FG59dz8kGOuYdp81xAYBJsUicDkZ9DtWLQQ38dPKz83lmcfz0J9YGYI B2DOylLwoflr6IW0iM5kUGhV6O5uPt6FkvwwvYba+2DKBKaEofDtMbWEOazyXBuuiQ B1WQtj6Lt2DK78QwePSu4zfB/qGGqWuyHMw6fXqW/sa9FTyVzMikHVssyU0kXAUoDs Yq/GCSenYRFsdlgnji4UC4XTElhvJZ7zxffEBMsL0K45eBHBDy15Rld3Idy0dofsFB xhIY2oaHz/uTk1IhjsmNhxcKJtAHjIYGvvsL8LZ1txb6s4cXeaM7GQn8WzFX3Flekc DAXx3u7fOyOgQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4D0B810001D; Wed, 10 Jan 2024 11:04:54 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 39639120235; Wed, 10 Jan 2024 11:04:54 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 9 Jan 2024 11:05:55 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Wed, 10 Jan 2024 11:04:00 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.437 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I must be out of luck, because Eglot does need "the language" to send > as the LSP "languageID" to the server. No quite "the language": it needs "the language as defined by LSP (or by its LSP server)". FWIW, I view centralized mode-indexed databases like `eglot-server-programs` generally as a "youth diseases": as a package matures this gets replaced by buffer-local vars set by the respective major modes. Reminds me that maybe we should better label our major modes, so as to distinguish a few different categories: - `prog-mode` and `fundamental-mode`: "virtual modes" used for the sole purpose of sharing code between their children. They don't corresponding to any particular content type. - `tuareg-mode`, `cperl-mode`, `foo-ts-mode`: "alternate modes". This way, it might be easier to heuristically compute "the language" by removing "-mode" from the non-"alternate", non-"virtual" mode(s) in `derived-mode-all-parents`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 11:13:00 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 16:13:00 +0000 Received: from localhost ([127.0.0.1]:42560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNbCN-0006h9-Sk for submit@debbugs.gnu.org; Wed, 10 Jan 2024 11:13:00 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNbCM-0006gv-Ak for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 11:12:58 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 400FF442CC8; Wed, 10 Jan 2024 11:12:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704903172; bh=xaj0IciQ4eP39zG5Sld8CW2PnLbfF8wEtzrs9D6Wk6M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jxfNs9GFgIxMYr2TRdQgXljwkCb+Y40nj7O+ETg0G5oYd4AHjFQ6USb/C77oqGbCr zQL6aptXa/0FSuOQXkwurWuw51VtBWY0cBmKZfDExP1oO22bLttLXvuEJjmCf550LT pjSPvCdvJAtD98GNv5ZfwvQy1jrcYuawpuNkEA+O8ZlE40J6N7iXyNfxHPjRrq2ijZ oNJ36OULBjdM1JBTQlMUhQrE7XFaGvaRj8K0W1XOpzKYIwHuppVhzJo+L6FiNBuTIj VzTM1AvJ7eu4+/J9cK6xmLDJOW22xk/Oay6pm7NceW5THoDC2/ghHydGMSvMNa7Bid kSrSSL17eoc4A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A6933442D88; Wed, 10 Jan 2024 11:12:52 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 942B3120A6F; Wed, 10 Jan 2024 11:12:52 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <5ee1a261-0d5d-4567-b98a-5f8100b55b0c@gutov.dev> (Dmitry Gutov's message of "Wed, 10 Jan 2024 03:18:47 +0200") Message-ID: References: <831qavvcbo.fsf@gnu.org> <5ee1a261-0d5d-4567-b98a-5f8100b55b0c@gutov.dev> Date: Wed, 10 Jan 2024 11:11:58 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.137 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > That's very nice and concise, but it still leaves the issue of users being > able to use a common hook for a family of major modes (for the same > language). So I guess some inheritance-based solution is needed? We have `define-derived-mode` for that. And even those major modes which don't want to inherit via `define-derived-mode` can `run-mode-hooks` any additional hook they like. Doing it when a mode is defined is easy and "safe". Changing it after the fact risks introducing breakage (just like my `derived-mode-add-parents` does) where the code run via the hook depends on specific details of the original mode which aren't available in the "pseudo-derived" mode. For this reason my patch only proposes the use of `derived-mode-add-parents` since that's the part where a clear need has been found. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 12:02:29 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 17:02:29 +0000 Received: from localhost ([127.0.0.1]:42679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNbyG-0001l0-OP for submit@debbugs.gnu.org; Wed, 10 Jan 2024 12:02:29 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:57229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNbyF-0001km-Cr for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 12:02:27 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5B6493200AE8; Wed, 10 Jan 2024 12:02:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 10 Jan 2024 12:02:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704906141; x=1704992541; bh=axTEXa3WJEwDHdh9VUZIKh49OrC3aUxHov5hK0gTH6k=; b= n64PvqqFBbd3MyalpwIsQIRx0L7qMrPU7H2AR/eYB8qWXAGm7rRN4hgpztIwl7+j AtP1DUrIA3ATR2w2J0pCvVAvnRBNriX30L1BsiWtz9QcNuojGsw2U229OyiGcmlk 4XMtYa0L2oJNwrMzriyMiAwdrD/VYIFmTp7s733PPm0pgji+XijQavd/cFNNzx9Z /6BDMvxu6vI5NKt9FI4Y9XyQylS/ZF3kenwgdYm4rBUcrs/2PheEsRxk9pXkFMAI idJ9ydtiW2wIC1Pd80a6K1p/tVlSTZK8fqlpJbg/PSU9JksFlOLc9D9p705ODjnv jydbIA6twRgdysTwOVHrTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704906141; x= 1704992541; bh=axTEXa3WJEwDHdh9VUZIKh49OrC3aUxHov5hK0gTH6k=; b=x hOaF1iEUwuYf65FBpxo+pEt6xFuCt1uhxj0eoBsbsBO/a66gtNYMkXzUGQh8kbEk SUq2c0QYIUoaL59wGUwX5Ixu8zj1ehpstq6tzDOWtkN6FWllsVR3zXTiXUa5pD9t IeFz3FazGdEiGJOJx2/jNZAJ1O+WgegFajfM7pfZSvQJ3HiHhoRL7BA4UbYdpkIV 3BNB5IV1s/v3OwV0XJuAjLnOCYhMgvZd/Vk1jQoi1VuC0ji0Le0lg7mAzZb6MUK8 nIHxHbOtWxW1dQ/xl5k1x6rbd6L6J8xa75I6TDUPjhZ+xLJrK114SgfWes1/CAcg OlzG9SESNdkDVl2gCoS2g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeiuddgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Jan 2024 12:02:20 -0500 (EST) Message-ID: <1890454b-7562-4f29-9b27-53df52402cf6@gutov.dev> Date: Wed, 10 Jan 2024 19:02:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 10/01/2024 18:04, Stefan Monnier wrote: > FWIW, I view centralized mode-indexed databases like > `eglot-server-programs` generally as a "youth diseases": as a package > matures this gets replaced by buffer-local vars set by the respective > major modes. One of the proposed approaches was indeed for major modes to label themselves in the definition as associated with a particular language. (Or maybe languages, plural? Do we want that? I suppose that might happen.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 12:30:40 2024 Received: (at control) by debbugs.gnu.org; 10 Jan 2024 17:30:40 +0000 Received: from localhost ([127.0.0.1]:42759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNcPX-0006ea-PU for submit@debbugs.gnu.org; Wed, 10 Jan 2024 12:30:40 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:46522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNcPV-0006R7-Eb for control@debbugs.gnu.org; Wed, 10 Jan 2024 12:30:37 -0500 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2ccb923c4d2so47818741fa.1 for ; Wed, 10 Jan 2024 09:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704907833; x=1705512633; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=fWNWdEEEu7II7FuTB2ybPo4UNGnK3MutMSveKtI5L18=; b=OvjyI66E286jzhrdzjaO295wv7nskQTSLDyTUqH3/YKRcfzJtQS8Q75tUZtznD+PRY 1J+WoWpTzb4TQZJL7hYXxljqVoI2qezKWDDMTAKXVvdPqpAh/f38wUy1MgfKQHj5m12O oVFq1Aqq4jiApynV57LiBnTqYHx6TwcFZoBkopOoryWiNHlFDyltS8kvmgQxkiHmd870 ZFYE2DF2oMpgEBuQcRJTeNo/U/wuZgL+PpNK+AHp9MoSdSj+biXm/ieXqQybsbZWPhox N2gaF1sfINyI/dPbGJCmq7e79UiIVgTEVZCljmHmNZzTt3X+sgIDX91uSYoYW7Iw74Nw Slig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704907833; x=1705512633; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fWNWdEEEu7II7FuTB2ybPo4UNGnK3MutMSveKtI5L18=; b=RXUhW4l5jGfq9CESJ7zoVdaW3jqAyHYvbDLC9wqycKQDHqKiWYEqFpEAgwLPRHmYRk Ba8uEFlOnHV4O/VRbvHFT1ef0+GwFzUgjMYW5q0ZTDBa4C9/sOGbnqScL79l3OUoY/1x MoEECZT4f5viFlbXThwoaEggskxYgUnHxFcqbc8Gw2NqhuoSfa2aepyIj3r8mWHtq07p GHGtQp0UCsKu0jB4ZWnl149iU4E9DGcBqAlmQzyEx+bS4qLVFShdJ5SLg8YTMSr0ChD8 k6tu8Zx6HeeO/s/xsaLfGCQr25XmXIHgKeNv9ZIUU2c5mKCGKmz0UVLXVmERON0CSZnp ULSA== X-Gm-Message-State: AOJu0Yzv2Hy9U+VO5shxsuttAScCDUxgH5mMoQdp4mBuedoRElqjLXqW 58FmzpVSVxqyWPNmgTEuuH0FWUrJewBBNEsl9UE3ty92DtyaWA== X-Google-Smtp-Source: AGHT+IFay++NXpWBeCNJpCh41aHfBl5C8qgeIp3Yx80SjjmjLi0zZzc0FsbRZa0tveg+MZc9o1d68BAJ8i+4txQs2XQ= X-Received: by 2002:a05:651c:10a5:b0:2cd:1efa:d2a1 with SMTP id k5-20020a05651c10a500b002cd1efad2a1mr448089ljn.29.1704907832684; Wed, 10 Jan 2024 09:30:32 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2024 09:30:32 -0800 From: Stefan Kangas MIME-Version: 1.0 Date: Wed, 10 Jan 2024 09:30:32 -0800 Message-ID: Subject: control message for bug #68246 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 68246 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 12:32:09 2024 Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 17:32:10 +0000 Received: from localhost ([127.0.0.1]:42787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNcQz-0007sj-KJ for submit@debbugs.gnu.org; Wed, 10 Jan 2024 12:32:09 -0500 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:57663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNcQx-0007s8-MW for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 12:32:08 -0500 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cd1ca52f31so49814621fa.3 for <68246@debbugs.gnu.org>; Wed, 10 Jan 2024 09:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704907923; x=1705512723; 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=NUmsMR/9pqeDc9fNYGHTR84el3RIP03TjrFrbdHQtvQ=; b=BRlkTisDYho3TeIeBfx/WcZqDE9XBcB0MrUxarlSm0zhxGSnwwaNggCl25yb7ru8fr t8WppnR7XiLjDQnWex/ntiXqwWm5hXQTd1SNXvHO9JXppk4oyvfWyWULZ3CV2eishVhw 0N0kczFcOaasGT0MxMAzozOOthBBks5twzXxf3b7YdMZCN3kHLsp3h1GG8uTWIuhu8qr zBBUITcQVaY7Hnwb2BJON/EvV1470wkNC0afPJ+i/7FGQd5i3WyDAa/t1Z1hYpmeHqNv 5yi7KzwrlwPQYTZv1tInOYlKHMj1uihfNrq0eicfCKeesXjqnUDpvH02VxJfyXHKD1mH M/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704907923; x=1705512723; 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=NUmsMR/9pqeDc9fNYGHTR84el3RIP03TjrFrbdHQtvQ=; b=MVHc1RtZZ6WkHMcXnvIhhXyy+eNcKYXwxf7KucFlGw+euT7uxJxo+eO1RmulaH5Dcs xaFVOiPX211XPN7+LUeEctpSSMKNDYaO9lPLuj+HFVWQGZPVb74iWFrYq3E6a/PYurgO uh5JMw/UalGn6uRi/Ogw97899EuHMBFUUZ5fDhpaXvRJTs25YWR/YdofHaq9a1rxzqtF SJwDkGqvqehwZ/gcHtnAaC4+BESVZwjzkZqq1uFN83c60uWyOl3KEW5ydbFUiU++sLct WilvHqi3KKPKRZsAbzZ+W7xBERYrm0SfeU9LW1HFxsG513WY93HPvF/2B448tniS6G3g 000Q== X-Gm-Message-State: AOJu0YzmnT6gxRwqboWWI0lDlZSqdSVOGJ5DNreJ/4h/3XVYmbpQ9xzE SYFFT77ILoElwvABs5jXTj7Sjss5/9ftiz8cO6Y= X-Google-Smtp-Source: AGHT+IFeAHeuXVQntJJ1RP94p1U2lj3uwmHx2xdnvq/SpEEJP5OyC+8ryDms/duQsDleiRrLhIpRuSzNdAjlsUvtBHQ= X-Received: by 2002:a2e:8895:0:b0:2cd:5c96:46f4 with SMTP id k21-20020a2e8895000000b002cd5c9646f4mr769650lji.35.1704907922517; Wed, 10 Jan 2024 09:32:02 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 10 Jan 2024 17:31:50 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jan 10, 2024 at 4:04=E2=80=AFPM Stefan Monnier wrote: > > > I must be out of luck, because Eglot does need "the language" to send > > as the LSP "languageID" to the server. > > No quite "the language": it needs "the language as defined by LSP (or by > its LSP server)". As there is almost always a 100% match, I'm happy to have eglot-emacs-language-to-lsp-language with very few exceptions. > FWIW, I view centralized mode-indexed databases like > `eglot-server-programs` generally as a "youth diseases": as a package > matures this gets replaced by buffer-local vars Me too. But it's orthogonal to the "needs to know the language" problem. > set by the respective major modes. ...or directory-locals, or whatever hook/interface the user prefers. So I'd phrase that as "suggested by the major-mode". And this major mode doesn't have to be concrete either. The foo-base-mode, parent of old-style foo-mode and new-style foo-ts-mode is an excellent place to suggest that the LSP server is for "foo" is "fools". Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 22:42:03 2024 Received: (at 68246) by debbugs.gnu.org; 11 Jan 2024 03:42:03 +0000 Received: from localhost ([127.0.0.1]:43648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNlxC-00050w-K8 for submit@debbugs.gnu.org; Wed, 10 Jan 2024 22:42:03 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:41225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNlxA-00050L-6M for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 22:42:00 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 6F5B63200A24; Wed, 10 Jan 2024 22:41:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 10 Jan 2024 22:41:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704944513; x=1705030913; bh=fI0mHn6TA5ahE69WSqzlOaRcYvwnH5P7NUdHzdkJxQI=; b= g/Vgv80s6anh37/mx/vjmjG+C97DG0GCMvUbpzQ0Tu33QdcWKU6YaObnZh2W9cL2 YH4UYbDV2sE4s8BCwfnmNoDhjnvkvdkbgN18paJJdqr6tdN92xUOIuzOAhuqhQoS Qdc2X4LMc20FYnU/nIgkiHWmTu0zoJ4TPDJo9EOC7PZH2fkXiAyd86r39VMaERmY oDcjaey1IeEtWw2XyNoHKfdY3y94XLI1jdMHj5/f+num/1WPPYAbbKtOCHh+fVxy UFM5mZ7NPi/wmAuS2BTNcpRdeJYovi5kXwIUSFoP9OtqpOx6FX0ewz8vkVwQIE3H YMPYfAHt35jpgbl70dkOtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704944513; x= 1705030913; bh=fI0mHn6TA5ahE69WSqzlOaRcYvwnH5P7NUdHzdkJxQI=; b=g 51S3LmJf88FBXbQQ8ycN+fCPYW/ta1F7MxDvP7SwNO7S5LaQXt4n/U3g6cjiOqt2 gu/rOCKCScdjRJjRsNK5ypUSm+uRlVom5ZsLuyHxbB9ygPYXBoqa7sh1BdrHN5cY eTbRMXcvwKdCtvghTey0GMS2e9k1h7OovTDC/nlNOI0b5DJmvrZRukOlz8sQ3Bk+ 13DPAeNKqcsaXzp50SqRmbwtPXZwwKwuJ2maN4c/UXu+qohR20CF6RG9dLNHkt8Z R/d5Djbi1sr884xs5f4k3gp3tO4EhDLGaw1DC+3jYZrmcvOZTcC4VjZz8QXy/YY8 r+9rpsAeWSmopn/uSF2/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeivddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Jan 2024 22:41:51 -0500 (EST) Message-ID: <1cdf0694-5081-4ff0-9460-908dfc9d8abf@gutov.dev> Date: Thu, 11 Jan 2024 05:41:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier References: <5ee1a261-0d5d-4567-b98a-5f8100b55b0c@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 10/01/2024 18:11, Stefan Monnier wrote: >> That's very nice and concise, but it still leaves the issue of users being >> able to use a common hook for a family of major modes (for the same >> language). So I guess some inheritance-based solution is needed? > We have `define-derived-mode` for that. > And even those major modes which don't want to inherit via > `define-derived-mode` can `run-mode-hooks` any additional hook they like. Hmm, I guess I figured that having a common hook is the more pressing issue, since the users would want to try the different available modes, and they don't always know where to put their settings - on js-mode-hook, or js-ts-mode-hook, or that there is the base mode that can be used (which is the case not for every ts mode). Whereas the packages that use derived-mode-p are most likely less numerous than our total set of users who employ customizations in hooks, and thus can more easily bear the inconvenience of having to mention both js-ts-mode and js-mode, for example. > Doing it when a mode is defined is easy and "safe". Indeed, 'run-mode-hooks' is a workable approach, but if we decided on a common hook name to use (e.g. if it used the format like xyz-language-mode-hook) that might relieve the situation somewhat. > Changing it after the fact risks introducing breakage (just like my > `derived-mode-add-parents` does) where the code run via the hook depends > on specific details of the original mode which aren't available in the > "pseudo-derived" mode. Sure. A new hook shouldn't have such a problem, though. > For this reason my patch only proposes the use of > `derived-mode-add-parents` since that's the part where a clear need has > been found. That makes sense. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 10 22:50:08 2024 Received: (at 68246) by debbugs.gnu.org; 11 Jan 2024 03:50:08 +0000 Received: from localhost ([127.0.0.1]:43660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNm52-0007yH-3w for submit@debbugs.gnu.org; Wed, 10 Jan 2024 22:50:08 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:45153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNm4z-0007xc-RQ for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 22:50:06 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 70A843200AB9; Wed, 10 Jan 2024 22:50:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 10 Jan 2024 22:50:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704944999; x=1705031399; bh=wHoH2AfIoQkA47WlvMkJlSWDJlQfiw7zxyjatfeof1U=; b= KGFxYD0NPKXxxnngberh0B+oE13pApgS5qe7tshKX9NpLn4J3aKgz+4EHEb8VIO8 7hzlMYZAsN3oMFOeiiA1J3mPAGbPFuAweZe3Sclrhuwgwd/KbHJtCkDa4plHwery 3sQ7vfjWbn53G/gFtDgq8rExqvdTUPXgHo473z7FVXCPrrscPZTG7lV9U87zT7tv Jdlu0bUWJ6aAlG0lUqHF0ScfpMrb7OF1sKo/1irML/LCZ903h1Fh+bVPGE3du0O4 XMfpltae8ZAJrtgWaHWX2HrF2p/XYmeX2KKFJuWDRFPGJl7kGkgbi1sOE7NakTHz JvaZ8u/werUQcpHo4vQ7Hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704944999; x= 1705031399; bh=wHoH2AfIoQkA47WlvMkJlSWDJlQfiw7zxyjatfeof1U=; b=3 hkvGZkXspnP02iX9+ZLxjd67AgkqdyRn0L1BGMLFdmXCiWtcCPrPaLGLz8oXoMQz N/tjlI8GI/79g+yC0Hj9vw7JHs9VS0hfpZn40/IbWkYn4ltOLxzI6DOY9j1zgjqd ZczHPjo6Go0MX1F4htmHjoDpujulh9v25oyVtdkyNAzFhwsS7fsJpum4SkXpbuJp q0jV/BzEstvHgojutCAsLX/XJMMHQ4A9TI+2NEbVdi8HYSzckQb6eragvThLyeIe f4QkcdSV8sPxY9o5V/IAoFDHtYTxixqMDurFCq/KleoT3MnEMxeu6YPBQCAeDkh5 zLeam2AjtQQiZi0IKOJEA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeivddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Jan 2024 22:49:58 -0500 (EST) Message-ID: Date: Thu, 11 Jan 2024 05:49:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Kangas , Stefan Monnier References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 10/01/2024 08:24, Stefan Kangas wrote: >> Also, "what language is this" does happen to be a meaningful question. >> Eglot's example aside, we can have other tools, databases, etc. > I can't speak for Stefan M but AFAIU he agrees that "which language > corresponds to this mode" is something we want to answer. He just > proposes using the taxonomy we already have for this, instead of adding > a new one. > > I.e. the difference is: > > (derived-mode-p 'foo-mode) vs (language-for-mode-p 'foo) > Monnier Távora > > 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. The predicate is available, but implementing the function that decides on the current buffer's language is harder. Because js-mode derives from prog-mode as well. You can't really take the current major mode, or an ancestor, slash away "[ts-]-mode", and say "this is the name of the language", because it's hard to decide which of them to use. >> Finally, if we did have "languages" as an entity, we could have some UI >> for the user to choose the mode for a language - something like Debian's >> 'update-alternatives'. And it would also serve to list the supported >> languages, I guess. > This is a good point. Also to install extensions for those languages. > Or we could use it to implement the VSCode-like prompt "hey this seems > to be language , do you want to install support for it?". Yup. Or - as long as the language name is decidable, allow the user to just enable, say, fundamental-mode, call 'M-x eglot' and have it provide both syntax highlighting and indentation support through LSP. This might not always be practical (and syntax highlighting is not implemented in Eglot yet), but it seems like an interesting possibility. Especially in those rare and purely hypothetical cases when an LSP server for a language exists, but there is no Emacs major mode yet. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 13 21:19:45 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 02:19:45 +0000 Received: from localhost ([127.0.0.1]:41425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOq6D-0005Sl-BL for submit@debbugs.gnu.org; Sat, 13 Jan 2024 21:19:45 -0500 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]:47585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOq6A-0005SV-W9 for 68246@debbugs.gnu.org; Sat, 13 Jan 2024 21:19:44 -0500 Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-28db4f860easo2833008a91.3 for <68246@debbugs.gnu.org>; Sat, 13 Jan 2024 18:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705198778; x=1705803578; darn=debbugs.gnu.org; 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=WFmlNV9ObhC2xbwmmKAVmw2Y9WqzN4m/Aut7+EBIK+E=; b=cqALS46PkluRogkWpCjEKGcuAyr1EXv8OPEu7jT7lqPGCkNpAj/uvMLtvB0Jftjtba qeXBk2o7HfbeW5kqm+GCLhemL4rDGvPpxDZjSYgN5qjltCtPuKwIR3Lht1mo0U8zPMDK pzrXKABLEFMNhZIumdUD4wujKLhrXbdocr6x3d2Z51yUcilVCO/unTJzbEDRCVQzmwOb z7YhzY8bNTXn5g1Hg38wXAjn8uKZbcdkujEUk+ELBfsciorZAf3N165aVz016kEtRlxN Op4Z+SrMS/EdAA4Hb+R+ICoXBAofERF8uTRDNjdKraJrUYOF8ZDRHaGKqeUOTBWVC8HQ EfKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705198778; x=1705803578; 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=WFmlNV9ObhC2xbwmmKAVmw2Y9WqzN4m/Aut7+EBIK+E=; b=cnZg5FYkqGUMkOZq0qN94UXsrPYjZo8g/PsoLoijUY7yVvIICXg+gl3fB8YvU1ur8t PzXAeWrlEAJ3ycanrssiD54DsOn2HGuqycYB1XpXY9a6aokeUF64bXwFgXq81fjzOQi2 hy4CPU7saDEzRGtuKb8ZxYPv4kY689drMM25t2FuuhAxdXPmMAIuWbT0MOD63Gs1tePP Dr1jM/EDuaHdWUKciD41CMgv2g9PDWqHT2R9J/o0oJvwYmnjaheSg4Xsi+09h7ZrnPxr aR2tCPWPbnPZkridb6nBzbUJvIfYgEyxMXOshTcvHey4JNl6BxUSC/umMpWGJm8oijXs lw9g== X-Gm-Message-State: AOJu0YwWeFee2lUwzmwF6L3zorT5efHaDw8pJqMJKzp1vzof1GoJ3YQ3 JJJZTAVv8b8aJaNxMHvdjqs= X-Google-Smtp-Source: AGHT+IHQTDZ6xyJow4e2Yu9yEjTKpJX9IeXYmsiCnTx1grS1rWbzlyCKS4U9BxuMIQBRLUHIok8r6w== X-Received: by 2002:a17:902:cecb:b0:1d5:b7b2:c307 with SMTP id d11-20020a170902cecb00b001d5b7b2c307mr304376plg.54.1705198777961; Sat, 13 Jan 2024 18:19:37 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id g11-20020a170902c98b00b001d4c97a2adcsm5392294plc.108.2024.01.13.18.19.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jan 2024 18:19:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: <831qarrbjx.fsf@gnu.org> Date: Sat, 13 Jan 2024 18:19:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 8, 2024, at 9:15 AM, Eli Zaretskii wrote: >=20 >> From: Jo=C3=A3o T=C3=A1vora >> Date: Mon, 8 Jan 2024 14:45:31 +0000 >> Cc: monnier@iro.umontreal.ca, casouri@gmail.com, = 68246@debbugs.gnu.org >>=20 >> On Mon, Jan 8, 2024 at 1:14=E2=80=AFPM Eli Zaretskii = wrote: >>=20 >>>>> It attempts to abstract a trait that isn't abstract, by going in = the >>>>> opposite direction of that used for abstractions. >>>>=20 >>>> It's interesting how you state a simple get/set is a "leaky = abstraction", >>>> but then also not an abstraction at all. >>>=20 >>> It's "leaky" because it "leaks" the idea that it should be a >>> "language". >>=20 >> Oh right, of course. Who came with this "leaky" idea that there >> are programming languages are all? >=20 > For some reason, once any discussion with you got past some number of > messages, it always deteriorates into a stream of ad-hominem and > sarcastic nonsense. I'm outta here. I've never doubted the good intention of the participants in this = thread. You=E2=80=99ve all sacrificed much personal time for making = Emacs better. And I believed we can have efficient and friendly = discussions if everyone in this thread have enough time to go over each = other=E2=80=99s message very carefully and compose a detailed reply = that=E2=80=99s hard to misinterpret.=20 Alas, no one in this thread has the luxury of =E2=80=9Cenough time=E2=80=9D= (especially Eli, I=E2=80=99m already amazed that he can keep up with = all these discussions everywhere everyday). And we sometimes end up with = unfortunate situations like this. Now come back to the subject. What we can do now, it seems, is to apply = this on master and observe what breaks? Then Joao can either say =E2=80=9C= I told you=E2=80=9D or happily found out that this patch works ok. And = maybe we could also mention this change in emacs-devel, given the = potential impact of it. Yuan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 13 22:10:22 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 03:10:22 +0000 Received: from localhost ([127.0.0.1]:41441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOqtB-0006ME-Jx for submit@debbugs.gnu.org; Sat, 13 Jan 2024 22:10:21 -0500 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:55305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOqt9-0006Lx-8V for 68246@debbugs.gnu.org; Sat, 13 Jan 2024 22:10:19 -0500 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-336c9acec03so6331659f8f.2 for <68246@debbugs.gnu.org>; Sat, 13 Jan 2024 19:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705201813; x=1705806613; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BsfEikrwsIqrZkex3PIOCzEfEWwP6EJELeTv+D5rZDQ=; b=Dv1cIO6j4lYstwQ8s7Xn1BXiKp/s1krp16pizsrXps2WgshtPAiCbSBtw0GcZXMcJg 2iCT5ck8imp2FhLhIVCcSkplv0WULxqOqYLR7aKeyAZ2wxGUiEhTvsj7DZeVr7l+MCDR c8WJFrGIASL3V+18IVKQNwBC2ICrQj6pXwQP1qYEONhA+OCn6bsU7Yr5CphsgtD+8cMo ViZk0Z4dZXg2Hb6QsYpj8fk2SWKbg3XC66GCmn0jUTXFV2RzZh3Sa7zHmEkW8KEmOnD2 X7k0x8bLm0J4zHyf9wAElU7Fpaa7DLoEKljjum/YDbhHGp2T+Sa1fEO3bIONQ7aWNilm 1GlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705201813; x=1705806613; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BsfEikrwsIqrZkex3PIOCzEfEWwP6EJELeTv+D5rZDQ=; b=WYOhsLCmA1l+ush0V6pDPW2sE56/zVNWVZRRaZzs5NnDsJA72cxMmL32s/1EGNTsjd 0AVBXJwX1MGw1l9D2cq2J4C/GNwCKpjvmBBJXycbQVpSjB2BtAWBEJnY/utShVKO4nRj EfQoEo2OiJ/I8zXVNxphtCzzm8Xclah8zVuzG4sanh4KYCsWKIfD0gkkoeUs66QxLQSA T9D5PYgMiZX5OnJWFhTtZexOdr1ibx76YrLGumo0lIOH9V6HeLi06+NjavQ/2BOEDTn2 Wh53VThWxj4eGV795Tg3OLXMuOtFoiWKIK8H4ba0lP1LDBjAKxoN8+78jrZOlJ7dsT+C TqeQ== X-Gm-Message-State: AOJu0Yzjj0/sj0C6wq36CNR2UKpqhn1soTlV46eYm5HIRvOnzxyiU1iI 4AaYa4vrmGLswygf3pLlxmyJd69JU4k= X-Google-Smtp-Source: AGHT+IHQEtgBuw28OCWxBDqUWCqzpy/TpBYAFYKFApkzQRWLhIW0C4G04T55gZHGpZimzHleMzZOOw== X-Received: by 2002:a5d:6d43:0:b0:336:807b:ed62 with SMTP id k3-20020a5d6d43000000b00336807bed62mr1794520wri.60.1705201813184; Sat, 13 Jan 2024 19:10:13 -0800 (PST) Received: from krug (87-196-72-99.net.novis.pt. [87.196.72.99]) by smtp.gmail.com with ESMTPSA id h7-20020adff4c7000000b0033677aae2e2sm8039994wrp.107.2024.01.13.19.10.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jan 2024 19:10:12 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Yuan Fu Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Yuan Fu's message of "Sat, 13 Jan 2024 18:19:26 -0800") References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> Date: Sun, 14 Jan 2024 03:10:02 +0000 Message-ID: <87a5p84nlh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: > observe what breaks? Then Joao can either say =E2=80=9CI told you=E2=80= =9D or happily > found out that this patch works ok. Those are not the only two outcomes. It might work OK and not break anything [*]. However it is not easy to quantify confused users looking to understand the new meaning of things in dir-locals.el. Or users wondering why they need to set Eglot variables in both 'c++-mode-hook' and 'c++-ts-mode-hook' when all they see is 'c++-mode' in 'eglot-server-programs'. So it might not break, and even have some reasonalby solid theoretical backend beautifully enshrined in documentation. But is it the right thing? I think not. Unless I'm mistaken it's already proven to be confusing even to two seasoned Emacs hackers in this thread (and I'm not including myself). And it doesn't do much for two main problems that were presented at the base: Eglot and Yasnippet. I.e. Eglot still inescapably needs to report the language to the server and Yasnippet would be better and much simpler if it could organize snippets by languages instead of major modes. There are better alternatives to this patch: 1. The base modes, which are substantially _already_ in place. They follow the naming convention -base-mode. After giving more thought to your earlier objection about derived modes overriding variables, it doesn't make sense (I can elaborate if you want :-) ). 2. Explicitly associating some major modes with languages or file types. This doesn't seem hard and other further uses like suggesting modes or packages to a new user based on languages have been proposed. Nevertheless, I suspect that you want a solution to some real problem happening today Can you say in your own words what that problem is? As I explained, I don't have a good idea of the cases besides Eglot, Yasnippet and possibly/likely Lsp-mode. Jo=C3=A3o [*]: It's possible though. One way would be for a user to have added entries to 'eglot-server-programs' for non-TS 'foo-mode' specifically with 'add-to-list', a very common practice. Her later 'foo-ts-mode' entries would be shadowed. Unlikely, perhaps? But what about variables set in '.dir-locals.el' for 'foo-mode' and 'foo-ts-mode'? Suprising "magic" aside, it seems these settings will be merged (right?) in 'foo-ts-mode' buffers. But does this make sense every time? Even in our own dir-locals.el there are some settings for 'c-mode' (unrelated to cc-mode.el) that are not in the 'c-ts-mode' section, but after Stefan's patch it will be as if they were. I think it's unavoidable we'll catch some users off-guard and break things. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 13 23:00:32 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 04:00:32 +0000 Received: from localhost ([127.0.0.1]:41495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOrfj-0008Qq-St for submit@debbugs.gnu.org; Sat, 13 Jan 2024 23:00:32 -0500 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:57549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOrfh-0008Fd-MU for 68246@debbugs.gnu.org; Sat, 13 Jan 2024 23:00:30 -0500 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6ddf05b1922so2782857a34.2 for <68246@debbugs.gnu.org>; Sat, 13 Jan 2024 20:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705204825; x=1705809625; darn=debbugs.gnu.org; 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=vZSR36649lHvzAJhgw3KU/yAVY2pV7Orr/9VpGYrJvU=; b=cP27sD5eWqSSjFXJazsxQkuWS6gNWkvUlWLgNMJkqNJOalvxd7FfzEEV0LZMaPmfPF rTMKM/xLthPabH7r3/4qEiUv4FbLuA0F2iRtkgncdaH4lv4dVfApUNJ+IryZFRBDTNHA Z49G1UjHJj/zMvxk+KFbRIq4q87+vJr3zr+4tQ0j05I8QPZmwHS3V0/OvVYo6MftChfn ze/+40w/bMe/kJlk3l7tPBw1JL5lsKH7dZ9boVs58a1WEJDnZX71991MdnyqwVTb3/kk NX6LZpRKchCYtk+5JOquB5pRR0PD7ppbKM7ocxOLACtutcd3MtBpl9eHy7cPpwkhutaG X2xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705204825; x=1705809625; 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=vZSR36649lHvzAJhgw3KU/yAVY2pV7Orr/9VpGYrJvU=; b=bQjhBTaLlO+PaxiFUyAqw03p+IU/Jj+uSecHHfD3KrI63OtSSkO32//rFlcfAdcP8E 2IAO8exqnBTLS7CnEjMqeb/E2HFdwvMBvz/9J+pdL7DUZU+ESfvpkWuM3CcHidFxIzj1 +8bv+neXSj8orOzpooZ3uPCas9fj6n86S1infTRw/qQU0FxcT9XcDVhm6ldqjjFL1Xi6 DfEVtH6BjKmSiAG5iskpcz3oSpFFaK3teONJP+EibjpIVNscC2zRRYKrYWOJ4wWkVXx9 sqbJ2B86GyeWB3sqB2y3Hm3Gkc8EgTiscljfs0TVVw3kSnXZdIicnrm5aqhrrPf4aiw7 UNDQ== X-Gm-Message-State: AOJu0Yx1LJCP+f8nMh4FqNSrRIqGcw40VDXgo9ZSQ0BTfXFvvmX3ye9M 3hguaUTSlsjxsOc3xust4Z8= X-Google-Smtp-Source: AGHT+IFbODyDl4xuZLifsssTtZT/Y42CwYOW1BuuOJyiaeAVuuJfdHWUZMBaofPPkHAHCLZQNZe3GA== X-Received: by 2002:a05:6808:1783:b0:3bd:3fd6:ce67 with SMTP id bg3-20020a056808178300b003bd3fd6ce67mr4490575oib.32.1705204824935; Sat, 13 Jan 2024 20:00:24 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id ko20-20020a056a00461400b006da13bc46c0sm5582834pfb.171.2024.01.13.20.00.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jan 2024 20:00:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: <87a5p84nlh.fsf@gmail.com> Date: Sat, 13 Jan 2024 20:00:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 13, 2024, at 7:10 PM, Jo=C3=A3o T=C3=A1vora = wrote: >=20 > Yuan Fu writes: >=20 >> observe what breaks? Then Joao can either say =E2=80=9CI told you=E2=80= =9D or happily >> found out that this patch works ok. >=20 > Those are not the only two outcomes. It might work OK and not break > anything [*]. >=20 > However it is not easy to quantify confused users looking to = understand > the new meaning of things in dir-locals.el. Or users wondering why = they > need to set Eglot variables in both 'c++-mode-hook' and > 'c++-ts-mode-hook' when all they see is 'c++-mode' in > 'eglot-server-programs'. I agree. =E2=80=9CNot confusing=E2=80=9D is very valuable for Emacs, or = any system. > So it might not break, and even have some reasonalby solid theoretical > backend beautifully enshrined in documentation. But is it the right > thing? I think not. Unless I'm mistaken it's already proven to be > confusing even to two seasoned Emacs hackers in this thread (and I'm = not > including myself). >=20 > And it doesn't do much for two main problems that were presented at = the > base: Eglot and Yasnippet. I.e. Eglot still inescapably needs to = report > the language to the server and Yasnippet would be better and much > simpler if it could organize snippets by languages instead of major > modes. >=20 > There are better alternatives to this patch: >=20 > 1. The base modes, which are substantially _already_ in place. They > follow the naming convention -base-mode. After giving more > thought to your earlier objection about derived modes overriding > variables, it doesn't make sense (I can elaborate if you want :-) ). Yeah, I made a mistake there, as Stefan corrected. Still, the other part = of the argument holds: creating a base mode needs cooperation from every = involved major modes=E2=80=99 authors. We can=E2=80=99t unilaterally = create base modes and make third-party major modes to base on it. I=E2=80=99= m not saying it wouldn=E2=80=99t work, it would, but we can=E2=80=99t = apply it everywhere. >=20 > 2. Explicitly associating some major modes with languages or file = types. > This doesn't seem hard and other further uses like suggesting modes > or packages to a new user based on languages have been proposed. >=20 > Nevertheless, I suspect that you want a solution to some real problem > happening today Can you say in your own words what that problem is? = As > I explained, I don't have a good idea of the cases besides Eglot, > Yasnippet and possibly/likely Lsp-mode. I think I want the same thing as you do: right now many packages have a = central database that maps major mode to some mode-specific = configuration. IIUC, for Eglot, that=E2=80=99s the server=E2=80=99s = arguments; for Yasnippet, that=E2=80=99s the snippets. I can think of = other examples like hs-special-modes-alist in hideshow.el. I=E2=80=99m = sure there are countless third-party packages that uses a central = database rather than a buffer-local variable for their mode-based = configuration. For those databases, I want lang-ts-mode to use the same configuration = for lang-mode. More importantly, I hope the countless databases in all these = third-party packages to continue to work. Adding language tags for major = modes is nice and all, but a) third-party packages has to change their = database to make use of it, and b) third-party major modes need to add = language tags.=20 That=E2=80=99s why I like major mode names a bit better. Both major mode = names and language tags are leaky abstraction to some degree, so might = as well use the one that already exists. > [*]: It's possible though. One way would be for a user to have added > entries to 'eglot-server-programs' for non-TS 'foo-mode' specifically > with 'add-to-list', a very common practice. Her later 'foo-ts-mode' > entries would be shadowed. Unlikely, perhaps? But what about = variables > set in '.dir-locals.el' for 'foo-mode' and 'foo-ts-mode'? Suprising > "magic" aside, it seems these settings will be merged (right?) in > 'foo-ts-mode' buffers. But does this make sense every time? Even in > our own dir-locals.el there are some settings for 'c-mode' (unrelated = to > cc-mode.el) that are not in the 'c-ts-mode' section, but after = Stefan's > patch it will be as if they were. I think it's unavoidable we'll = catch > some users off-guard and break things. Right=E2=80=A6 Sometimes we want lang-mode and lang-ts-mode to share = some config, and sometimes we don=E2=80=99t. I don=E2=80=99t have good = ideas right now :-) Yuan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 14 01:33:44 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 06:33:44 +0000 Received: from localhost ([127.0.0.1]:41548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOu40-0007By-5W for submit@debbugs.gnu.org; Sun, 14 Jan 2024 01:33:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOu3y-0007Bl-BD for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 01:33:42 -0500 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 1rOu3u-0004zx-02; Sun, 14 Jan 2024 01:33:38 -0500 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=bgFecNVRKW1Y4MQn12PFE/PKBdZ4Ozmss8p33mIgkqw=; b=U8I7+/hkL7JtOIDzmUgu ItjHmqPDRHSfA/oqVrI6KE5nwbLpBSXW7I9f/ghoeQQFWBoUvBTYaG+FuORHiaAtYf6RdBtQl76He gJTWJZvoG/OXJTHJCnIGYwynQbfBIpSJYw6jPYOt7Y7y+0nLAUypzjNifp8zol7WK9NWyMGqi+xTH nAhLgHLOuUFSWGdFSxAo4Uslq7SVLm587L3cPB/xbJSO+yfX/cdnvCfInaQY7aaW55vf0J0TkhT+7 d2ib/61yMXRxOhIxoWihaSGWpo+ZuM9qJKKzsuVPK2a/qQieAnKLufJ3J4JDRsb8AmZ6OEo4duMO4 JjndGLxTb4Sx5A==; Date: Sun, 14 Jan 2024 08:33:19 +0200 Message-Id: <83frz0fmq8.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Sat, 13 Jan 2024 18:19:26 -0800) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sat, 13 Jan 2024 18:19:26 -0800 > Cc: João Távora , > Stefan Monnier , > 68246@debbugs.gnu.org > > Now come back to the subject. What we can do now, it seems, is to > apply this on master and observe what breaks? I agree, and Stefan evidently also agrees, since he already installed this on master, with suitable changes to NEWS and the ELisp reference manual. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 14 02:02:54 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 07:02:54 +0000 Received: from localhost ([127.0.0.1]:41558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOuWE-00057R-5t for submit@debbugs.gnu.org; Sun, 14 Jan 2024 02:02:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOuWB-00057D-A8 for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 02:02:52 -0500 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 1rOuW6-0004Tf-Ia; Sun, 14 Jan 2024 02:02:46 -0500 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=wThNZbkq17oJrh7cc+G6aBffguw5c57bW25TMbAGUQ4=; b=dZMsfybSm5JJRIDl8KE5 JpgsFVkUxGTgd2Cd1afupXOk5Eg4rAcaXFLjd+iRgUx8UbN4j3PLKBHlSzcWirGfZT4HM8hJK+8Ro 1b4wrkdILmz+I/83jB5x8CHTDqIcSQO6gHNMBratCgy0mWohDPxG6ta8qzTLnbRsQyOmMgY7hnDKp P4CZOO2kWUpM3DY2JKvTHq6HdvzvNJ5oEw2FiSl1mavaWqBlpd80GOM+uj26m7+aywyAHFt1KXyej iszR9LfrVrmXjxFB7SeK84c+yScR0Vqne6jKRh/+2bjZFcfW4+YBXvOmWEMSaW+e4s0aYXqAP21r5 fnm/+epqhHmAFQ==; Date: Sun, 14 Jan 2024 09:02:25 +0200 Message-Id: <83edekfldq.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87a5p84nlh.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 14 Jan 2024 03:10:02 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: Eli Zaretskii , Stefan Monnier > , 68246@debbugs.gnu.org > Date: Sun, 14 Jan 2024 03:10:02 +0000 > > Yuan Fu writes: > > > observe what breaks? Then Joao can either say “I told you” or happily > > found out that this patch works ok. > > Those are not the only two outcomes. It might work OK and not break > anything [*]. > > However it is not easy to quantify confused users looking to understand > the new meaning of things in dir-locals.el. Or users wondering why they > need to set Eglot variables in both 'c++-mode-hook' and > 'c++-ts-mode-hook' when all they see is 'c++-mode' in > 'eglot-server-programs'. Those users will hopefully submit bug reports or otherwise complain on the Emacs mailing lists, and then we will know. > There are better alternatives to this patch: > > 1. The base modes, which are substantially _already_ in place. They > follow the naming convention -base-mode. After giving more > thought to your earlier objection about derived modes overriding > variables, it doesn't make sense (I can elaborate if you want :-) ). The recommendation is to use base modes where it makes sense, and the installed changes around derived-mode-add-parents don't in any way preclude having a base mode and don't make it harder. But I don't think we should force everyone in this situation to invent a base mode as the sole means for solving this. > 2. Explicitly associating some major modes with languages or file types. > This doesn't seem hard and other further uses like suggesting modes > or packages to a new user based on languages have been proposed. This is IMO a heavier and more thorough change, especially since Emacs doesn't have the notion of "language". This discussion shows that its advantages are not evident, and moreover we don't even have a clear shared view what will that entail. So I think Yuan is right: let's see what happens with what we have on master, and take it from there. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 14 18:18:21 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 23:18:21 +0000 Received: from localhost ([127.0.0.1]:44231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rP9kD-0004CU-6E for submit@debbugs.gnu.org; Sun, 14 Jan 2024 18:18:21 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:59409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rP9kB-0004CG-Bc for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 18:18:19 -0500 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40e68d0dbf9so22933035e9.2 for <68246@debbugs.gnu.org>; Sun, 14 Jan 2024 15:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705274293; x=1705879093; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=bcdCwAOFunyFVh0kjoQTPTMCoUYqoe12ctatymPZylM=; b=Yig4gbyMgpEsafQHaEmZK/K5a9INH+gCP75Y58OOcULp9DdqVh+wgyt0Iyh7lZxeDS 00RQE2/frZa7auUf9qFq6e6G7/YijaxdM3rYj4in/yhEbWRz4Q/86qN0kalS5mZoSuu1 QpqEA5A4J2+0Oho0WX2stkthK8tZzc/oXYTzmCHKgV+32hs52GBLfrzCEulQpdFQUw6B EiUoTsv05jSMlBQkw7LC0Gib39GttL4uTrdametZJdv90U4nkHWidOUEKL9dnKVV4DjQ DnaLz5cu+amVA35lr71YH1w+CAppsfr/Eb5R88HyCewfFSCmONhtsBPvzo7sqX/2Lj2G 5cGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705274293; x=1705879093; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bcdCwAOFunyFVh0kjoQTPTMCoUYqoe12ctatymPZylM=; b=SN9xl9MyRHvDTsy7ZP7ubHbUUl+WCt4NPl+6QawoGpdhgh+nUzH51YM9TilSaUZyUG PqL8IoDZcJbUmNmteHNPJ7exTpfRVrt4ljUzHcwMVZwWX4yHBAvFhD4iisYyVP2/1YHH tWD3tXyAIdryJayhTYjZ6F1eJZqTYvmgw2/a+sLYHwnzPx+99lVb17HI93kcG4KOS+TS YnntSG/gETe3dEiRvrjn+2JhE8GbGFSYxhfQsSbbuqU1eOq8XdalRUGDXbo/nsxbp2FQ xBV9CGhH9oHH+0NrVCZ1wAk1V1V84f4dgR3yVzST0t+MTGFSEodsL9+n5xL4XxZFcNd3 FwyQ== X-Gm-Message-State: AOJu0Yxa1Mog8W83oMpUKVNZlAR4l5fb9jRL8ADK9G94nqmSW/GF8/gX +vjzoVKqsPQX1ELpCGyqOFgHJ9NYklQ= X-Google-Smtp-Source: AGHT+IH86lHhrENhyTumw6Dw/1VLY7ufneoK7/fYQOdwns4jJFZJnoj43pVuUy3Am/Ih84fq1ZXNcA== X-Received: by 2002:a05:600c:68c3:b0:40e:75f6:f757 with SMTP id jd3-20020a05600c68c300b0040e75f6f757mr335490wmb.318.1705274292949; Sun, 14 Jan 2024 15:18:12 -0800 (PST) Received: from krug ([87.196.72.99]) by smtp.gmail.com with ESMTPSA id p10-20020a05600c358a00b0040e559e0ba7sm17552259wmq.26.2024.01.14.15.18.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 15:18:12 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <83frz0fmq8.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Jan 2024 08:33:19 +0200") References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <83frz0fmq8.fsf@gnu.org> Date: Sun, 14 Jan 2024 23:18:11 +0000 Message-ID: <877ckbfqrw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Yuan Fu , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Now come back to the subject. What we can do now, it seems, is to >> apply this on master and observe what breaks? > > I agree, and Stefan evidently also agrees, since he already installed > this on master, with suitable changes to NEWS and the ELisp reference > manual. I don't see the Stefan M's patch to this bug number in either master or Emacs 29. If possible I'd like to sign off on the Eglot parts of the final version of the patch to be installed. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 14 18:40:28 2024 Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 23:40:28 +0000 Received: from localhost ([127.0.0.1]:44242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPA5b-0007WS-K8 for submit@debbugs.gnu.org; Sun, 14 Jan 2024 18:40:28 -0500 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:54593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPA5Z-0007WC-1t for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 18:40:25 -0500 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33678156e27so7028990f8f.1 for <68246@debbugs.gnu.org>; Sun, 14 Jan 2024 15:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705275619; x=1705880419; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=2me5OmxSWCOjNKBbjo+e+JNIN3/Vz8Gj+CuESO44OPg=; b=BzipV2vjv7fvGVguAILD9GZ8r9fAKHwSkMgW3S5xDTmrNp03BUIWgZGKCfwzJEzuX7 kdfy9fuMx7LWzW3AdFIaisHPaKp2misrtxe6ZZa2VFjuz3gH/3+eF8TCdqvGCmkjSJNB NGQpFwCMAHcosEwqd+G6N+VLjLVB9xA0L2ct9YWDSbu9KH1PNZTdB203uts7hkWIGEpf nCHHt7+a3dHRzkszXjT1Sp0t9RYmHQNzjz3sxDp+cOzwUmnRPjdZVuFnk8KxesHxsCog sG0MpqyvE9cGvwFDmkuErrES4BadxUbuXWq9zQC92I42s0LzFC1SJ/tJkz1zifQKwvlM am7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705275619; x=1705880419; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=2me5OmxSWCOjNKBbjo+e+JNIN3/Vz8Gj+CuESO44OPg=; b=k9KTmPBK1XzHAl/dmDxat5Pu2NeuKVSNPtbxk6ff1ZhiiKpuiTtr2P3KS7/DT0qYDr jyEmjBiZw0lCXWZx1P9iHnr0baEEnY89Qvke3tlhe2NWinr24cntBSblDsYhyp7GlQAW 1GkHpPWogLe+1PfI/dXINkhBfIe8Fv+fsR72bp7h7KgZGy2p39I1eJkbyUq2xNe/uWpx 9by9RLWRUiVPAu6c37nHfgvamih+wIXbWGuA9szn2Yq0c67pFwdoCmQiYhdvlgm61Zd9 YntFNZezI/qxAhmlWzyN7thmcs6lHcJlnDtnZenE5kDtBuJ1WB3sU8+fXEdnJqjiY0/T VuZw== X-Gm-Message-State: AOJu0Yyo3jGvsIfXjnAT9TUpQ4u+3qsBSywg8yiH5sooxnWmNb5vNz+n cb0rLWk5nc/OGaZYc7I83MbDEJk816k= X-Google-Smtp-Source: AGHT+IFL5TSCLtn6wNb4LuMQMwQtoJUK4vB4xjG0IzSCKzlQlASzCTWdzcZ5RDBOCR/Dw2Y+AB0eeg== X-Received: by 2002:a5d:4843:0:b0:337:6258:4e76 with SMTP id n3-20020a5d4843000000b0033762584e76mr2530349wrs.112.1705275618865; Sun, 14 Jan 2024 15:40:18 -0800 (PST) Received: from krug ([87.196.72.99]) by smtp.gmail.com with ESMTPSA id x18-20020adfffd2000000b003377680c55bsm10262372wrs.16.2024.01.14.15.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 15:40:18 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <83edekfldq.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Jan 2024 09:02:25 +0200") References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> Date: Sun, 14 Jan 2024 23:40:17 +0000 Message-ID: <871qajfpr2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> However it is not easy to quantify confused users looking to understand >> the new meaning of things in dir-locals.el. Or users wondering why they >> need to set Eglot variables in both 'c++-mode-hook' and >> 'c++-ts-mode-hook' when all they see is 'c++-mode' in >> 'eglot-server-programs'. > > Those users will hopefully submit bug reports or otherwise complain on > the Emacs mailing lists, and then we will know. You also know this doesn't always happen. A confused user has a certain probability of using those channels, and that is most definitely not 100%. But I will make sure to send any Eglot confusion this way yes. >> There are better alternatives to this patch: >>=20 >> 1. The base modes, which are substantially _already_ in place. They >> follow the naming convention -base-mode. After giving more >> thought to your earlier objection about derived modes overriding >> variables, it doesn't make sense (I can elaborate if you want :-) ). > > The recommendation is to use base modes where it makes sense, and the > installed changes around derived-mode-add-parents don't in any way > preclude having a base mode and don't make it harder. But I don't > think we should force everyone in this situation to invent a base mode > as the sole means for solving this. We can invent for them. There's very little to invent. Earlier you seemed to view a base mode as a receptacle for common code. It _can_ be that (and _should_ where applicable). But it doesn't _have_ to be. An empty base mode is useful just for its hook and its behaviour in dir-locals, for example. So, find two modes for the same language foo, make an empty foo-base-mode: (define-derived-mode foo-base-mode prog-mode "Base mode for Foo") Then ask the authors of 'foo-mode', 'foo-ts-mode', 'foo-nongnu-mode', etc to put foo-base-mode in their mode definitions. If they refuse or are unresponsive, consider insinuating 'foo-base-mode' in them (after asking why, of course). If this insinuation is acceptable for complex "extra parents", why shouldn't it be acceptable for normal parents? This is not technically hard to do, a simple add-function works (and it's also self-documenting). >> 2. Explicitly associating some major modes with languages or file types. >> This doesn't seem hard and other further uses like suggesting modes >> or packages to a new user based on languages have been proposed. > > This is IMO a heavier and more thorough change, especially since Emacs > doesn't have the notion of "language". This discussion shows that its > advantages are not evident, and moreover we don't even have a clear > shared view what will that entail. It's not an extremely heavy change, at least not when compared to extra parents at least. But yes, we should be careful how to implement it. The advantages are evident though. Eglot and Yasnippet would be much simpler to configure. Even simpler with a language-specific hook. But "base mode" approach, which has a significant deployment already, is basically the "languages approach" in slightly more verbose naming. > So I think Yuan is right: let's see what happens with what we have on > master, and take it from there. OK, experimenting in master is what master is good for, after all. Could be effective (even too much, as the recent register imbroglio clearly showed). But I think the practical subtleties (like dir-locals merging, potential Eglot fallout) need to be highlighted somewhere or at least announced in emacs-devel. Also I for one would like to understand the how consistently these extra-parents are going to be used in the future: the symbol named 'foo-mode' is about to be promoted to something above just _a_ major-mode for Foo, and I'd like to see that cleanly described somewhere. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 14 21:10:28 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 02:10:28 +0000 Received: from localhost ([127.0.0.1]:44411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPCQl-0004eG-Nh for submit@debbugs.gnu.org; Sun, 14 Jan 2024 21:10:28 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:44931) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPCQi-0004dv-Jm for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 21:10:25 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E0E515C00FD; Sun, 14 Jan 2024 21:10:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 14 Jan 2024 21:10:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1705284619; x=1705371019; bh=J5l6/C1wdj Fj0ezXq2KDbvL7dc9+mHMPhGmQX6eVaDE=; b=f7+oF4Br06PgwUkU4bweo9rGKW QPVDx3eIPXsUx1H/32PUoYboD5KwfbMt+0pHvisji9FDcYC9f/LUGru5T73Djawb 2P7u9q5U7o6XZ7fKZ5V21ye/XUZzDmyF9cjQz95YdiTz1Ow7/xzmiA9f7YoM0SRA VvKOPmTTt7eV4OTy8WWzV21KTayNz0WAfL7rD2yoO5NznZcXCZlCj6co1ai6JQ1b n1cjqEfN4j42AgqV9h7Tura2E39gvhwv4sVzNPdHymkaQQdqgxHUYx433ZaOp+UT eOA2Iq0o4cRg1QdloM+N7DsGMplcdtnHQuXV0ioDTsqNuwdepb8/yWaAGTCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1705284619; x=1705371019; bh=J5l6/C1wdjFj0ezXq2KDbvL7dc9+ mHMPhGmQX6eVaDE=; b=YRHpUzfR4bO+eMPQst1GoarMHBBuNOYKuy8YkEJ6eooH 8g7AqHJRU5dhsYKHtG7PqrjhdoobC60e/XKGaN/mepAQjWWYjfvr6U/pwymPCB0n w6gOinqLg8S00TZnBcQ7ZuQopOCUqgC09wGxtCKa291QKMep8+bQg2GzmrUQj87s n8l/X2kJOUETjG++YZS04xwouyR9fcZAgm6gb3dNn1ZTv9/+iS3ssmbSD5yjGKub jlzx2USR7n3aFKuDfCzb0uColKNOYQc5t4bANvO/5W0Re0rR4KWTDHbdLeb2SIij /5h1ghUwB99cbCHh6rhpA8JgDxu0W7cZfdemR6ca+g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejtddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeujeegueekveffkeejjeev heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 14 Jan 2024 21:10:17 -0500 (EST) Content-Type: multipart/mixed; boundary="------------z7nKgB6pfDIY6GBUOKYYxVsB" Message-ID: Date: Mon, 15 Jan 2024 04:10:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Kangas References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83edekfldq.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------z7nKgB6pfDIY6GBUOKYYxVsB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 14/01/2024 09:02, Eli Zaretskii wrote: >> From: João Távora >> Cc: Eli Zaretskii , Stefan Monnier >> , 68246@debbugs.gnu.org >> Date: Sun, 14 Jan 2024 03:10:02 +0000 >> >> Yuan Fu writes: >> >>> observe what breaks? Then Joao can either say “I told you” or happily >>> found out that this patch works ok. >> >> Those are not the only two outcomes. It might work OK and not break >> anything [*]. >> >> However it is not easy to quantify confused users looking to understand >> the new meaning of things in dir-locals.el. Or users wondering why they >> need to set Eglot variables in both 'c++-mode-hook' and >> 'c++-ts-mode-hook' when all they see is 'c++-mode' in >> 'eglot-server-programs'. > > Those users will hopefully submit bug reports or otherwise complain on > the Emacs mailing lists, and then we will know. I rather wouldn't rely on that. >> There are better alternatives to this patch: >> >> 1. The base modes, which are substantially _already_ in place. They >> follow the naming convention -base-mode. After giving more >> thought to your earlier objection about derived modes overriding >> variables, it doesn't make sense (I can elaborate if you want :-) ). > > The recommendation is to use base modes where it makes sense, and the > installed changes around derived-mode-add-parents don't in any way > preclude having a base mode and don't make it harder. But I don't > think we should force everyone in this situation to invent a base mode > as the sole means for solving this. It's not like we don't have an existing solution for this: if there are two different modes to configure, change the settings for both modes, or alter two hooks. Less magical and more verbose, but being explicit can be good. >> 2. Explicitly associating some major modes with languages or file types. >> This doesn't seem hard and other further uses like suggesting modes >> or packages to a new user based on languages have been proposed. > > This is IMO a heavier and more thorough change, especially since Emacs > doesn't have the notion of "language". This discussion shows that its > advantages are not evident, and moreover we don't even have a clear > shared view what will that entail. Here's a draft patch of how a "language" could work. It doesn't alter every entry, but it is backward compatible. It adds an entity called "language" above major modes which are denoted with keywords (you could also call it content-types, but that's a longer name). The patch implements an implicit language detection as well (based on the mode name), but ideally modes that belong to specific languages would not have direct entries in auto-mode-alist, etc, at all. Benefits: - Avoiding duplicating a bunch of regexps, for ts modes in particular. - Uncovered an existing bug: ruby-ts-mode didn't add an entry for interpreter-mode-alist, only for auto-mode-alist. - The user could avoid thinking in terms of major modes, and when they wanted to enable a fitting mode, they can type 'M-x set-buffer-language' and choose one of the known languages with completion. - Features like Eglot could now call (buffer-language) and dispatch based on that (that can make the value of eglot-server-programs more compact in the long run). - Hook -language-hook is run inside set-auto-mode-0, for the user to add customizations to major modes that share the language but no common ancestor. Further possible additions (mentioned previously): - Potential UI for customizing major-mode-remap-alist to decide which major mode to use for a given language, becomes easier/doable. - Even when there is no installed major mode for a given language, but an auto-mode-alist entry for it exists, we could now do something with it in fundamental-mode. Like still use Eglot's features, or suggest the user installs one of the language support packages for that language from ELPA (knowing the language name, we can suggest a specific package). --------------z7nKgB6pfDIY6GBUOKYYxVsB Content-Type: text/x-patch; charset=UTF-8; name="buffer-language.diff" Content-Disposition: attachment; filename="buffer-language.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvZmlsZXMuZWwgYi9saXNwL2ZpbGVzLmVsCmluZGV4IDljODkx NGJmYzUwLi4wNzA3ZGMwOWFjOCAxMDA2NDQKLS0tIGEvbGlzcC9maWxlcy5lbAorKysgYi9s aXNwL2ZpbGVzLmVsCkBAIC0zMDEwLDEwICszMDEwLDEwIEBAIGF1dG8tbW9kZS1hbGlzdAog ICAgICAoIlxcLmRia1xcJyIgLiB4bWwtbW9kZSkKICAgICAgKCJcXC5kdGRcXCciIC4gc2dt bC1tb2RlKQogICAgICAoIlxcLmRzXFwoc3NcXCk/bFxcJyIgLiBkc3NzbC1tb2RlKQotICAg ICAoIlxcLmpzW214XT9cXCciIC4gamF2YXNjcmlwdC1tb2RlKQorICAgICAoIlxcLmpzW214 XT9cXCciIC4gOmpzKQogICAgICA7OyBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS8u aGFyCi0gICAgICgiXFwuaGFyXFwnIiAuIGphdmFzY3JpcHQtbW9kZSkKLSAgICAgKCJcXC5q c29uXFwnIiAuIGpzLWpzb24tbW9kZSkKKyAgICAgKCJcXC5oYXJcXCciIC4gOmpzKQorICAg ICAoIlxcLmpzb25cXCciIC4gOmpzb24pCiAgICAgICgiXFwuW2RzXT92YT9oP1xcJyIgLiB2 ZXJpbG9nLW1vZGUpCiAgICAgICgiXFwuYnlcXCciIC4gYm92aW5lLWdyYW1tYXItbW9kZSkK ICAgICAgKCJcXC53eVxcJyIgLiB3aXNlbnQtZ3JhbW1hci1tb2RlKQpAQCAtMzE1MCw2ICsz MTUwLDkgQEAgYXV0by1tb2RlLWFsaXN0CiBWaXNpdGluZyBhIGZpbGUgd2hvc2UgbmFtZSBt YXRjaGVzIFJFR0VYUCBzcGVjaWZpZXMgRlVOQ1RJT04gYXMgdGhlCiBtb2RlIGZ1bmN0aW9u IHRvIHVzZS4gIEZVTkNUSU9OIHdpbGwgYmUgY2FsbGVkLCB1bmxlc3MgaXQgaXMgbmlsLgog CitGVU5DVElPTiBjYW4gYWxzbyBiZSBhIGtleXdvcmQgZGVub3RpbmcgYSBsYW5ndWFnZSwg dG8gYmUgbG9va2VkCit1cCBpbiBgbWFqb3ItbW9kZS1yZW1hcC1hbGlzdCcuCisKIElmIHRo ZSBlbGVtZW50IGhhcyB0aGUgZm9ybSAoUkVHRVhQIEZVTkNUSU9OIE5PTi1OSUwpLCB0aGVu IGFmdGVyCiBjYWxsaW5nIEZVTkNUSU9OIChpZiBpdCdzIG5vdCBuaWwpLCB3ZSBkZWxldGUg dGhlIHN1ZmZpeCB0aGF0IG1hdGNoZWQKIFJFR0VYUCBhbmQgc2VhcmNoIHRoZSBsaXN0IGFn YWluIGZvciBhbm90aGVyIG1hdGNoLgpAQCAtMzIwNiwxMCArMzIwOSwxMCBAQCBpbnRlcnBy ZXRlci1tb2RlLWFsaXN0CiAgICAgICgiZW1hY3MiIC4gZW1hY3MtbGlzcC1tb2RlKSkpCiAg ICJBbGlzdCBtYXBwaW5nIGludGVycHJldGVyIG5hbWVzIHRvIG1ham9yIG1vZGVzLgogVGhp cyBpcyB1c2VkIGZvciBmaWxlcyB3aG9zZSBmaXJzdCBsaW5lcyBtYXRjaCBgYXV0by1tb2Rl LWludGVycHJldGVyLXJlZ2V4cCcuCi1FYWNoIGVsZW1lbnQgbG9va3MgbGlrZSAoUkVHRVhQ IC4gTU9ERSkuCitFYWNoIGVsZW1lbnQgbG9va3MgbGlrZSAoUkVHRVhQIC4gTU9ERS1PUi1M QU5HVUFHRSkuCiBJZiBSRUdFWFAgbWF0Y2hlcyB0aGUgZW50aXJlIG5hbWUgKG1pbnVzIGFu eSBkaXJlY3RvcnkgcGFydCkgb2YKIHRoZSBpbnRlcnByZXRlciBzcGVjaWZpZWQgaW4gdGhl IGZpcnN0IGxpbmUgb2YgYSBzY3JpcHQsIGVuYWJsZQotbWFqb3IgbW9kZSBNT0RFLgorTU9E RS1PUi1MQU5HVUFHRS4KIAogU2VlIGFsc28gYGF1dG8tbW9kZS1hbGlzdCcuIikKIApAQCAt MzU1NCw3ICszNTU3LDcgQEAgbWFqb3ItbW9kZS1yZW1hcC1hbGlzdAogOzsgc2FtZSBvbmUg d2UgYWxyZWFkeSBoYXZlLCBkb24ndCBhY3R1YWxseSByZXNldCBpdC4gIFdlIGRvbid0IHdh bnQgdG8gbG9zZQogOzsgbWlub3IgbW9kZXMgc3VjaCBhcyBGb250IExvY2suCiAoZGVmdW4g c2V0LWF1dG8tbW9kZS0wIChtb2RlICZvcHRpb25hbCBrZWVwLW1vZGUtaWYtc2FtZSkKLSAg IkFwcGx5IE1PREUgYW5kIHJldHVybiBpdC4KKyAgIkFwcGx5IE1PREUgYW5kIHJldHVybiBp dC4gIE1PREUgY2FuIGJlIGEgZnVuY3Rpb24gb2YgbGFuZ3VhZ2UuCiBJZiBvcHRpb25hbCBh cmcgS0VFUC1NT0RFLUlGLVNBTUUgaXMgbm9uLW5pbCwgTU9ERSBpcyBjaGFzZWQgb2YKIGFu eSBhbGlhc2VzIGFuZCBjb21wYXJlZCB0byBjdXJyZW50IG1ham9yIG1vZGUuICBJZiB0aGV5 IGFyZSB0aGUKIHNhbWUsIGRvIG5vdGhpbmcgYW5kIHJldHVybiBuaWwuIgpAQCAtMzU2NSwx MSArMzU2OCw0MyBAQCBzZXQtYXV0by1tb2RlLTAKIAkJICAgICAgICAoZXEgbW9kZSAoY2Fy IHNldC1hdXRvLW1vZGUtLWxhc3QpKQogCQkgICAgICAgIChlcSBtYWpvci1tb2RlIChjZHIg c2V0LWF1dG8tbW9kZS0tbGFzdCkpKSkpCiAgICAgKHdoZW4gbW9kZQotICAgICAgKGZ1bmNh bGwgKGFsaXN0LWdldCBtb2RlIG1ham9yLW1vZGUtcmVtYXAtYWxpc3QgbW9kZSkpCisgICAg ICA7OyBYWFg6IFdoZW4gdGhlcmUncyBubyBtYXBwaW5nIGZvciBgOjxsYW5ndWFnZT4nLCB3 ZSBjb3VsZCBhbHNvCisgICAgICA7OyBsb29rIGZvciBhIGZ1bmN0aW9uIGNhbGxlZCBgPGxh bmd1YWdlPi1tb2RlJy4KKyAgICAgIChmdW5jYWxsIChhbGlzdC1nZXQgbW9kZSBtYWpvci1t b2RlLXJlbWFwLWFsaXN0IChpZiAoa2V5d29yZHAgbW9kZSkKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjJ2Z1bmRhbWVudGFs LW1vZGUKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbW9kZSkpKQorICAgICAgKHdoZW4gKGtleXdvcmRwIG1vZGUpICAgICAgICAg ICAgIDtQZXJoYXBzIGRvIHRoYXQgdW5jb25kaXRpb25hbGx5LgorICAgICAgICAocnVuLWhv b2tzIChpbnRlcm4gKGZvcm1hdCAiJXMtbGFuZ3VhZ2UtaG9vayIgKGJ1ZmZlci1sYW5ndWFn ZSkpKSkpCiAgICAgICAodW5sZXNzIChlcSBtb2RlIG1ham9yLW1vZGUpCiAgICAgICAgIChz ZXRxIHNldC1hdXRvLW1vZGUtLWxhc3QgKGNvbnMgbW9kZSBtYWpvci1tb2RlKSkpCiAgICAg ICBtb2RlKSkpCiAKKyhkZWZ1biBidWZmZXItbGFuZ3VhZ2UgKCkKKyAgIlJldHVybiB0aGUg bGFuZ3VhZ2Ugb2YgdGhlIGN1cnJlbnQgYnVmZmVyLgorQSBsYW5ndWFnZSBpcyBhIGxvd2Vy Y2FzZSBrZXl3b3JkIHdpdGggdGhlIG5hbWUgb2YgdGhlIGxhbmd1YWdlLiIKKyAgOzsgQWx0 ZXJuYXRpdmVseSwgd2UgY291bGQgZ28gdGhyb3VnaCBhbGwgdGhlIG1hdGNoZXJzIGluCisg IDs7IGF1dG8tbW9kZS1hbGlzdCwgaW50ZXJwcmV0ZXItbW9kZS1hbGlzdCwKKyAgOzsgbWFn aWMtZmFsbGJhY2stbW9kZS1hbGlzdCBoZXJlLCBwb3NzaWJseSB1c2luZyBhIGNhY2hlIGtl eWVkIG9uCisgIDs7IGJ1ZmZlci1maWxlLW5hbWUuICBCdXQgdGhhdCdzIHByb2JhYmx5IGFu IG92ZXJraWxsOiBpZiB0aGUgdXNlcgorICA7OyBjaGFuZ2VzIHRoZSBzZXR0aW5ncywgdGhl eSBjYW4gY2FsbCBgTS14IHJldmVydC1idWZmZXInIGF0IHRoZSBlbmQuCisgIChpZiAoa2V5 d29yZHAgKGNhciBzZXQtYXV0by1tb2RlLS1sYXN0KSkKKyAgICAgIChjYXIgc2V0LWF1dG8t bW9kZS0tbGFzdCkKKyAgICA7OyBCYWNrd2FyZCBjb21wYXRpYmlsaXR5LgorICAgIChpbnRl cm4gKGZvcm1hdCAiOiVzIiAocmVwbGFjZS1yZWdleHAtaW4tc3RyaW5nICJcXCg/Oi10c1xc KT8tbW9kZVxcJyIgIiIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoc3ltYm9sLW5hbWUgbWFqb3ItbW9kZSkpKSkpKQorCisoZGVmdW4g c2V0LWJ1ZmZlci1sYW5ndWFnZSAobGFuZ3VhZ2UpCisgICJTZXQgdGhlIGxhbmd1YWdlIG9m IHRoZSBjdXJyZW50IGJ1ZmZlci4KK0FuZCBzd2l0Y2ggdGhlIG1ham9yIG1vZGUgYXBwcm9w cmlhdGVseS4iCisgIChpbnRlcmFjdGl2ZQorICAgKGxpc3QgKGxldCogKChjdCAobWFwY2Fu CisgICAgICAgICAgICAgICAgICAgICAobGFtYmRhIChwYWlyKSAoYW5kIChrZXl3b3JkcCAo Y2FyIHBhaXIpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxpc3Qg KHN5bWJvbC1uYW1lIChjYXIgcGFpcikpKSkpCisgICAgICAgICAgICAgICAgICAgICBtYWpv ci1tb2RlLXJlbWFwLWFsaXN0KSkKKyAgICAgICAgICAgICAgICAobGFuZyAoY29tcGxldGlu Zy1yZWFkICJMYW5ndWFnZTogIiBjdCkpKQorICAgICAgICAgICAoYW5kIGxhbmcgKGludGVy biBsYW5nKSkpKSkKKyAgKHNldC1hdXRvLW1vZGUtMCBsYW5ndWFnZSkpCisKIChkZWZ2YXIg ZmlsZS1hdXRvLW1vZGUtc2tpcCAiXlxcKCMhXFx8J1xcXFxcIlxcKSIKICAgIlJlZ2V4cCBv ZiBsaW5lcyB0byBza2lwIHdoZW4gbG9va2luZyBmb3IgZmlsZS1sb2NhbCBzZXR0aW5ncy4K IElmIHRoZSBmaXJzdCBsaW5lIG1hdGNoZXMgdGhpcyByZWd1bGFyIGV4cHJlc3Npb24sIHRo ZW4gdGhlIC0qLS4uLi0qLSBmaWxlLQpkaWZmIC0tZ2l0IGEvbGlzcC9wcm9nbW9kZXMvanMu ZWwgYi9saXNwL3Byb2dtb2Rlcy9qcy5lbAppbmRleCAwMTE1ZmViMGU5Ny4uMjE4YTBmMDU1 NDEgMTAwNjQ0Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL2pzLmVsCisrKyBiL2xpc3AvcHJvZ21v ZGVzL2pzLmVsCkBAIC0zODk1LDggKzM4OTUsNyBAQCBqcy10cy1tb2RlCiAgICAgICAgICAg ICAgICAgICAgbmlsIG5pbCkpKQogICAgICh0cmVlc2l0LW1ham9yLW1vZGUtc2V0dXApCiAK LSAgICAoYWRkLXRvLWxpc3QgJ2F1dG8tbW9kZS1hbGlzdAotICAgICAgICAgICAgICAgICAn KCJcXChcXC5qc1tteF1cXHxcXC5oYXJcXClcXCciIC4ganMtdHMtbW9kZSkpKSkKKyAgICAo YWRkLXRvLWxpc3QgJ21ham9yLW1vZGUtcmVtYXAtYWxpc3QgJyg6anMgLiBqcy10cy1tb2Rl KSkpKQogCiAoZGVmdmFyIGpzLXRzLS1zLXAtcXVlcnkKICAgKHdoZW4gKHRyZWVzaXQtYXZh aWxhYmxlLXApCkBAIC0zOTc3LDcgKzM5NzYsMTEgQEAganMtanN4LS1jb21tZW50LXJlZ2lv bgogCiA7OzsjIyNhdXRvbG9hZAogKGRvbGlzdCAobmFtZSAobGlzdCAibm9kZSIgIm5vZGVq cyIgImdqcyIgInJoaW5vIikpCi0gIChhZGQtdG8tbGlzdCAnaW50ZXJwcmV0ZXItbW9kZS1h bGlzdCAoY29ucyAocHVyZWNvcHkgbmFtZSkgJ2pzLW1vZGUpKSkKKyAgKGFkZC10by1saXN0 ICdpbnRlcnByZXRlci1tb2RlLWFsaXN0IChjb25zIChwdXJlY29weSBuYW1lKSA6anMpKSkK KworOzs7IyMjYXV0b2xvYWQKKyhhZGQtdG8tbGlzdCAnbWFqb3ItbW9kZS1yZW1hcC1hbGlz dCAnKDpqcyAuIGpzLW1vZGUpKQorKGFkZC10by1saXN0ICdtYWpvci1tb2RlLXJlbWFwLWFs aXN0ICcoOmpzb24gLiBqcy1qc29uLW1vZGUpKQogCiAocHJvdmlkZSAnanMpCiAKZGlmZiAt LWdpdCBhL2xpc3AvcHJvZ21vZGVzL2pzb24tdHMtbW9kZS5lbCBiL2xpc3AvcHJvZ21vZGVz L2pzb24tdHMtbW9kZS5lbAppbmRleCAzMmJjMTBiYmRhOS4uNDUzNTU0YTkyZGQgMTAwNjQ0 Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL2pzb24tdHMtbW9kZS5lbAorKysgYi9saXNwL3Byb2dt b2Rlcy9qc29uLXRzLW1vZGUuZWwKQEAgLTE2NSw4ICsxNjUsNyBAQCBqc29uLXRzLW1vZGUK ICAgKHRyZWVzaXQtbWFqb3ItbW9kZS1zZXR1cCkpCiAKIChpZiAodHJlZXNpdC1yZWFkeS1w ICdqc29uKQotICAgIChhZGQtdG8tbGlzdCAnYXV0by1tb2RlLWFsaXN0Ci0gICAgICAgICAg ICAgICAgICcoIlxcLmpzb25cXCciIC4ganNvbi10cy1tb2RlKSkpCisgICAgKGFkZC10by1s aXN0ICdtYWpvci1tb2RlLXJlbWFwLWFsaXN0ICcoOmpzb24gLiBqc29uLXRzLW1vZGUpKSkK IAogKHByb3ZpZGUgJ2pzb24tdHMtbW9kZSkKIApkaWZmIC0tZ2l0IGEvbGlzcC9wcm9nbW9k ZXMvcHl0aG9uLmVsIGIvbGlzcC9wcm9nbW9kZXMvcHl0aG9uLmVsCmluZGV4IDExNDhkYTEx YTA2Li4wZDU2MGVlMWE1ZiAxMDA2NDQKLS0tIGEvbGlzcC9wcm9nbW9kZXMvcHl0aG9uLmVs CisrKyBiL2xpc3AvcHJvZ21vZGVzL3B5dGhvbi5lbApAQCAtMjg4LDkgKzI4OCw5IEBAIG91 dGxpbmUtaGVhZGluZy1lbmQtcmVnZXhwCiAoYXV0b2xvYWQgJ2hlbHAtZnVuY3Rpb24tYXJn bGlzdCAiaGVscC1mbnMiKQogCiA7OzsjIyNhdXRvbG9hZAotKGFkZC10by1saXN0ICdhdXRv LW1vZGUtYWxpc3QgKGNvbnMgKHB1cmVjb3B5ICJcXC5weVtpd10/XFwnIikgJ3B5dGhvbi1t b2RlKSkKKyhhZGQtdG8tbGlzdCAnYXV0by1tb2RlLWFsaXN0IChjb25zIChwdXJlY29weSAi XFwucHlbaXddP1xcJyIpIDpweXRob24pKQogOzs7IyMjYXV0b2xvYWQKLShhZGQtdG8tbGlz dCAnaW50ZXJwcmV0ZXItbW9kZS1hbGlzdCAoY29ucyAocHVyZWNvcHkgInB5dGhvblswLTku XSoiKSAncHl0aG9uLW1vZGUpKQorKGFkZC10by1saXN0ICdpbnRlcnByZXRlci1tb2RlLWFs aXN0IChjb25zIChwdXJlY29weSAicHl0aG9uWzAtOS5dKiIpIDpweXRob24pKQogCiAoZGVm Z3JvdXAgcHl0aG9uIG5pbAogICAiUHl0aG9uIExhbmd1YWdlJ3MgZmx5aW5nIGNpcmN1cyBz dXBwb3J0IGZvciBFbWFjcy4iCkBAIC02OTkyLDggKzY5OTIsNyBAQCBweXRob24tdHMtbW9k ZQogICAgICh3aGVuIHB5dGhvbi1pbmRlbnQtZ3Vlc3MtaW5kZW50LW9mZnNldAogICAgICAg KHB5dGhvbi1pbmRlbnQtZ3Vlc3MtaW5kZW50LW9mZnNldCkpCiAKLSAgICAoYWRkLXRvLWxp c3QgJ2F1dG8tbW9kZS1hbGlzdCAnKCJcXC5weVtpd10/XFwnIiAuIHB5dGhvbi10cy1tb2Rl KSkKLSAgICAoYWRkLXRvLWxpc3QgJ2ludGVycHJldGVyLW1vZGUtYWxpc3QgJygicHl0aG9u WzAtOS5dKiIgLiBweXRob24tdHMtbW9kZSkpKSkKKyAgICAoYWRkLXRvLWxpc3QgJ21ham9y LW1vZGUtcmVtYXAtYWxpc3QgJyg6cHl0aG9uIC4gcHl0aG9uLXRzLW1vZGUpKSkpCiAKIDs7 OyBDb21wbGV0aW9uIHByZWRpY2F0ZXMgZm9yIE0teAogOzsgQ29tbWFuZHMgdGhhdCBvbmx5 IG1ha2Ugc2Vuc2Ugd2hlbiBlZGl0aW5nIFB5dGhvbiBjb2RlLgpkaWZmIC0tZ2l0IGEvbGlz cC9wcm9nbW9kZXMvcnVieS1tb2RlLmVsIGIvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLmVs CmluZGV4IDk5OWZiZWJmYjA4Li42OTc1Y2Y1YmUwYSAxMDA2NDQKLS0tIGEvbGlzcC9wcm9n bW9kZXMvcnVieS1tb2RlLmVsCisrKyBiL2xpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5lbApA QCAtMjcwMywxMSArMjcwMywxMyBAQCBydWJ5LW1vZGUKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAiXFx8UHVwcGV0XFx8QmVya3NcXHxCcmV3XFx8RmFzdCIKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiXFx8VmFncmFudFxcfEd1YXJk XFx8UG9kXFwpZmlsZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi XFwpXFwnIikpCi0gICAgICAgICAgICAgICAgICAgJ3J1YnktbW9kZSkpCisgICAgICAgICAg ICAgICAgICAgOnJ1YnkpKQorOzs7IyMjYXV0b2xvYWQKKyhhZGQtdG8tbGlzdCAnbWFqb3It bW9kZS1yZW1hcC1hbGlzdCAnKDpydWJ5IC4gcnVieS1tb2RlKSkKIAogOzs7IyMjYXV0b2xv YWQKIChkb2xpc3QgKG5hbWUgKGxpc3QgInJ1YnkiICJyYngiICJqcnVieSIgImo/cnVieVxc KD86WzAtOS5dK1xcKSIpKQotICAoYWRkLXRvLWxpc3QgJ2ludGVycHJldGVyLW1vZGUtYWxp c3QgKGNvbnMgKHB1cmVjb3B5IG5hbWUpICdydWJ5LW1vZGUpKSkKKyAgKGFkZC10by1saXN0 ICdpbnRlcnByZXRlci1tb2RlLWFsaXN0IChjb25zIChwdXJlY29weSBuYW1lKSA6cnVieSkp KQogCiAocHJvdmlkZSAncnVieS1tb2RlKQogCmRpZmYgLS1naXQgYS9saXNwL3Byb2dtb2Rl cy9ydWJ5LXRzLW1vZGUuZWwgYi9saXNwL3Byb2dtb2Rlcy9ydWJ5LXRzLW1vZGUuZWwKaW5k ZXggNTk4ZWFhNDYxZmYuLjlmYjI1M2JhNzA2IDEwMDY0NAotLS0gYS9saXNwL3Byb2dtb2Rl cy9ydWJ5LXRzLW1vZGUuZWwKKysrIGIvbGlzcC9wcm9nbW9kZXMvcnVieS10cy1tb2RlLmVs CkBAIC0zNSw4ICszNSw4IEBACiA7OyBgdHJlZXNpdC1leHRyYS1sb2FkLXBhdGgnLgogCiA7 OyBUaGlzIG1vZGUgZG9lc24ndCBhc3NvY2lhdGUgaXRzZWxmIHdpdGggLnJiIGZpbGVzIGF1 dG9tYXRpY2FsbHkuCi07OyBZb3UgY2FuIGRvIHRoYXQgZWl0aGVyIGJ5IHByZXBlbmRpbmcg dG8gdGhlIHZhbHVlIG9mCi07OyBgYXV0by1tb2RlLWFsaXN0Jywgb3IgdXNpbmcgYG1ham9y LW1vZGUtcmVtYXAtYWxpc3QnLgorOzsgWW91IGNhbiBkbyB0aGF0IHVzaW5nIGBtYWpvci1t b2RlLXJlbWFwLWFsaXN0JyAoYnkgYWRkaW5nIGFuIGVudHJ5Cis7OyBmb3IgYDpydWJ5Jyku CiAKIDs7IFRyZWUgU2l0dGVyIGJyaW5ncyBhIGxvdCBvZiBwb3dlciBhbmQgdmVyc2l0aWxp dHkgd2hpY2ggY2FuIGJlCiA7OyBicm9rZW4gaW50byB0aGVzZSBmZWF0dXJlcy4KQEAgLTEx OTcsMTggKzExOTcsNyBAQCBydWJ5LXRzLW1vZGUKICAgKHNldHEtbG9jYWwgc3ludGF4LXBy b3BlcnRpemUtZnVuY3Rpb24gIydydWJ5LXRzLS1zeW50YXgtcHJvcGVydGl6ZSkpCiAKIChp ZiAodHJlZXNpdC1yZWFkeS1wICdydWJ5KQotICAgIDs7IENvcGllZCBmcm9tIHJ1YnktbW9k ZS5lbC4KLSAgICAoYWRkLXRvLWxpc3QgJ2F1dG8tbW9kZS1hbGlzdAotICAgICAgICAgICAg ICAgICAoY29ucyAoY29uY2F0ICJcXCg/OlxcLlxcKD86IgotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICJyYnc/XFx8cnVcXHxyYWtlXFx8dGhvciIKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAiXFx8amJ1aWxkZXJcXHxyYWJsXFx8Z2Vtc3BlY1xcfHBvZHNw ZWMiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlxcKSIKLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAiXFx8LyIKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiXFwoPzpHZW1cXHxSYWtlXFx8Q2FwXFx8VGhvciIKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAiXFx8UHVwcGV0XFx8QmVya3NcXHxCcmV3IgotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICJcXHxWYWdyYW50XFx8R3VhcmRcXHxQb2RcXClmaWxlIgot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJcXClcXCciKQotICAgICAgICAgICAg ICAgICAgICAgICAncnVieS10cy1tb2RlKSkpCisgICAgKGFkZC10by1saXN0ICdtYWpvci1t b2RlLXJlbWFwLWFsaXN0ICcoOnJ1YnkgLiBydWJ5LXRzLW1vZGUpKSkKIAogKHByb3ZpZGUg J3J1YnktdHMtbW9kZSkKIAo= --------------z7nKgB6pfDIY6GBUOKYYxVsB-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 07:36:20 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 12:36:20 +0000 Received: from localhost ([127.0.0.1]:44875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMCR-000769-UN for submit@debbugs.gnu.org; Mon, 15 Jan 2024 07:36:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMCQ-00075t-PY for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 07:36:19 -0500 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 1rPMCK-00034Q-9W; Mon, 15 Jan 2024 07:36:13 -0500 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=KQ4QI/MCXZBTbarIRb1/YGCdTkKdDXZ0A/VHp/51pAc=; b=VcYoqtriHKKZy066jZcD axp+hRU9SaVPhn8IHtE1fwZIN/eeAh1uywiAoWedlRrvPsweyHQVdMtbq9evvXR13WrB8d7ajsShh ZQJlA9GitPWqI78/Jwvp3kIYgsTGrJsjiOY+RRsv684ORggOY4/EJKRIgAdDJ7Ll/ipyVRACick3l ivVJ30Xi3C+ZQcGDL4/N8tZ4EG+E3fYjUQ3lNW4m1u5HO9beVSaU7ieNCoWBitmp6cVXGzhAmAPtA vWFiva9+JYztT0dExLFLFQRKoAb9Zq4uK7AGjRwO+7mg0uauIerisE0WHmMsLmbTSOpBuhRvgj9HB 83oTenEdscnXeA==; Date: Mon, 15 Jan 2024 14:35:58 +0200 Message-Id: <83edeiepu9.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <877ckbfqrw.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 14 Jan 2024 23:18:11 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <83frz0fmq8.fsf@gnu.org> <877ckbfqrw.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: Yuan Fu , monnier@iro.umontreal.ca, > 68246@debbugs.gnu.org > Date: Sun, 14 Jan 2024 23:18:11 +0000 > > Eli Zaretskii writes: > > >> Now come back to the subject. What we can do now, it seems, is to > >> apply this on master and observe what breaks? > > > > I agree, and Stefan evidently also agrees, since he already installed > > this on master, with suitable changes to NEWS and the ELisp reference > > manual. > > I don't see the Stefan M's patch to this bug number in either master or > Emacs 29. Start with commit 4194f9bd870, I think. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 07:39:05 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 12:39:05 +0000 Received: from localhost ([127.0.0.1]:44880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMF7-0007Gs-FI for submit@debbugs.gnu.org; Mon, 15 Jan 2024 07:39:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMF5-0007GP-Sy for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 07:39:04 -0500 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 1rPMF0-0003Vo-Oz; Mon, 15 Jan 2024 07:38:58 -0500 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=FzZ3xXj0AINvP67i/7Fb7N0G+QHVo6MoC5lg9DbKCm4=; b=TO9bsqMFIBe8mw9JIDle Q1VgFuSZyqx8qNMDAd/f/bxq0fVj5E67rh62fBCfL1/ep59MRpGzKMFI/VgWQEwkdVwmo4uwg4k0m yYLz+dwLPkaaAMr6lEfFABDkYkWKaUACy2igcXhhXNZPinF3tmjtA7mh2reJ8QcZ9mwB9K8ZGEoEM WN5JLJeCM8keZip1KHzrSaqN7pijpPhyc2R0koItw9UIQ8lMI2Vr3L5l8ZoE++Eeg5cCv4aIYeBg5 iI27fLDDBMvpcrSoDYckEMgYSqxiJouveFtiR8Bd70ATg1855g9tNgy848JEg+T8s3MfL5fBou/bn uznIb/oJWI18dA==; Date: Mon, 15 Jan 2024 14:38:44 +0200 Message-Id: <83cyu2eppn.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <871qajfpr2.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 14 Jan 2024 23:40:17 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <871qajfpr2.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > Date: Sun, 14 Jan 2024 23:40:17 +0000 > > Eli Zaretskii writes: > > >> However it is not easy to quantify confused users looking to understand > >> the new meaning of things in dir-locals.el. Or users wondering why they > >> need to set Eglot variables in both 'c++-mode-hook' and > >> 'c++-ts-mode-hook' when all they see is 'c++-mode' in > >> 'eglot-server-programs'. > > > > Those users will hopefully submit bug reports or otherwise complain on > > the Emacs mailing lists, and then we will know. > > You also know this doesn't always happen. It's our only reliable instrument of getting feedback for our decisions. > > The recommendation is to use base modes where it makes sense, and the > > installed changes around derived-mode-add-parents don't in any way > > preclude having a base mode and don't make it harder. But I don't > > think we should force everyone in this situation to invent a base mode > > as the sole means for solving this. > > We can invent for them. Yes, but only where it makes sense. For example, an empty base mode doesn't. > An empty base mode is useful just for its hook and its behaviour in > dir-locals, for example. No, it is completely useless, and we shouldn't introduce such modes. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 07:46:57 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 12:46:57 +0000 Received: from localhost ([127.0.0.1]:44890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMMi-0001ij-OL for submit@debbugs.gnu.org; Mon, 15 Jan 2024 07:46:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMMg-0001gB-KI for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 07:46:55 -0500 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 1rPMMb-00059E-Dg; Mon, 15 Jan 2024 07:46:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1jv9D9SPfWUitq3WrwEtFF2yyvAdV0Rqm9OIIoSlG5c=; b=JH4hDoo1KvdF npvMtpDjLvcqxsHwY0cdhwZMTBkxgAttPShSeikYqJfRkGcn2XEXUI744vmU4xzePdhfgEzKVeK8q sveS48rGOC15bfU6Gz2YnEAqPn+5zymObooN6ptBEKgp7ohj4M0Si2VC+jqUKgQFhVQ0l+ztuw3yQ DNbRGUtUcgGN/17bdtp2r+GHqmRC5C5tOCCH4E+U70m4LRnnM42cRBmXN9WY4rEaGFBVD54MIQHSW GNFM/S0bIXrDiida933v5dhcb0HQSFr7511c14esHTnmoZdBHV0APMydUS5vxIfMQkgrr0YuVx3oJ vMMM59TprrqXIAltTLNfzw==; Date: Mon, 15 Jan 2024 14:46:34 +0200 Message-Id: <83a5p6epcl.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 15 Jan 2024 04:10:16 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Mon, 15 Jan 2024 04:10:16 +0200 > Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca > From: Dmitry Gutov > > >> However it is not easy to quantify confused users looking to understand > >> the new meaning of things in dir-locals.el. Or users wondering why they > >> need to set Eglot variables in both 'c++-mode-hook' and > >> 'c++-ts-mode-hook' when all they see is 'c++-mode' in > >> 'eglot-server-programs'. > > > > Those users will hopefully submit bug reports or otherwise complain on > > the Emacs mailing lists, and then we will know. > > I rather wouldn't rely on that. Why not? The decisions we made are not arbitrary. Given the best consensus (or lack thereof) we could arrive upon after careful consideration of the issues, it is perfectly fine to expect feedback to set us straight if we made a mistake. > > The recommendation is to use base modes where it makes sense, and the > > installed changes around derived-mode-add-parents don't in any way > > preclude having a base mode and don't make it harder. But I don't > > think we should force everyone in this situation to invent a base mode > > as the sole means for solving this. > > It's not like we don't have an existing solution for this: if there are > two different modes to configure, change the settings for both modes, or > alter two hooks. This doesn't solve the problem at hand, since the differences between the modes are not limited to these simple aspects. Less magical and more verbose, but being explicit can > be good. > > >> 2. Explicitly associating some major modes with languages or file types. > >> This doesn't seem hard and other further uses like suggesting modes > >> or packages to a new user based on languages have been proposed. > > > > This is IMO a heavier and more thorough change, especially since Emacs > > doesn't have the notion of "language". This discussion shows that its > > advantages are not evident, and moreover we don't even have a clear > > shared view what will that entail. > > Here's a draft patch of how a "language" could work. It doesn't alter > every entry, but it is backward compatible. Like I said: it is heavier, so we should only do that if the simpler method don't work well enough. So thanks, but let's try the existing simpler solution first and see if we need something better. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 09:46:00 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 14:46:00 +0000 Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPODw-0000ON-D5 for submit@debbugs.gnu.org; Mon, 15 Jan 2024 09:46:00 -0500 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:42122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPODu-0000ET-TV for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 09:45:59 -0500 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2ccea11b6bbso81098581fa.0 for <68246@debbugs.gnu.org>; Mon, 15 Jan 2024 06:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705329953; x=1705934753; 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=xs+O/aoaTZDuVVVBu6X8phJe4O+65ixslU6PrwKa6pE=; b=aSR43HTY6f2iRORohZ42TqWSfBbH9tfXx9ycm92DA/Xc1rsFSA3ydzYe1bRvV0mioz rBtJu8eIOblcHNd6aAAL4Tc/Bf2Z5MPc/10NKFM+FR40702EOMY1l2XRr8iW51vETjCO BZA1V0FPIwNEdz3HZQyyRmqL9tI3KkPtbDiya62VrRBhDLmue9i3WZL8VzNV1cf5H3eE YldWQkH+hpHYW8UzfFDJB/i9PYCxZd1MxYu0FVBQ4FjwOP0f4vuAxYrLDHDMG5Oh5BHE zcrYlU7jrGFm+4jQyM/iisMkOmAOP90KvFJ8LJ/YYPrEfo7MtcWx0ejZBP0sSTWx+XP9 aUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705329953; x=1705934753; 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=xs+O/aoaTZDuVVVBu6X8phJe4O+65ixslU6PrwKa6pE=; b=kR5x5Hrx7NcWqddUNIPSNYnKKlFqRIsCWO7UFDFPKXhu+JN5rF1J9UQjMojjIz9Vpx E7m9znz3AKGjzeM1YPRLfHhGN/plbbMqmRXYOwMsXA3W8/GI71ZsKZc5OW1ROiJaGwNT bzpDAJCrqyfXPdBj4O1Nz6sFZwCax3qpk2bwt4afi5wpbAE/LZoOs5Efc6mvJLPW5Vmp t3FVBaN1P1XjB/aeo85FcCpALZIS8zBx3jmnavzj526WFz8BPq+Gv+WZyJEA9Iq8X4h3 wz6p0QZwpDySvu62ntQ3ztcyHh0kst9ehI9PW0YFNZY65xTjtSsMUz3I5Z2I48BOkKlL 9qaw== X-Gm-Message-State: AOJu0YyGk7z10fPNzyQ3/f/FpwfvEdMQmbvIiAn8e/zIxD4KuEXMjYO/ V9O+U6VfBd/Lw+IeytHxjMVP38Y/5PaOZo1GFH4= X-Google-Smtp-Source: AGHT+IHsVEcf5xp12H00Qo9uxdRWesHOJexk28gQWZyVNPr3M/jD5/c6qzfzWzZ5kJWbFAHYAAruAwByxetT3vozLbQ= X-Received: by 2002:a2e:965a:0:b0:2cd:283b:806f with SMTP id z26-20020a2e965a000000b002cd283b806fmr3631486ljh.12.1705329952876; Mon, 15 Jan 2024 06:45:52 -0800 (PST) MIME-Version: 1.0 References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <871qajfpr2.fsf@gmail.com> <83cyu2eppn.fsf@gnu.org> In-Reply-To: <83cyu2eppn.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 15 Jan 2024 14:45:41 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 15, 2024 at 12:38=E2=80=AFPM Eli Zaretskii wrote= : > It's our only reliable instrument of getting feedback for our > decisions. It's an instrument among others. It's not particularly reliable. > > An empty base mode is useful just for its hook and its behaviour in > > dir-locals, for example. > > No, it is completely useless, and we shouldn't introduce such modes. One more time. The user hook for 'foo-base-mode', which is the normal parent of 'foo-mode', 'foo-ts-mode' and 'foo-whatever-impl-mode' can be used to: * setup a library of snippets for the Foo language.; * define a suitable Flymake backend for said language * appear in dir-locals to setup fill-column for this language * define simpler more robust major-mode database, such as ((foo-base-mode . thingy-42) (js-base-mode . thingy-43) (ruby-base-mode . thingy-45)) * many more things These are exactly the things being discussed here. There is this crystal clear evidence of usefulness being laid in front of you and yet you claim adamantly it is "completely useless". With no justification for the statement. Because of course, there is no such thing. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 09:49:35 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 14:49:35 +0000 Received: from localhost ([127.0.0.1]:45042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOHP-0001S1-0X for submit@debbugs.gnu.org; Mon, 15 Jan 2024 09:49:35 -0500 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:45122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOHN-0001Rp-LK for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 09:49:34 -0500 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2cd2f472665so92453301fa.2 for <68246@debbugs.gnu.org>; Mon, 15 Jan 2024 06:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705330168; x=1705934968; 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=0WJBq9fS7uFbXTpqW4Ztm1iDhMExbScodzh5+2/bj/0=; b=W8+JxzHJvlnWJL1wICJr39d13LeLoSW0kFeQ7iXhKoIzd3FYmdR2K8psYe+VWOkmLe 2HIJlDgPYoLx3fQeXOJW2d8zCnZV/CGKn4B/Dsqc6MIEpJr3eqKd5LUtbMTSORqrZEYE B9rS5YXN/hO1TTjDH5aavJvvsBQkI9Z4GI5BO0Iyzm5z00w2pcj59qNwFZi2o7aW/5d7 XaCdyd86mYsH4dpajmduaA8b6DTL2AD7Vc8N9v/M51KKLlEIhYsu0fdwRqHviGXYVAZg acL+F9QR543RNRioaAd4STWjg3L9E7MGdGUgWZmPtEKCnK8tBc2dLwuKul0Hf5hvlEcC QK/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705330168; x=1705934968; 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=0WJBq9fS7uFbXTpqW4Ztm1iDhMExbScodzh5+2/bj/0=; b=k23zuNHfYWh6EPghQVM0zj7wmvvKPYNVDXyTR6gHoBk76DI3FsnPMJjvYgf7i6qd9r Ps1KOE5T305RMFcZakzQAWUqqnW+xezJBaaV8hsvQCcgYo2XkZx3STejN/8WxIrvxmsG DEP7aEpWKg+6do9se826DsAQYNp9d3RPWo5YTbnIRs0DRmUSTY4Dhpvv4lNLg8bFLu+g i4MSacHZU1tzJBJRF5SBGKcHi6B46n0NENdD46q9tpJPmucBm1S7jKheZJ9b9O9rN5LM 55fB3eQB6UbjhQcJFO9H/3XKygr84MQekSxGXJzUWqKn92WeqxswVa1gomDDYAVz+P40 C5Ug== X-Gm-Message-State: AOJu0Yz+41mQVhaPj5/CtOqU8soed00zQ5LuL2Uo3MnbUhimI9dXaLS8 lLeMGjKhrSsUU2Bwe9mT4vPfBZrjVcctLH6ll7g= X-Google-Smtp-Source: AGHT+IFU49ezcxNvX3pVEwJYDveS6TA3Oton3N2PtHfHaT2BKqFx7Ls3BrKLPjbQ4Teo59wNEuiyGgfRWZtr17NWSsw= X-Received: by 2002:a2e:8096:0:b0:2cd:1647:966 with SMTP id i22-20020a2e8096000000b002cd16470966mr2387506ljg.35.1705330167749; Mon, 15 Jan 2024 06:49:27 -0800 (PST) MIME-Version: 1.0 References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <83frz0fmq8.fsf@gnu.org> <877ckbfqrw.fsf@gmail.com> <83edeiepu9.fsf@gnu.org> In-Reply-To: <83edeiepu9.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 15 Jan 2024 14:49:15 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 15, 2024 at 12:36=E2=80=AFPM Eli Zaretskii wrote= : > > > From: Jo=C3=A3o T=C3=A1vora > > Cc: Yuan Fu , monnier@iro.umontreal.ca, > > 68246@debbugs.gnu.org > > Date: Sun, 14 Jan 2024 23:18:11 +0000 > > > > Eli Zaretskii writes: > > > > >> Now come back to the subject. What we can do now, it seems, is to > > >> apply this on master and observe what breaks? > > > > > > I agree, and Stefan evidently also agrees, since he already installed > > > this on master, with suitable changes to NEWS and the ELisp reference > > > manual. > > > > I don't see the Stefan M's patch to this bug number in either master or > > Emacs 29. > > Start with commit 4194f9bd870, I think. That was added back in November and adds in the derived-mode-add-parents machinery. Uses said machinery in one place, not related to this bug report. So it's not in master yet, and we should continue evaluating alternatives. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 10:00:57 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 15:00:57 +0000 Received: from localhost ([127.0.0.1]:46678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOSO-0003st-PA for submit@debbugs.gnu.org; Mon, 15 Jan 2024 10:00:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOSL-0003gH-VA for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 10:00:54 -0500 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 1rPOSG-0008Km-Ma; Mon, 15 Jan 2024 10:00:48 -0500 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=pEhTimqEW7BP7pZvd5OMtl3C1lecx0JN2EmTJLTVCkU=; b=ZONPZim23DanLbZGPk9f SK+W8oCHRKKji4YmZysWJApNYouzwVUKxtnATUkLrxh2jmEMAr6ljyuJrBRhwICOthrT+h+NzMzG9 q0kpjXdDq0ZNhidohgIPUtKZkBlm7haMwoaSJUm95lBjIbIbchId91PbNBuMrCnu3TTTJQz/5cbH4 Lo1T+yBnrAyIyDRqDuUsWgkMk2McqjD7ItC1XzswBb76RTepIOm9ZRzIeAYDW73D3PSBFT78toePR BsSpH8wkozNaJNx7CpWxZUyHtiPGX2I6P930PUr8Tg+YwoHHwamh2xN9YaoazHvQ+cJhNVojpu1oJ IX+LJT3j3FagNA==; Date: Mon, 15 Jan 2024 17:00:34 +0200 Message-Id: <83zfx6d4kt.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Mon, 15 Jan 2024 14:45:41 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <871qajfpr2.fsf@gmail.com> <83cyu2eppn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Mon, 15 Jan 2024 14:45:41 +0000 > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > On Mon, Jan 15, 2024 at 12:38 PM Eli Zaretskii wrote: > > > It's our only reliable instrument of getting feedback for our > > decisions. > > It's an instrument among others. It's not particularly reliable. You are entitled to your opinions, but mine is different in this matter. > > > An empty base mode is useful just for its hook and its behaviour in > > > dir-locals, for example. > > > > No, it is completely useless, and we shouldn't introduce such modes. > > One more time. Thanks, I understood the first time. I just don't agree with your conclusions. And I already explained why, so at this point let's agree to disagree, again. > There is this crystal clear evidence of usefulness being laid > in front of you and yet you claim adamantly it is "completely > useless". With no justification for the statement. Because > of course, there is no such thing. Right. The stream of ad-hominem and sarcastic nonsense again. Sorry, I forgot that I already bowed out of the attempts to discuss this with you. Mea culpa. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 10:10:02 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 15:10:02 +0000 Received: from localhost ([127.0.0.1]:46694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPObC-000512-1E for submit@debbugs.gnu.org; Mon, 15 Jan 2024 10:10:02 -0500 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:56704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPObA-00050Q-0y for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 10:10:00 -0500 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cd0d05838fso99634781fa.1 for <68246@debbugs.gnu.org>; Mon, 15 Jan 2024 07:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705331394; x=1705936194; 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=opErljv9Yjvy8XEoaFITZl6q5khmUWuKe/eubQi2IbQ=; b=Ptyh3yU9r2fXo/E2oQ3XmSyNrZF1HIsCT/BDqC+0zpJd6tJj1V04ZA1C07NpHKkRaU m1rNdzUyC1oplTJBq8BdkZH0YE41OrrfYhGOu3uDm5Oc9tRYBYvv1FXDKcZSjA8yWoMi bD24qWIq0iERoB+dKk2PeOxdvBV/HC5iTk0LOaNJxgYGz0924bm+3FXcF73g58ooPN2h HqG5kqzO7DgaMY15vBa5qfmM8DbQ4R+o5mF7lWAqI4v/6uq22wOaqyy72aHrpAGQ63LD cBjvf/ToP/5WVAWeeG3nQdW+95X3bRBNGbdqvwFKM6lqqXwcJvgaIfD3hr/PyheS5RYT qzVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705331394; x=1705936194; 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=opErljv9Yjvy8XEoaFITZl6q5khmUWuKe/eubQi2IbQ=; b=oK7PSZxiaQ0jJapWgl59xM4UXp8CDRDflrIoS3YCtJXNoCEJkwHf0LxoE+e7RRRgTr 3Z9aGMDFcYim2kLHYwtPcnGLyKzbFct8Xte8z9PmFt9GHFzTWKa8iYryVYt1TrRKJ6zx gDXApPQqEICKL2ORwbs2FM2I7W59OVfWuTdc/cuXfjn7Wc2uFbuLUIIrMm4KITC7od81 1OC3cXo5ih25kS4o7BPiAf0fuVGnLfwIeeQgxHGTXHjJpgwez0nyAoGua8uwPcVIWWx9 Le0T3UpdBsfvbs9NaG0q1+4Z7MNb1BxZuxfFMisYq0uwA+5gPd7Pz4z5dZZupM83gp7o 1jvw== X-Gm-Message-State: AOJu0YzW3KFvDSiVgWyCOvEMGuy4koOrQZtvC4ckZnm9bXK/Snots/xL ffYK7+4MjjdhHwnXiW+4kAodUoMftvi5H0VaS5i0aKn6P0M= X-Google-Smtp-Source: AGHT+IE9yWFXnw8NLOF2hs/voBbz+gDE3xXjcX82GzFUNFGYSTzgSYPWsnceRtn5keWduOCpulVWDnC801hv6AgZeB4= X-Received: by 2002:a2e:3813:0:b0:2cd:46c1:fd97 with SMTP id f19-20020a2e3813000000b002cd46c1fd97mr2626980lja.36.1705331394058; Mon, 15 Jan 2024 07:09:54 -0800 (PST) MIME-Version: 1.0 References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <871qajfpr2.fsf@gmail.com> <83cyu2eppn.fsf@gnu.org> <83zfx6d4kt.fsf@gnu.org> In-Reply-To: <83zfx6d4kt.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 15 Jan 2024 15:09:42 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jan 15, 2024 at 3:00=E2=80=AFPM Eli Zaretskii wrote: > Thanks, I understood the first time. I just don't agree with your > conclusions. And I already explained why, so at this point let's > agree to disagree, again. There's not much open to interpretation of what "useful" means here. But by all means go ahead and justify what you think these hooks, dir-locals use cases, and other features are "completely useless". You haven't done that. > > There is this crystal clear evidence of usefulness being laid > > in front of you and yet you claim adamantly it is "completely > > useless". With no justification for the statement. Because > > of course, there is no such thing. > Right. The stream of ad-hominem and sarcastic nonsense again. Sorry, > I forgot that I already bowed out of the attempts to discuss this with > you. Mea culpa. That was most obviously not sarcastic. And calling my posts where I give actual evidence of things "nonsense" (which you have done twice now) is, I'm fairly sure, the true ad-hominem here. Unsarcastically yours, Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 10:27:26 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 15:27:26 +0000 Received: from localhost ([127.0.0.1]:46705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOs2-00084p-CA for submit@debbugs.gnu.org; Mon, 15 Jan 2024 10:27:26 -0500 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:43426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPOrz-00084b-Ub for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 10:27:24 -0500 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cd04078ebeso91042171fa.1 for <68246@debbugs.gnu.org>; Mon, 15 Jan 2024 07:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705332438; x=1705937238; 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=BWspocRlxCdFO7dR9ol+Y5pI3+NE87yAkOByuEsHtTc=; b=e4IMrxkNmUFRPHGGcKizCpvn0g62K3neOYwdEgPHYl/rCcxk41YG2BRTuk7mDYi8t4 rvy4ej3dr27MwzzZUxNMYRorhRFUz2fBlTuUbOmNCEY6OpMKbIt7l/WWzl7ju6Otvgdt 9yOA01wmFMJH81O07pEGxnLHac0eBmIT+kcgErK2b2UQ0Zw+6GrtPTaMMtmOzFm+wh/y 9jgRFIFumu/7S8dpfzNAeo3Ve+KRQr8HBOKLfaBo67cmj0bm0lNqoPNDzenepq6c3GTY YupMfESvHABIy74KEf9g7zt7hgORP1vl3U0DINiY2Ie8nCTcRXdZJO6nSzDNnAfC+cnU 0EYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705332438; x=1705937238; 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=BWspocRlxCdFO7dR9ol+Y5pI3+NE87yAkOByuEsHtTc=; b=ciooEA2bsGxqYiHsYUVrPuVgtbFCTyxfVkAyNmf6VQlfB08Ag5e0ZbUAYa+0D70a1J 3fPDAT0R2QUV5XYuuJzOuTzlWQy9N+DaIa1bUw94DLc2vEyxpMeCtKX0fioQz/ugkx4v S4eZVqqjCheu0kE2F5ve4UdyhZynIv5eqZp5Qe+18QteLthKY938MYZF11j/pPHkO900 BhAm4P6qUYAikOCt2XMyt0qY/LKnyp/9UBl9AvdqiGngh1WZr9gNtZn9lrfGxhdFjaDx buqYYGCuX/Pjm76wXt2yOiL4c1FrjtJZLQatXZtHt1E+cU6CV9+QYG6QCZMExZjc00tn t2uw== X-Gm-Message-State: AOJu0YzuBk0ZbCwoXap+0XROu7r+o/lPrjoWTtXWHTJHooIE7QyYumQW hOnsNlV1m+344yfT8t94YayBYspwH/MiWOh8HaU= X-Google-Smtp-Source: AGHT+IHqwBXfTJYUADe3QURVT2wJFKbOI8icJ6HEbj/PPddzw9AY4SC3QVLprjQbrzKAYeLPkev2jCwzvi00ezmD7Q8= X-Received: by 2002:a2e:a54c:0:b0:2cd:8dda:e15c with SMTP id e12-20020a2ea54c000000b002cd8ddae15cmr4677030ljn.1.1705332437784; Mon, 15 Jan 2024 07:27:17 -0800 (PST) MIME-Version: 1.0 References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 15 Jan 2024 15:27:05 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Mon, Jan 15, 2024 at 2:10=E2=80=AFAM Dmitry Gutov wro= te: > > It's not like we don't have an existing solution for this: if there are > two different modes to configure, change the settings for both modes, or > alter two hooks. Less magical and more verbose, but being explicit can > be good. I don't think there's anything magical about a base mode. But I like your solution too. > Here's a draft patch of how a "language" could work. It doesn't alter > every entry, but it is backward compatible. I think something like this can work, yes. - (funcall (alist-get mode major-mode-remap-alist mode)) + ;; XXX: When there's no mapping for `:', we could also + ;; look for a function called `-mode'. + (funcall (alist-get mode major-mode-remap-alist (if (keywordp mode) + #'fundamental-mo= de + mode))) + (when (keywordp mode) ;Perhaps do that unconditionally. + (run-hooks (intern (format "%s-language-hook" (buffer-language))))= ) (unless (eq mode major-mode) Regarding the "XXX", this is basically the same questions in the two headings, I think, which is whether to consider the in existing -mode as language. I think we can do it yes. Eglot and other packages [*] have been doing it for quite some time. It will fail very rarely, only for major modes outside Emacs (like "tuareg-mode" for Ocaml) and we can probably fix that in-tree. The only thing that leaves me some doubts is the 'set-buffer-language' entry point. It's a new thing not strictly required. Normally the databases are edited (via whatever means) and then the buffer is reverted for a mode change. So I don't think we need to introduce this user convenience just yet (though, like the other user conveniences you have imagined, I'm not necessarily opposed to it). Also 'buffer-language' could be 'get-mode-language', so you don't have to have an actual buffer handy to get this association. The implementation would just be a reverse search in major-mode-remap-alist Other than that, I think the solution is workable. The other package [*] that does exactly the same thing as Eglot, and invented it independently is markdown-mode: (defun markdown-get-lang-mode (lang) "Return major mode that should be used for LANG. LANG is a string, and the returned major mode is a symbol." (cl-find-if #'markdown--lang-mode-predicate (nconc (list (cdr (assoc lang markdown-code-lang-modes)) (cdr (assoc (downcase lang) markdown-code-lang-modes))) (and (fboundp 'treesit-language-available-p) (list (and (treesit-language-available-p (intern lang)) (intern (concat lang "-ts-mode"))) (and (treesit-language-available-p (intern (downcase lang))) (intern (concat (downcase lang) "-ts-mode"))))) (list (intern (concat lang "-mode")) (intern (concat (downcase lang) "-mode")))))) It uses this to know what major-mode to use to fontify GitHub style markdown code blocks (which have a little language cookie after the three backticks). Like Eglot's similar code, I think it could be trivially rewritten if something like your patch were in place. Bug#68217 is also relevant here. Eglot calls into markdown-mode.el to fontify LSP documentation snippets and sometimes the mode picked by markdown-mode.el to do the fontification is not the same the user is using for the buffer. It most clearly should be. So get-language-for-mode and get-(preferred)-mode-for-language are two evidently needed helpers. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 13:32:42 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 18:32:42 +0000 Received: from localhost ([127.0.0.1]:46821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRlJ-0005Of-Ie for submit@debbugs.gnu.org; Mon, 15 Jan 2024 13:32:42 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:48045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRlH-0005OS-I7 for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 13:32:40 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 358063200ADF; Mon, 15 Jan 2024 13:32:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 15 Jan 2024 13:32:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705343552; x=1705429952; bh=pOBQ8sK1RYybQPI+vwSm4mQrAgnYllpIxs80rCHoZNg=; b= DkCrSVlQwdJBXl1bq7LxREVamfzdQJC6iHSKmpS9sualA6UYGtL+iwiROoaPIHC2 0XacE/nT04AmHw9RQmvTLHq2nsogV3m2Gx3vzWxJJw9hlDF9cFpJfc6Trn2E0gZc zcbZmSEQ01GaEXm7b9PPbY6lsUjQ6KDKfVqEm6S+4aRegYCYTQYIc1p5sCFjSVH5 dX5HG3esyHQ8ShnDsJSFVTQsvIPHiVmvcfto6L63sRutzEU1bPcn4SuUU846Hxml cRiVhdvizQdaA0jXV8gtFtbPFnQatEAre6rMhYhg9dezsyxVKEuA9ubaRp3ufs8I qHKCQBrBN50dGOt4iGmPgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705343552; x= 1705429952; bh=pOBQ8sK1RYybQPI+vwSm4mQrAgnYllpIxs80rCHoZNg=; b=g M2PczBl1AmBtFWHzQCak/keUSOQewGbUTaMXnmZBJzS3dOh/qI3MAr1Hc+RnmgYe 0KozVZkGVh98xCRuaKGXUpZq8R7CIX+9C2t6n5fXIUO/00Rz6f9+HAhWtsc/9AmZ 8WDc1JK9AHlHItp2ZWPckoX8NoioHlXhTILqIvCFlx2Ts9+hWyMtoyQEEhjWwUSP lpBsiDmm3LgCXdotA0AN7bfLJaLkjXQOmGW0GHAfv4QLSMajLkkdkBZeJGmmudQf yIEeRjAzVHNFloGFIA/FBZBqhL30Wia8aiC6rBp5y9fOY7G6EvkmlrwW371DW6F+ 9LS5+D/U704+7R0Mdfc/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 13:32:30 -0500 (EST) Message-ID: <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> Date: Mon, 15 Jan 2024 20:32:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <83a5p6epcl.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83a5p6epcl.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15/01/2024 14:46, Eli Zaretskii wrote: >> Date: Mon, 15 Jan 2024 04:10:16 +0200 >> Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >>>> However it is not easy to quantify confused users looking to understand >>>> the new meaning of things in dir-locals.el. Or users wondering why they >>>> need to set Eglot variables in both 'c++-mode-hook' and >>>> 'c++-ts-mode-hook' when all they see is 'c++-mode' in >>>> 'eglot-server-programs'. >>> >>> Those users will hopefully submit bug reports or otherwise complain on >>> the Emacs mailing lists, and then we will know. >> >> I rather wouldn't rely on that. > > Why not? The decisions we made are not arbitrary. Given the best > consensus (or lack thereof) we could arrive upon after careful > consideration of the issues, it is perfectly fine to expect feedback > to set us straight if we made a mistake. Because the corresponding downsides are already known. They are not catastrophic ones, however, and as such they won't be critical in day-to-day usage (prompting fewer users to bother with bug reports). And if one builds a chair with 5 legs, it will likely be not as convenient to use, but not many people will go and tell the author that the chair has an extra leg - it's obviously intentional. Nor we are quick to change our mind based on such feedback, as bug#61177 and bug#61177 demonstrate. >>> The recommendation is to use base modes where it makes sense, and the >>> installed changes around derived-mode-add-parents don't in any way >>> preclude having a base mode and don't make it harder. But I don't >>> think we should force everyone in this situation to invent a base mode >>> as the sole means for solving this. >> >> It's not like we don't have an existing solution for this: if there are >> two different modes to configure, change the settings for both modes, or >> alter two hooks. > > This doesn't solve the problem at hand, since the differences between > the modes are not limited to these simple aspects. I don't understand your response. The original description says: packages tend to behave poorly because they do not understand that a buffer in `js-ts-mode` contains Javascript Presumably, a call like (derived-mode-p 'js-mode) fails. The packages can change it to (derived-mode-p '(js-mode js-ts-mode)), and it will succeed. Yes, it's a bit more work, but they will have to do it anyway to support Emacs 29.1 for a number of years. > Less magical and more verbose, but being explicit can >> be good. >> >>>> 2. Explicitly associating some major modes with languages or file types. >>>> This doesn't seem hard and other further uses like suggesting modes >>>> or packages to a new user based on languages have been proposed. >>> >>> This is IMO a heavier and more thorough change, especially since Emacs >>> doesn't have the notion of "language". This discussion shows that its >>> advantages are not evident, and moreover we don't even have a clear >>> shared view what will that entail. >> >> Here's a draft patch of how a "language" could work. It doesn't alter >> every entry, but it is backward compatible. > > Like I said: it is heavier, so we should only do that if the simpler > method don't work well enough. So thanks, but let's try the existing > simpler solution first and see if we need something better. Indeed it's heavier because it's not just a fix, but a whole new feature. I suggest people try it out and see how they like it. If not, well... From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 13:52:53 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 18:52:53 +0000 Received: from localhost ([127.0.0.1]:46846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPS4q-0000Am-Lo for submit@debbugs.gnu.org; Mon, 15 Jan 2024 13:52:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPS4o-0000AZ-EU for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 13:52:51 -0500 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 1rPS4i-000304-On; Mon, 15 Jan 2024 13:52:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=uRbZQmUYWFDydCpBgPvTIu2TtIzpt1Zr1zjCymA6V1w=; b=PDp+KU+vWMZw f3IJAgmHPTusRFet/x95vjM9LsbMmDOtUXgXhe1KpJrpYwlvu8enO130WJdC8pK2kq8iCkRfrMfOJ 9eftLQFqSZpDKpdh1f0Yq3uc6qc3r9iDhD2oK7v4AGymYlocwASz6J68kd6MwuxR7ANMcXpqYGswX T+zpBsjqlF44a90pK49EoAY3z47dcrFUdh0IPnuQiAbyxguC4RH0AV+dEXO6vr7gU3DKpOYSkqORw BiuyS2NaD55cMPnrODU/hg/FYePlNKSXT26iqmhkYZvp94CPSTZXt+PMx6KlV8VEQZ1IEoTLjrkzZ pXzGhDYerF7w8N61zgJOxQ==; Date: Mon, 15 Jan 2024 20:52:30 +0200 Message-Id: <83sf2yctu9.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> (message from Dmitry Gutov on Mon, 15 Jan 2024 20:32:27 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <83a5p6epcl.fsf@gnu.org> <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Mon, 15 Jan 2024 20:32:27 +0200 > Cc: joaotavora@gmail.com, stefankangas@gmail.com, 68246@debbugs.gnu.org, > casouri@gmail.com, monnier@iro.umontreal.ca > From: Dmitry Gutov > > >>> Those users will hopefully submit bug reports or otherwise complain on > >>> the Emacs mailing lists, and then we will know. > >> > >> I rather wouldn't rely on that. > > > > Why not? The decisions we made are not arbitrary. Given the best > > consensus (or lack thereof) we could arrive upon after careful > > consideration of the issues, it is perfectly fine to expect feedback > > to set us straight if we made a mistake. > > Because the corresponding downsides are already known. And so are the advantages. And from where I stand, the advantages outweigh the known downsides. > They are not catastrophic ones, however, and as such they won't be > critical in day-to-day usage (prompting fewer users to bother with > bug reports). Once again: we should try the simpler, light-weight solution before we go to more complex ones. > And if one builds a chair with 5 legs We don't build a chair with 5 legs, so the analogy misses the point. > Nor we are quick to change our mind based on such feedback, as bug#61177 > and bug#61177 demonstrate. We are as quick as possible. You are welcome to step up as an Emacs maintainer and improve these aspects if you can. > >>> The recommendation is to use base modes where it makes sense, and the > >>> installed changes around derived-mode-add-parents don't in any way > >>> preclude having a base mode and don't make it harder. But I don't > >>> think we should force everyone in this situation to invent a base mode > >>> as the sole means for solving this. > >> > >> It's not like we don't have an existing solution for this: if there are > >> two different modes to configure, change the settings for both modes, or > >> alter two hooks. > > > > This doesn't solve the problem at hand, since the differences between > > the modes are not limited to these simple aspects. > > I don't understand your response. Then you will have to re-read all the discussions which led to separate modes, and re-discover the problems we discovered almost a year ago. The current arrangement was not an accident and not happened by default. It is the best arrangement we could come up with given the differences between the TS and non-TS modes. Where the differences are relatively small, we either have a significant base mode or something similar. But in several important cases that is impractical, so we don't. > The original description says: > > packages tend to behave poorly because they do not understand that a > buffer in `js-ts-mode` contains Javascript A major mode doesn't need to "understand" anything, it needs to support users as the users expect. > >> Here's a draft patch of how a "language" could work. It doesn't alter > >> every entry, but it is backward compatible. > > > > Like I said: it is heavier, so we should only do that if the simpler > > method don't work well enough. So thanks, but let's try the existing > > simpler solution first and see if we need something better. > > Indeed it's heavier because it's not just a fix, but a whole new > feature. I suggest people try it out and see how they like it. I think such a feature is unjustified by what we know about the problem. If we don't know enough, we will learn soon enough, and will then be in a position to make informed decisions, unlike now that we are arguing about issues we don't yet have enough experience about to be able to discuss usefully and effectively. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 15:18:09 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 20:18:09 +0000 Received: from localhost ([127.0.0.1]:47088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTPN-0001bu-1u for submit@debbugs.gnu.org; Mon, 15 Jan 2024 15:18:09 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:43721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTPK-0001b6-Nr for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 15:18:07 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id 7B96E3200B23; Mon, 15 Jan 2024 15:18:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 15 Jan 2024 15:18:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705349879; x=1705436279; bh=jyLFx+wbxfiSrKkwUV5FdkGs9wydpWvI4w7STRjvJAA=; b= a75fBvVntPEsc38Lj7T9KSw80XqdiBKxB2AMfxSnpmLEUqV/QEiPn9+b9fKF4CmJ 8ZBOF6bILCvlG2y7pKVOt/kvwqL1697pWc1orsTbFVruRnpaOBva44RBr76XMPow J/O7C1Bezhjv9RHpFpHvmr7UnqqfC7A0y6YbBYTjW4vIiraoEwwIYlw9nxouYzJZ xC1FqzqXCdeW/PR6zqZgsZABHSNgfh1MrS1MrrA5UkVaseHH6MLZj03ntsfsJjur DmlbF0EYaz1vGSDYrg90PXPjW8fgemW8P3SEQOS3VgamWhSdEftVEQIvUvIyQ4Ju Bu9QfrW2VAeom174id+UPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705349879; x= 1705436279; bh=jyLFx+wbxfiSrKkwUV5FdkGs9wydpWvI4w7STRjvJAA=; b=I rdLfDG9bQLd3uKZdnTf2NQdiBZmHx8aIAv8y5Bp3cba+2X7xRSsm5Ni4zk3YYoPq LdwJs1uamcI6xTr4hbJs0WHs3B4Dh+PzWmhyx7PpOupsT8N2A65y/QbQYl/8hpKo srxxRpH4Vn/diz/ieq7wdDcGA3i8hy/A95MJ5xXEIK8BF9aKxDwxuplO0T6STD9T mg24KtJ8a2NHFtwnoukB56ujWEKqHJLLqZ4BqnSWGu4pmwV745W1juHiK455uXTm 42Lkay53FyJC4yhfpUmnTP/jJUngKmDOCRe/gQEHSmJKyzW4SfPbwafMggu8CV48 VeDiD1DvQN+b2tPHtLDRA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 15:17:58 -0500 (EST) Message-ID: Date: Mon, 15 Jan 2024 22:17:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <83a5p6epcl.fsf@gnu.org> <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> <83sf2yctu9.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83sf2yctu9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15/01/2024 20:52, Eli Zaretskii wrote: >> They are not catastrophic ones, however, and as such they won't be >> critical in day-to-day usage (prompting fewer users to bother with >> bug reports). > > Once again: we should try the simpler, light-weight solution before we > go to more complex ones. A change in inheritance chain is a pretty heavy/complex solution in my book. >> And if one builds a chair with 5 legs > > We don't build a chair with 5 legs, so the analogy misses the point. When a certain behavior is obviously intended, you don't always report is as a bug. Sometimes you sigh deeply and either continue using the tool, >> Nor we are quick to change our mind based on such feedback, as bug#61177 >> and bug#61177 demonstrate. > > We are as quick as possible. You are welcome to step up as an Emacs > maintainer and improve these aspects if you can. I didn't mean that the speed was the issue here. The bugs above are closed as "wontfix", rather than remaining in-progress. >>>>> The recommendation is to use base modes where it makes sense, and the >>>>> installed changes around derived-mode-add-parents don't in any way >>>>> preclude having a base mode and don't make it harder. But I don't >>>>> think we should force everyone in this situation to invent a base mode >>>>> as the sole means for solving this. >>>> >>>> It's not like we don't have an existing solution for this: if there are >>>> two different modes to configure, change the settings for both modes, or >>>> alter two hooks. >>> >>> This doesn't solve the problem at hand, since the differences between >>> the modes are not limited to these simple aspects. >> >> I don't understand your response. > > Then you will have to re-read all the discussions which led to > separate modes, and re-discover the problems we discovered almost a > year ago. The current arrangement was not an accident and not > happened by default. It is the best arrangement we could come up with > given the differences between the TS and non-TS modes. Where the > differences are relatively small, we either have a significant base > mode or something similar. But in several important cases that is > impractical, so we don't. Perhaps I should clarify that my preferred alternative solution is not base modes, but "keep things as is". The same current arrangement you mention. >> The original description says: >> >> packages tend to behave poorly because they do not understand that a >> buffer in `js-ts-mode` contains Javascript > > A major mode doesn't need to "understand" anything, it needs to > support users as the users expect. I would be best to address the technical approach I mentioned rather than pick at the phrasing in a sentence that doesn't belong to me. >>>> Here's a draft patch of how a "language" could work. It doesn't alter >>>> every entry, but it is backward compatible. >>> >>> Like I said: it is heavier, so we should only do that if the simpler >>> method don't work well enough. So thanks, but let's try the existing >>> simpler solution first and see if we need something better. >> >> Indeed it's heavier because it's not just a fix, but a whole new >> feature. I suggest people try it out and see how they like it. > > I think such a feature is unjustified by what we know about the > problem. If we don't know enough, we will learn soon enough, and will > then be in a position to make informed decisions, unlike now that we > are arguing about issues we don't yet have enough experience about to > be able to discuss usefully and effectively. It doesn't seem to me like that experiment is easy to reverse. And I'm not sure what is unclear about the problem, to require additional data. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 15:28:05 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 20:28:05 +0000 Received: from localhost ([127.0.0.1]:47112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTYz-0001sq-Cr for submit@debbugs.gnu.org; Mon, 15 Jan 2024 15:28:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTYw-0001sK-SJ for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 15:28:04 -0500 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 1rPTYr-00020Q-It; Mon, 15 Jan 2024 15:27:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xUsp/KhZrEIgQmEGqn98YWD/yq2g0C5XIQObowDKy2Q=; b=L8b/eOa8tR47 IBIdwvKRhQh9479XlROaFGXuKaxSImgn3cgnJPB1QiA8f/PDgmMPgBnal4qYA5IeZkHxcBC6zQ1L8 qrZvV8N5DJ6V+cpRhNwInHIhNuzgJ0wwyQX7Qt6ZwPm11jK7a05MK6QtM2iMpqFNIvevDToufeCw9 kcPfjAh8IFYqezH9L+W1tQkSasLl4OVHzfMTPoPbE+ccyrzfGR0KM5w2zmdkTGiFKIpP/Un4nh3Zd 9PeYjzRFsWbY+oqJyw4TJ5b8bHRtONKoYLNGhUXyChUBd7DBZbqueLeP1+7oG5houz9uZa6d8Rzx3 tc99w2AhSpcHSiHXJs0M9A==; Date: Mon, 15 Jan 2024 22:27:44 +0200 Message-Id: <83le8qcpfj.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 15 Jan 2024 22:17:56 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <83a5p6epcl.fsf@gnu.org> <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> <83sf2yctu9.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Mon, 15 Jan 2024 22:17:56 +0200 > Cc: joaotavora@gmail.com, stefankangas@gmail.com, 68246@debbugs.gnu.org, > casouri@gmail.com, monnier@iro.umontreal.ca > From: Dmitry Gutov > > On 15/01/2024 20:52, Eli Zaretskii wrote: > > >> They are not catastrophic ones, however, and as such they won't be > >> critical in day-to-day usage (prompting fewer users to bother with > >> bug reports). > > > > Once again: we should try the simpler, light-weight solution before we > > go to more complex ones. > > A change in inheritance chain is a pretty heavy/complex solution in my book. Stefan's addition doesn't change the inheritance chain. > >> Nor we are quick to change our mind based on such feedback, as bug#61177 > >> and bug#61177 demonstrate. > > > > We are as quick as possible. You are welcome to step up as an Emacs > > maintainer and improve these aspects if you can. > > I didn't mean that the speed was the issue here. The bugs above are > closed as "wontfix", rather than remaining in-progress. Same answer. > > I think such a feature is unjustified by what we know about the > > problem. If we don't know enough, we will learn soon enough, and will > > then be in a position to make informed decisions, unlike now that we > > are arguing about issues we don't yet have enough experience about to > > be able to discuss usefully and effectively. > > It doesn't seem to me like that experiment is easy to reverse. If there are good reasons, we will. > And I'm not sure what is unclear about the problem, to require > additional data. Additional downsides, if any. If there are none, then we already have a solution that I consider satisfactory. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 15:51:45 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 20:51:45 +0000 Received: from localhost ([127.0.0.1]:47127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTvs-000832-R6 for submit@debbugs.gnu.org; Mon, 15 Jan 2024 15:51:45 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:47463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTvq-00082o-HF for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 15:51:43 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D96313200A91; Mon, 15 Jan 2024 15:51:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 15 Jan 2024 15:51:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705351895; x=1705438295; bh=2L9ZiGhm7W9CW/keZXLDJIvwlt+DIqMKzg44s3FXShY=; b= QlR4YqedBT/IHl29AYQAoVnQ/AStVzhrUzIMHHuMLboMij3RlQw/8ALMlZfQE5kF iwqKQVcfZsB5PmLfKBg4NP/TPF/qFWt/KiQA5LtiyYftDD6RRAQlOujVDko0rUcq q2TR4j2SaBx5QAvcs8/Bpoaw7JMIdY4g3m11O6SYRte42eWB8+d2HQnTjixZuHxj phyAcBkMqNhqo+1ZxusifVTLf9mnl4DGTS9XBnRRRuPAvFj4R1HuxfyTgIDZfge3 iCH34n5Z1J4/gRJuBtR53gyqxeXsua6jBHPFsWv1WjUsYUbiu01fG0B0euL41h4l NXkyb1N6oy5VE/jkTxQpZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705351895; x= 1705438295; bh=2L9ZiGhm7W9CW/keZXLDJIvwlt+DIqMKzg44s3FXShY=; b=y t8PwCe4NlDLhnen++J4giIgetgMBjo21Tgfo77dQYrm4/dPN7HrIdpqvwqcS0Vx1 CieNKpsfsBV70tYnLe/KvdSgn5Nhcj+80HoiIp3A7FzaWyFbIc7m++6vEo9PIRx4 Z72HxNFmHmj6VsFf1VyqwqH7hqG6IW8y1YF+9/jbhCCJMMVb3wFaVi6DEATC/kDd /UymfDUrQXdBcLyUxf8/umWu1Gy+FLTnWxF74yv5m6Cu8rAGYBYp8/t76WNqg30K GKKZl68VadKFEYNu77Hz8EIdb6ZsnwsGCEBHnciTaU2AAxYxo/kegitwlf+hkJDy 5t9W1Co3mw72vYoPKt4vw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeegleefteekgffhvdfhtdegveevveetteegteevgeettdehhfdukeetheff ueekkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 15:51:33 -0500 (EST) Message-ID: Date: Mon, 15 Jan 2024 22:51:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15/01/2024 17:27, João Távora wrote: > On Mon, Jan 15, 2024 at 2:10 AM Dmitry Gutov wrote: >> > >> It's not like we don't have an existing solution for this: if there are >> two different modes to configure, change the settings for both modes, or >> alter two hooks. Less magical and more verbose, but being explicit can >> be good. > > I don't think there's anything magical about a base mode. But I like your > solution too. As "magical", I meant the original patch for this report. I wouldn't mind the "base mode" approach, but I guess its still suffers from not being suitable for using with earlier Emacs versions. And every programming mode will have to come with -base-mode defined, otherwise we'll have to revisit this every time a new third-party -ts-mode appears. >> Here's a draft patch of how a "language" could work. It doesn't alter >> every entry, but it is backward compatible. > > I think something like this can work, yes. > > - (funcall (alist-get mode major-mode-remap-alist mode)) > + ;; XXX: When there's no mapping for `:', we could also > + ;; look for a function called `-mode'. > + (funcall (alist-get mode major-mode-remap-alist (if (keywordp mode) > + #'fundamental-mode > + mode))) > + (when (keywordp mode) ;Perhaps do that unconditionally. > + (run-hooks (intern (format "%s-language-hook" (buffer-language))))) > (unless (eq mode major-mode) > > Regarding the "XXX", this is basically the same questions in the > two headings, I think, which is whether to consider the in existing > -mode as language. I think we can do it yes. Eglot and other > packages [*] have been doing it for quite some time. It will fail very > rarely, only for major modes outside Emacs (like "tuareg-mode" for > Ocaml) and we can probably fix that in-tree. It's a choice between embedding the implicit logic here, or returning nil and allowing the callers to do their own fallbacks. I'm not sure, personally, which is the better. One might be convenient, but the other more strict, possibly leaning to fewer defects. This choice is coupled with the corresponding logic in 'buffer-language' (whether to keep the replace-regexp-in-string branch). > The only thing that leaves me some doubts is the 'set-buffer-language' > entry point. It's a new thing not strictly required. Normally the > databases are edited (via whatever means) and then the buffer is > reverted for a mode change. So I don't think we need to introduce > this user convenience just yet (though, like the other user conveniences > you have imagined, I'm not necessarily opposed to it). I was thinking of what would be required to make "language" a first-class entity, so that users could interact with them instead of major modes. To prove the validity of the feature. Because it's something that people do (I, at least): invoke the major mode to choose a different language/content-type for a buffer (one not visiting a file yet, perhaps). And if we have an abstraction over mmodes, it would make sense to use it. The interactive behavior of set-buffer-language seems to justify it, I think: when you try to enable a major mode, you get all the session's functions as completions. But 'M-x set-buffer-language TAB' gives you a neat and tidy list of known languages, it's a tangible improvement. > Also 'buffer-language' could be 'get-mode-language', so you don't > have to have an actual buffer handy to get this association. The > implementation would just be a reverse search in major-mode-remap-alist This makes it dependent on the major mode already being applied. Which is a valid strategy, but then it can't be used in the last two features from my list ("Further possible additions") - they're about the case when there is no major mode defined. > Other than that, I think the solution is workable. > > The other package [*] that does exactly the same thing as Eglot, and > invented it independently is markdown-mode: > > (defun markdown-get-lang-mode (lang) > "Return major mode that should be used for LANG. > LANG is a string, and the returned major mode is a symbol." > (cl-find-if > #'markdown--lang-mode-predicate > (nconc (list (cdr (assoc lang markdown-code-lang-modes)) > (cdr (assoc (downcase lang) markdown-code-lang-modes))) > (and (fboundp 'treesit-language-available-p) > (list (and (treesit-language-available-p (intern lang)) > (intern (concat lang "-ts-mode"))) > (and (treesit-language-available-p (intern > (downcase lang))) > (intern (concat (downcase lang) "-ts-mode"))))) > (list > (intern (concat lang "-mode")) > (intern (concat (downcase lang) "-mode")))))) > > It uses this to know what major-mode to use to fontify GitHub style > markdown code blocks (which have a little language cookie after the > three backticks). Like Eglot's similar code, I think it could be trivially > rewritten if something like your patch were in place. Yup, it could use the entries in major-mode-remap-alist. > Bug#68217 is also relevant here. Eglot calls into markdown-mode.el > to fontify LSP documentation snippets and sometimes the mode picked > by markdown-mode.el to do the fontification is not the same the user > is using for the buffer. It most clearly should be. So > get-language-for-mode and get-(preferred)-mode-for-language are two > evidently needed helpers. Are there specific uses for get-mode-for-language when there is no existing buffer? Hmm, I suppose it could be the better option when either the current buffer is not visiting a file (but you want to have code completion in it anyway), or the user switched to a different major mode explicitly, one that does not correspond to buffer-file-name in the current configuration. We could have both functions: buffer-language and get-language-for-mode ('get-mode-language'?). Or define one initially and add the other as needed. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 18:12:15 2024 Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 23:12:15 +0000 Received: from localhost ([127.0.0.1]:47249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPW7r-0002Jk-3B for submit@debbugs.gnu.org; Mon, 15 Jan 2024 18:12:15 -0500 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:49267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPW7o-0002JX-EP for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 18:12:13 -0500 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd880ceaf2so51318481fa.2 for <68246@debbugs.gnu.org>; Mon, 15 Jan 2024 15:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705360326; x=1705965126; 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=V8tP1/XLGKv1Tbra/8yoe7FpHvEV0dB8La/+HOQn8hI=; b=BhBXsN9PRGpVsTO1cRu4wUwCRhtjsJUuCEg5LDIIeri9R3ID/cnXIPNU0E9WKV+GBw vOETGSpgMT5HKWb46tt08AdtWoKZ0eHRhWQtojjinJKTv/h2CEYqkpfdCdQVoDtSBL0l 6XXG7Dv+UFF0KO1b72jdOY1XzL52CA/x3NuX5YYNYoXWMYK8iw24g5PYH73zg5Rnnb+5 X75mhRtGfwbCkGK6Hyij4Y3xxhO/cCoNU1FrLD4C7pCM1VvDu5gOYniTyBPG6yk89JTz 7d+5bofrIihobxICjqz0HRkXx0HkwD78aB6ss15kRFmGbbvl+EvCe/JGu3o6Mcifm7tX SaZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705360326; x=1705965126; 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=V8tP1/XLGKv1Tbra/8yoe7FpHvEV0dB8La/+HOQn8hI=; b=XXl8uQ/8/CAzbn4gjn/tcm4967hp41pVEYddql38CIDSAbUmEs5ycN6mPWvv9U2iAG 9GUBi8JY0VClPfhVsvowhHFEV4U6dBfZnAhhvG14E/qWa5icq9P0MR2kSQUgIigvUfsL Pv7M0QDsRLLEkXtNWiJIrbFHx/a4KXzIX7k0ZGXxCFZTAeXxPc8+56HXVgCcH6wJ2d9B VEnUXHMF90J/OEslMICtDL/OVVqXDoVhAlVPca4tEVBWJM+jpeiG00FZeL031gdhuacp mrkOsRAcgKi7pnQSItCFsSEBTT/VBpJsq6CVzwhAkuw2nvq/21UZukHrUfKDW2dvt+i3 OgcQ== X-Gm-Message-State: AOJu0YzNKs1CSNwnbzaxtkKVUdF3rcIeCy33FvNlSHosy7LSTZrHQFKN gabFG3G0dEmWpO2uXr7xz5zCRW6gctKV7+APwtQ= X-Google-Smtp-Source: AGHT+IHOpVtz342Fb1Xw7hCy5bmb7ac4CCT+k77LmmL738thpByYMW9E51oQkP6BLK4a0MgNEkso9GLAP8IfpVV9Ht0= X-Received: by 2002:a2e:9b91:0:b0:2cd:1ca6:87c0 with SMTP id z17-20020a2e9b91000000b002cd1ca687c0mr2798353lji.23.1705360326082; Mon, 15 Jan 2024 15:12:06 -0800 (PST) MIME-Version: 1.0 References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 15 Jan 2024 23:11:54 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Mon, Jan 15, 2024 at 8:51=E2=80=AFPM Dmitry Gutov wro= te: > > I don't think there's anything magical about a base mode. But I like y= our > > solution too. > > As "magical", I meant the original patch for this report. I wouldn't > mind the "base mode" approach, but I guess its still suffers from not > being suitable for using with earlier Emacs versions. > > And every programming mode will have to come with -base-mode defined, We could define them all in batch in a macro, that's not too bad. And then let the existing fleshed out ones overwrite those definitions by making sure to load them later. The main advantages of the foo-base-mode approach is that: * it is easily grokkable by everybody, as it is very simply based on simple inheritance, which everybody knows already. * there's already a fair number of such modes in the tree. But I do like your patch better, it seems pretty useful to introduce the language concept, as it solves this and more problems more cleanly. So let's see where that goes. > This choice is coupled with the corresponding logic in 'buffer-language' > (whether to keep the replace-regexp-in-string branch). Yes. I think we should err on the side on convenience. What exactly are the defects can we get? I can't see anything else but the tuareg-mode, and= we can plug that on our side. Maybe you can see more. > Are there specific uses for get-mode-for-language when there is no > existing buffer? Yes, I'd say this markdown-mode use is exactly that. Markdown inserts some text into a buffer and all it knows is the language it's supposed to fontify it with. The major mode has that logic, so it must invoke the correct (and preferred) major-mode function. Another use is allowing the user to choose major modes for languages, say from a tutorial or wizard or at Emacs startup. Say, I prefer ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summarize those preferences. > We could have both functions: buffer-language and get-language-for-mode > ('get-mode-language'?). Or define one initially and add the other as need= ed. Yes. buffer-language isn't bad, it's a useful helper. But buffer-language should be just (with-current-buffer buffer (get-language-for-mode major-mode)) Right? Modulo some caching if it turns out to be very inneficient (which I really doubt) Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 21:09:19 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 02:09:20 +0000 Received: from localhost ([127.0.0.1]:47342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPYtD-0005eI-F9 for submit@debbugs.gnu.org; Mon, 15 Jan 2024 21:09:19 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:56369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPYtA-0005e4-G9 for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 21:09:17 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1CDE35C017D; Mon, 15 Jan 2024 21:09:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 15 Jan 2024 21:09:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705370951; x=1705457351; bh=hLSWlxDUg65lImz5NfsWs/HpZ4m93tvyzMcaCUE/5IU=; b= FINF/j8XTtwg2o8/PjNIbtBN6fNhMWLnMHji+FneUEBYLnsQ+xJZujCPvAx/0i5P qvzJWMxAS8FSOX9EH0fYtlAiQM4SicrhgOnW5PmcLINi20Ec4cWePpOE3WCxtHei 0k5q6imIgNpY4U/himFiy+bAboSJYAWCu2NrIEMqOtaaS6bAbLRygcZxR3BPFoam aRstjWntB+sYleTwhuVeROrAiJbtMPSMr8m87JR0Rm+Othr0Ch7V2v+iZtKe5+kp BNvKKifx683VYsnaM9Qe6NvTavowvDHFcdxQFz6gLkKWTc9WN3JihFqHut4prwXU 0dE2lIHCDhMY+/Fl7mRp2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705370951; x= 1705457351; bh=hLSWlxDUg65lImz5NfsWs/HpZ4m93tvyzMcaCUE/5IU=; b=O 0seXYkolGGE12OTkZth4+Qy1h321z9hQHk5RubaTFj1O91WPq1UppW5r4voKYaAU K/IcLNZUcN/BQ14qaMmdCnp8xzLX0JNIolLwylNbUUH5PBh2Qk/6LoXBpVp8Fckp Y52unrjKDqs4qOjnn/ngSOBc3pqV2pFrbyRYenGoJGFRAgs03CgnWizCqYGZxoVB d8ZGKVsGbEMuoD/WdGsR5vIPLQYyLojfrgeXTc2ZNDIKzFvf4PVG4WKAyNIw0lM6 JJJt/XA0pbSAu6JPHnU8i+SkcEn3fM3bApdj6ZXPZhidr3DWkQy42peBGLfl/Vwa 54QfH9PMmPYTHVeGq7Log== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejvddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 21:09:09 -0500 (EST) Message-ID: Date: Tue, 16 Jan 2024 04:09:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 16/01/2024 01:11, João Távora wrote: > On Mon, Jan 15, 2024 at 8:51 PM Dmitry Gutov wrote: > >>> I don't think there's anything magical about a base mode. But I like your >>> solution too. >> >> As "magical", I meant the original patch for this report. I wouldn't >> mind the "base mode" approach, but I guess its still suffers from not >> being suitable for using with earlier Emacs versions. >> >> And every programming mode will have to come with -base-mode defined, > > We could define them all in batch in a macro, that's not too bad. And > then let the existing fleshed out ones overwrite those definitions by > making sure to load them later. A keyword for define-derived-mode like (:base t)? That would work. > The main advantages of the foo-base-mode approach is that: > > * it is easily grokkable by everybody, as it is very simply based on > simple inheritance, which everybody knows already. > > * there's already a fair number of such modes in the tree. Agree. I guess the part I don't quite like is adding a lot more new -base- modes (we'll have to add one for every prog mode, at least), most of which would stay unused, but unlike hook variables, clutter the function namespace. > But I do like your patch better, it seems pretty useful to introduce the > language concept, as it solves this and more problems more cleanly. So > let's see where that goes. Great. >> This choice is coupled with the corresponding logic in 'buffer-language' >> (whether to keep the replace-regexp-in-string branch). > > Yes. I think we should err on the side on convenience. What exactly are > the defects can we get? I can't see anything else but the tuareg-mode, and we > can plug that on our side. Maybe you can see more. For example, it would sometimes return ugly non-existent languages like :help-fns--edit-value, :org-lint--report or :xref--xref-buffer. In most cases that would be harmless, but OTOH the callers would miss out on the opportunity to see that the language is nil and apply their own fallbacks right away. I don't have a real problem scenario in mind, though. Perhaps some commands that would act on the language of the current buffer might want to say "no language is associated", but could not with the "convenience" approach. >> Are there specific uses for get-mode-for-language when there is no >> existing buffer? > > Yes, I'd say this markdown-mode use is exactly that. Markdown inserts > some text into a buffer and all it knows is the language it's supposed > to fontify it with. The major mode has that logic, so it must invoke > the correct (and preferred) major-mode function. Sorry, I meant get-language-for-mode (which is the one implemented as buffer-language currently). > Another use is allowing the user to choose major modes for languages, > say from a tutorial or wizard or at Emacs startup. Say, I prefer > ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summarize > those preferences. This would require capabilities like "get all modes for a language" (not one of the set of functions mentioned so far, and it'll need a full scan of major-mode-remap-alist) and "get current mode for a language" (this one matches markdown-mode's function you posted). BTW, get-current-mode-for-language could be implemented in terms of set-buffer-language. >> We could have both functions: buffer-language and get-language-for-mode >> ('get-mode-language'?). Or define one initially and add the other as needed. > > Yes. buffer-language isn't bad, it's a useful helper. But buffer-language > should be just > > (with-current-buffer buffer (get-language-for-mode major-mode)) > > Right? Modulo some caching if it turns out to be very inneficient > (which I really doubt) Again: this won't work for files where no suitable major mode is available (e.g. not installed yet). From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 21:32:38 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 02:32:38 +0000 Received: from localhost ([127.0.0.1]:47349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZFl-0003Dk-Rj for submit@debbugs.gnu.org; Mon, 15 Jan 2024 21:32:38 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4187) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZFg-0003CZ-GN for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 21:32:35 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AD857100054; Mon, 15 Jan 2024 21:32:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705372344; bh=q3BDAZ8RLiLrYQl75priEYhl6wT7XQcmou7sK/Gy2OY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=awk4jVdJrECp6dv543H07sQdJxY1j+iZyj25XiZJLyU0XYOk9YeUhmN4P4RdIGA9B 4FZAfe30p9abBGwJ34nobHqFPRMuPzu6LnSh7r1ndQKjOOYY9aE6u3L1RwmfsT0Mdm upfnvbahmpq4+OsdtuJ6c1otr4s5eoZf1Ydj6tn52LnJiN0IRD+KGeuA+8nkk83c9I S2OZPpmQugomToWgNOksSEie0JaZPF9LaIZrfM10oHe3bQkZ28h2Jjslo/OXtXh+9N l1Fn94YR/FF20v6VOefmvFdcBJaihFedznsD5xQ+SKsNTP7lrtqy7JTRYt6q4eqjx2 R8SW/7b+/74hg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8CD3D10001D; Mon, 15 Jan 2024 21:32:24 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3E02912062F; Mon, 15 Jan 2024 21:32:24 -0500 (EST) From: Stefan Monnier To: Stefan Kangas Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Stefan Kangas's message of "Mon, 8 Jan 2024 11:18:41 -0800") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> Date: Mon, 15 Jan 2024 21:32:22 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.139 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Please don't call it "language". That'd be confusing. LSP is about >> programming languages, so "language" is natural there. But in Emacs, >> a major mode is more general than that. For example, it is not >> unthinkable to consider mail-mode to be the extra-parent of >> message-mode (or vice versa) -- but what is the "language" in that >> case? > Isn't the language for such modes in this paradigm just the empty set? I'm not too worried about those cases, indeed. I'm more worried about the taxonomy of languages. We currently have the taxonomy of major modes, with which we're pretty familiar, and we've had many years to learn about its downsides, complexity, as well as how to deal with them, but for languages we're only familiar with the easy cases, which makes us judge the idea in a way that may prove naive. IME, deciding what is the type of the content of a buffer is usually trivial but with some notable caveats, such as XPM or Postscript files, or "container formats" (like `.deb` or `.odt`, as well as things like DocBook which can be considered either as their own format or as XML), or "sublanguages" such as C being a subset of C++, or Javascript being a subset of Typescript. And I suspect the info we need will not always be quite the same. So while there might be a good case to be made to add some API functions to query the language/type(s) of a given buffer (I'm not sure we'd need the language of a given major mode, OTOH), or to find the preferred mode(s) for a given language/type, I think it's worthwhile to try and tweak our major mode taxonomy because it is information we must have and information we know we will always have, so we should strive to make it as good as we can. It shouldn't make it any harder to add language/type API functionality. On the contrary it should make it easier. [ As suggested elsewhere in this thread, we could even try and merge those taxonomies, e.g. using extra parents of the form `LANG-lang`. ] As I said at the very beginning of this long thread, I'm not completely sure how well my proposal will play out: the upsides are in plain sight, but it may bump into real problems. [ I'm actually surprised by Eli's optimism about it =F0=9F=99=82 ] But we won't know until we try it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 15 21:35:43 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 02:35:43 +0000 Received: from localhost ([127.0.0.1]:47355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZIk-0003J3-KO for submit@debbugs.gnu.org; Mon, 15 Jan 2024 21:35:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZIi-0003Io-QR for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 21:35:41 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2A9B844359B; Mon, 15 Jan 2024 21:35:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705372529; bh=RXQ+KfO5SyHLBEeAum8LKLULHFGMAdZ642O3S6wE2Y4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Hun4oVEv6Z7pH7v2GIejHeCJYLLNg9ONzgx54z1pKpvg8hH3MPG/rli4bme21tl7p ugpLj/H2ooxTA6/3qRvxxiFjZphPM1h2NmgSrWh4bsIx1hI2FIH7oM3WffPqo9WlEw JFAjqdu7b28jgQsonFw5DH8iqOY1bYfxxR5boYZgVwgh+331YENR1joI72bMuAT9Jr cMY6Ssr+3FwyqyU1eBrgkE4tafkGKGQLmTniRiDgjFIzq5VOOnWYT29i6Yoj7/oMhs DpHf3iDvoh4uVO451pubPMXi7Z667Qm4gUWGWhs1kFdIa9DWr9lT1g4NRwMgbCHyty rwlDA+a3Zt/0A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9DA644435A0; Mon, 15 Jan 2024 21:35:29 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6206B12021C; Mon, 15 Jan 2024 21:35:29 -0500 (EST) From: Stefan Monnier To: Stefan Kangas Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Stefan Kangas's message of "Tue, 9 Jan 2024 22:24:56 -0800") Message-ID: References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Date: Mon, 15 Jan 2024 21:35:28 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.008 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Basically, the biggest weakness of Stefan M's solution is the biggest > strength of Jo=E3o's and vice versa: "backwards-compatibility" (if we can > call it that) vs "clean taxonomy". While a fresh new taxonomy could definitely be cleaner, seeing how it can be designed with 40 years of hindsight, I believe "clean taxonomy" is an oxymoron. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 05:34:37 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 10:34:37 +0000 Received: from localhost ([127.0.0.1]:47850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPgmD-0001RF-3K for submit@debbugs.gnu.org; Tue, 16 Jan 2024 05:34:37 -0500 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:59489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPgmA-0001Qq-Ta for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 05:34:35 -0500 Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cd81b09e83so63658321fa.2 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 02:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705401269; x=1706006069; 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=K7aiDPaNjQ+kgoUz4sOXk1WaBcSklVCodkYnuk7wsSo=; b=HK2rur0CTYPCg5frisEtl986SveLikgT3F9cSmwaDJnb0cQfSrftWvEJRpXjN4NinB FSIUoLnddiRWHJdFPFr2/t2qkVLMqgDtCxdIy4jXHEPHl1+doqwl8t/+8hVTLG3/NaYc YCqClzrKeG9eaWyyKKkbcpjPmi4fDCvW35yaTw2yMFdso4nSlO/Dq2TAoBmbl3Fk0vPQ AoScDh5Tolv6vkoP0Y+duGwL3Tg0R6watovsIswTaSnRiPVbA7/SbfpcC+UlMaHsUaKd fZn2nXE4aPt/s/1riuAe4CGh/OxzJqREfnbiFPZpar0oRA5A7kldaOG87OXPgDvja+81 lyGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705401269; x=1706006069; 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=K7aiDPaNjQ+kgoUz4sOXk1WaBcSklVCodkYnuk7wsSo=; b=e4NP95FmoPYJPyeicDescN70kQ4Lh9z9GsXksWwLCsD0PlnESmmrYzpxYVFgp3xOJc fesK3YPx7Zuuc6gmy7LGm9mI4D6dwcnDnL2bgC/0xL4n/phslv+42nAS1J+M8QFfEKbV tk5+45t+oKGdAYXWJmZ5cHSKUqCiDdYXw9rAZgyWO5krtnNlImsNQx+NWNGElDJ8sWCg Z5pLwX1SQh9ReDaEVIpMvbi24VsyD2m9rV3D4abSpC5btA7v+qthmsaoKmClay3r34T4 PIIqqE5g5RiNhYnyTgFyapTlwVA+tOYE67AFfTmxp6ZqkR+eAfBX1SK1PwjZ8hUkWo2p ibBA== X-Gm-Message-State: AOJu0YyBJq8XQMqQKAzYc1QuvILgBCmnzIEy0Cr40C8Rorl91h0J256i u0HZ63QQcYTM7VBggtcCUHZMneRDkyF08Q9T4kk= X-Google-Smtp-Source: AGHT+IHaQDjNtunwjpITVubHCUKH3EmvcwWjm126plA0Z02KFCvwwt7nPySyT/b+x5LMjkNh29n34bXKWIKwZkTw8Ss= X-Received: by 2002:a2e:82c3:0:b0:2cd:4c1e:fdf4 with SMTP id n3-20020a2e82c3000000b002cd4c1efdf4mr1507292ljh.127.1705401268381; Tue, 16 Jan 2024 02:34:28 -0800 (PST) MIME-Version: 1.0 References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 16 Jan 2024 10:34:16 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 16, 2024 at 2:35=E2=80=AFAM Stefan Monnier wrote: > > > Basically, the biggest weakness of Stefan M's solution is the biggest > > strength of Jo=C3=A3o's and vice versa: "backwards-compatibility" (if w= e can > > call it that) vs "clean taxonomy". > > While a fresh new taxonomy could definitely be cleaner, seeing how it > can be designed with 40 years of hindsight, I believe "clean taxonomy" > is an oxymoron. "clean taxonomy" is most definitely a oxymoron :-) But is this really a "taxonomy"? I see no real categorization or classification. I just see a many-to-one mapping of major modes to languages. I don't see any conceptual wrinkles, can you point to one? Can you point to some concrete major modes inheriting from prog-mode where it's not easy to give a reasonable answer to the question: what language is this major mode for? I don't think it's a problem if we have to choose between "JS" and "JavaScript". Just pick one, and adapt to external systems if needed at the boundaries. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 06:06:45 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 11:06:46 +0000 Received: from localhost ([127.0.0.1]:47897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPhHJ-0007lA-BJ for submit@debbugs.gnu.org; Tue, 16 Jan 2024 06:06:45 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:53290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPhHH-0007ky-MR for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 06:06:44 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cca5d81826so126494851fa.2 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 03:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705403197; x=1706007997; 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=MuTJUMlazdn3QDK/TlSrLsXg8kiarmLbgii70UeVbxA=; b=WpcV20SnqxGr9yg3SVbVwXtqzrvIvftzZ1fV2ApvRiFNIM+enThqlaEfHO7g1Q4+4M G1bjRJfu+BE0KWPlB58/ms6rVdXK0lRj9QQH5EMkVefWmGO86B+TaCE+DJMN1nzxe1dA phO11ZQhNwG7rzXiaqD/aaTAnPGxjed7zqnRoMUnho87KaWlU/pIjZ3PMKixzAhxo1d2 kRKbD4UpAWFTx8ZmsUms2C464v89PA+oOQHApO1y345WPhDZ5aF/MtQYU5SXGbT5LQa2 fH2YujcWR56lmaeIQrXy/yzSwfPaXYJLr7bk7kbKwa9/Jl862r9gEAtzAXNzx4qnGKrW qLPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705403197; x=1706007997; 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=MuTJUMlazdn3QDK/TlSrLsXg8kiarmLbgii70UeVbxA=; b=ZplHrp4EJ1JfxaDLf4QuvXmiCUxVbF3dkmb6B109rSEYK2Vka+0BlptgzTfyptGj7+ 8lpjrIkbeEbP0lvDRnrkSUQXSi8dBVT8wMEJsxPqrm7klpQ+ZIMVm5pj7Eb9DiNuDd0Z +N1nPA8slopnzHoPj+w3nVFvEx3lhOway0Z+U7mt0oaIW/LqWpxWmiA+zeeoy1SfEqaW NBTlNsZ23SLS+DnK2GPnAuYFAznLd8wMxd0/RV4/skQP/pfhG2R7O25GUOGeu/1erJpg /mT5RxAB6X/3kpFpF06vj3NIy3J982082b+xG1omRLWzgymRQjfc+saRoW6gjI2MXqiN R9Mw== X-Gm-Message-State: AOJu0YxUcrPMBd6uTzetQL2Rl/7eErF1xgOyYjsV5ztxlwXesNae5fMD Hb+lnLVhPA1FmW8E00Qkcg9nyadzMWaSUyeOO2A= X-Google-Smtp-Source: AGHT+IG5RpAT31hm3gAv4JM5qxzl/r/T+++c5vRfGOdbLb1LeHIvLkYMtqVHKfHwXmdqkuZhgmApm8Zs2slzWAhxPnM= X-Received: by 2002:a2e:8395:0:b0:2cd:5e2b:52e3 with SMTP id x21-20020a2e8395000000b002cd5e2b52e3mr3772711ljg.54.1705403196727; Tue, 16 Jan 2024 03:06:36 -0800 (PST) MIME-Version: 1.0 References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 16 Jan 2024 11:06:25 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Tue, Jan 16, 2024 at 2:09=E2=80=AFAM Dmitry Gutov wro= te: > > We could define them all in batch in a macro, that's not too bad. And > > then let the existing fleshed out ones overwrite those definitions by > > making sure to load them later. > > A keyword for define-derived-mode like (:base t)? That would work. I think that would just clash with the existing PARENT one (when would one of those bases _not_ be the parent). For base modes, I think the current approach is mostly fine. There's something we can do for the existing ones (and future ones) though, which is to explicitly mark them abstract somehow. > > The main advantages of the foo-base-mode approach is that: > > > > * it is easily grokkable by everybody, as it is very simply based on > > simple inheritance, which everybody knows already. > > > > * there's already a fair number of such modes in the tree. > > Agree. > > I guess the part I don't quite like is adding a lot more new -base- > modes (we'll have to add one for every prog mode, at least), most of > which would stay unused, but unlike hook variables, clutter the function > namespace. Agree. And this is why I'm not crazy about the solution either. But as to cluttering the function namespace we could say that (:abstract t) modes do _not_ generate a function (or do not generate them in the public namespace -- as I think the function still has to exist for any concrete submodes down the line to call it). > > But I do like your patch better, it seems pretty useful to introduce th= e > > language concept, as it solves this and more problems more cleanly. So > > let's see where that goes. > > Great. > > >> This choice is coupled with the corresponding logic in 'buffer-languag= e' > >> (whether to keep the replace-regexp-in-string branch). > > > > Yes. I think we should err on the side on convenience. What exactly a= re > > the defects can we get? I can't see anything else but the tuareg-mode,= and we > > can plug that on our side. Maybe you can see more. > > For example, it would sometimes return ugly non-existent languages like > :help-fns--edit-value, :org-lint--report or :xref--xref-buffer. What if we filter by prog-mode? It would leave the ':ruby-base' and ':python-base' as false positives, I guess. But then we could reasonably say that anything ending with '-base' is abstract (or use the aforementioned explicit abstract prop). It would also make ':lisp-data' a language. But that's not bad. lisp-data-mode is actually a useful concrete prog-mode derivative, so I think it's OK to have ':lisp-data' as a language. We can then have exceptions for some notable cases. 'lisp-mode' is as we know, for Common Lisp only. > In most cases that would be harmless, but OTOH the callers would miss > out on the opportunity to see that the language is nil and apply their > own fallbacks right away. I don't have a real problem scenario in mind, > though. Neither do I, but I agree we should be as accurate as possible. > Perhaps some commands that would act on the language of the current > buffer might want to say "no language is associated", but could not with > the "convenience" approach. For sure. > >> Are there specific uses for get-mode-for-language when there is no > >> existing buffer? > > > > Yes, I'd say this markdown-mode use is exactly that. Markdown inserts > > some text into a buffer and all it knows is the language it's supposed > > to fontify it with. The major mode has that logic, so it must invoke > > the correct (and preferred) major-mode function. > > Sorry, I meant get-language-for-mode (which is the one implemented as > buffer-language currently). > > > Another use is allowing the user to choose major modes for languages, > > say from a tutorial or wizard or at Emacs startup. Say, I prefer > > ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summar= ize > > those preferences. > > This would require capabilities like "get all modes for a language" (not > one of the set of functions mentioned so far, and it'll need a full scan > of major-mode-remap-alist) and "get current mode for a language" (this > one matches markdown-mode's function you posted). Yes. I don't see the full scan of m-m-remap-alist as problematic from a effiency perspective. If we decide it's the database, it's the database. It's unfortunate that the "alist" implementation is hardcoded in the name (which is why I would prefer a (:language "Foo") kwarg to define-derived-mode) but we can abstract the alist aspect away with accessors and do the usual "Do not change this variable directly, use these accessors instead". > BTW, get-current-mode-for-language could be implemented in terms of > set-buffer-language. What does get-current-mode-for-language do exactly? > >> We could have both functions: buffer-language and get-language-for-mod= e > >> ('get-mode-language'?). Or define one initially and add the other as n= eeded. > > > > Yes. buffer-language isn't bad, it's a useful helper. But buffer-lang= uage > > should be just > > > > (with-current-buffer buffer (get-language-for-mode major-mode)) > > > > Right? Modulo some caching if it turns out to be very inneficient > > (which I really doubt) > > Again: this won't work for files where no suitable major mode is > available (e.g. not installed yet). Right. So maybe (or (with-current-buffer buffer (get-language-for-mode major-mode)) (let (kw) (and buffer-file-name (keywordp (setq kw (alist-get buffer-file-name auto-mode-alist)= )) kw)) (consult-oracles) (error "Don't know what language this is, sorry")) ? From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 12:45:29 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 17:45:29 +0000 Received: from localhost ([127.0.0.1]:49699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnVB-0005gJ-0e for submit@debbugs.gnu.org; Tue, 16 Jan 2024 12:45:29 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:34727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnV8-0005Tj-Vl for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 12:45:27 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id E44135C0243; Tue, 16 Jan 2024 12:45:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 16 Jan 2024 12:45:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705427120; x=1705513520; bh=0nuQK8sr7IROuXkUKijeVYWtq4qPrBYIGujcPpYgg+Y=; b= aaMeRV5KiFWPYLzb3KllT5/oehQog3KAgEPKSVioGuLTiODLEptyfEdX57vEkGoj 938+nl+kluI9IO8x079XqO6elY4PoiizpA6VOk3YcvKLYLH8LAph6VwLWN22p9CQ eY3dkT1K11Gw1OnYbBmtzz39cD+88VKEjhBkyWfd9leaV94/4HjzdxOf3uvS77Br Im9P7og5TGEmpELzYwoqCLGL2sB5uMlmw+ymsjXMsebKkgdCW7POztHLX18j95kk JGgHbRRyOyjhkydCNiASis61dfpKFtrJfIQ71gTiuZHTAiLbHYSeg3EoMptU3Xv6 4G8s2C37NR7nbxQernfPHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705427120; x= 1705513520; bh=0nuQK8sr7IROuXkUKijeVYWtq4qPrBYIGujcPpYgg+Y=; b=Q m16CO6jFPwDPqxpeF+2MR0RZC71BStIJ7NrS6r/2uV6GEqvhs9LcAqoQ7XRYqHQW 3XKto1sC+7g/zfpdomsbkASewuX9IF1swVlutZsokBI+d/USKejKUSaGC31QTTfe Lmvw8ZHDLMlkrwVqQsT8mt3LgyPy4wG9k4C5P8ITox8cIcSJ4f6/yxg6UTbXJyvZ pSvi3dBbtZtaWQUQzARRqLTUpEOrkk6C0eY1KEMndfJmp1zGCegbhpGawFzqCxF9 C13PIrAWuqEVw4bA11plywRTLdIjTkGjEv3sLuWwjDBtOSnozD8uVmctBcF5KA3G lGQhTA6uLpiVbAJui3z7A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejfedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeegleefteekgffhvdfhtdegveevveetteegteevgeettdehhfdukeetheff ueekkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 12:45:19 -0500 (EST) Message-ID: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> Date: Tue, 16 Jan 2024 19:45:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier References: <831qavvcbo.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 16/01/2024 12:34, João Távora wrote: > I see no real categorization or classification. I just see > a many-to-one mapping of major modes to languages. It might even be many-to-many, at least in some cases. E.g. js-ts-mode being good for both :js and :jsx. Whileas typescript-ts-mode can work for :js and :typescript but not :jsx (or :tsx). tsx-ts-mode is probably okay for both :tsx, :jsx and :js but not :typescript (in general, because of certain clashing syntax). Not sure how useful this -to-many relation is going to be in the above cases, but it's probably a good illustration of the possibility. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 17:00:56 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 22:00:56 +0000 Received: from localhost ([127.0.0.1]:49908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPrUN-000848-OX for submit@debbugs.gnu.org; Tue, 16 Jan 2024 17:00:56 -0500 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:45063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPrUL-0007rt-E5 for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 17:00:54 -0500 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd2f472665so109603271fa.2 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 14:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705442447; x=1706047247; 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=yS1xa7u+8PKUAz6QNaXR2oF6MRxBiOI4yEJiras243c=; b=aNqQPu2WhB3T6EEJtFjszodp52JAHtglxMQobB551a+bDwMzU2GxWN1xABbun+fFBN qxLnIgmOIIOn5GGQ19nfCNz55obbAAZMQTh+/4sAGTJGV5rDeci+8sos92OUjXuwBjA9 6K/dVkhcJ4Y5SCXGGUZEFfpASpS2wkaY8xaYtCamBadTOEvQNgFTyRc+9EY4RnFyB1F4 WY3BhRlPv6Ypn2BUXI7BRPNBeFx+cqWVb4gYlT0laQ7O0u7Ev0Z+wMMmhX47sr+e9s4w bD+K8WvTEmLOLrQThFLjVPpQ+U5Ni9w5kjEj4yof8SM61T7lDKXGzfI0bgOOM9kSxVHL x34Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705442447; x=1706047247; 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=yS1xa7u+8PKUAz6QNaXR2oF6MRxBiOI4yEJiras243c=; b=MVpz8DEJ83JAPg6gX/etrdw5ogPxUz4LNogIjcb8C5O/rTQWH2G3T1y5af2qnCETXd FQawxulhkF3Vm/ANcVRvz1zq8iUABbquFuiwaffH72d8RP7jV+mv3h5dxwWwY1pj1/nA SgiNckmy+AlTq4VX6WPc0VqFIRYQ0rvXdmvgCZrMK3OcAOhdygHP8ry8BJlYc9LuLAOA AfozdL/aQg2r+NTm0o0Su/aOZGmhlxbY7PX/sX0TFwFUCqX33BB9fylmHnFhw+EkUqhC bhhhuCTjjbRBbWfieoCMCYG2SHtpk+K2j7ZPQyfl3wL/NsstwFpu/bt9CalV+U8eMBl3 w8xg== X-Gm-Message-State: AOJu0Yw6dN9IxX2zbYTXKJ5bDUMriMySbFZstmYjVNYLsHigfbsl06f0 h0vupxddDk+vA0avE16eSpRA9oFokBdwL+P0R/w= X-Google-Smtp-Source: AGHT+IGAQmT4YsnnI119ProHKywwxIEs+qCkBqRWYXJUHFBQx0OvBOaH68FqSDlS+oqzugN11RJyZ08e93BFzflmKlM= X-Received: by 2002:a2e:b706:0:b0:2cc:a710:f422 with SMTP id j6-20020a2eb706000000b002cca710f422mr3564790ljo.28.1705442446518; Tue, 16 Jan 2024 14:00:46 -0800 (PST) MIME-Version: 1.0 References: <831qavvcbo.fsf@gnu.org> <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> In-Reply-To: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 16 Jan 2024 22:00:35 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Tue, Jan 16, 2024, 17:45 Dmitry Gutov wrote: > > On 16/01/2024 12:34, Jo=C3=A3o T=C3=A1vora wrote: > > I see no real categorization or classification. I just see > > a many-to-one mapping of major modes to languages. > > It might even be many-to-many, at least in some cases. > > E.g. js-ts-mode being good for both :js and :jsx. > > Not sure how useful this -to-many relation is going to be in the above > cases, but it's probably a good illustration of the possibility. According to https://react.dev, jsx is a "JavaScript syntax extension". So it would seem JSX is a superset of JS. If js-ts-mode parses it perfectly, it could be called jsx-ts-mode instead. But does it? I see Emacs modes specific for jsx out there, I suppose people use them for a reason. There's also tsx-ts-mode and typescript-ts-mode. At the end of the day, a language is not so easy to define, but it's not that problematic either, especially in the editor (in the compiler, it's much more important). The best sources are a standard, when it exists, but each iteration, sometimes each compiler is also its own language. There's "GNU C", "ANSI C", C17, C23. All handled by the C modes we have and the best way we have to designate this is just "C". c++-mode also handles this code by the way, probably flawlessly, and yet we don't say c++-mode is for C and C++. But if you want, I don't think there's any big problem in making get-language-for-mode return a list, with the most important likely language at the top. I predict it'll be pretty rare, but I guess you could have this (excuse the ugly CamelCase for demo purposes) (setq auto-mode-alist '(("\\.js$" . :JavaScript) ("\\.jsx$" . :JavaScriptReact))) (setq m-m-remap-alist '((:JavaScript . js-ts-mode) (:JavaScriptReact . js-ts-mode))) And 'buffer-language' becomes more like: (or buffer-overriding-language-keyword (with-current-buffer buffer (get-language-for-mode major-mode)) (let (kw) (and buffer-file-name (keywordp (setq kw ;; yes I know this needs regexps (alist-get buffer-file-name auto-mode-alist))) kw)) (consult-oracles) (error "Don't know what language this is, sorry")) Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 18:30:04 2024 Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 23:30:05 +0000 Received: from localhost ([127.0.0.1]:50123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPssd-0007yD-GN for submit@debbugs.gnu.org; Tue, 16 Jan 2024 18:30:04 -0500 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:48428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPssb-0007wn-8q for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 18:30:02 -0500 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2cdc1af60b2so32811911fa.1 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 15:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705447794; x=1706052594; 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=YKUK1jj00UVreBsJKxdV25vfo6DYdmT/VC2NZ2VU1T4=; b=XKMKahkP8jxE2TBGU5ndBJnXLBelwdwEIp/ytsvAo5nyV+wZsdGhHcimp8cI/PZDI1 6wEFtaAGErsBxDcWZxC6AuPVvONLV1v0Z0/QxARDGoTpC79oMrTSiUnPWq0ijr7y9jI8 qEOQxv7qKK2lRjN4qz8u9PP3RKefjG30lVz/7KwlheimMCveUfFoHhG1DIDDaOO8m4gQ tpzXSZ0A+6yoTV5jtXThwpHvCIMDRljSZae4rhFfPXKlJi9fyfgx+s/DFL9qOVbgIsYW bAXSszknhoIJKW9TxMYoANJunCXz9gLd8GwUAgGUuOvBJAYsL+qvKT/NKjd6qM930MSe A9NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705447794; x=1706052594; 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=YKUK1jj00UVreBsJKxdV25vfo6DYdmT/VC2NZ2VU1T4=; b=uE0aQ9NUrE/YVB08PKA0pqW5U8O71pDIzzHv/kRPGHWxdPqgm98LShXRyVChCPUwba MfI9hzqX/70VIY+kjWuxiO6jXk5e2Cf4KAhxFGbc1sesGEQQvSr5tD8L7Jd/3GWUXDvL sMzT6ytTUuTrPqPHCQZIMWPxHISv/9jt8qHIwIdYQpS8VcvfYvstA6gVGp7rJX6op5NH 1bSQeXeVVyEPRKO746/Tbs9cqiMCyCNMKpKuorI9FKzvEJ+60TC++8kdEsNha9MV/cyr QZv+HApX4HzJCxGHOS0qdyPbYQiTRNAxiDWk+IcAbZpczu2AdidigpV8QeYZPObdY3hW yEGA== X-Gm-Message-State: AOJu0Yz3Z6CAwCMOpvvbtmzzsrWPjtFENPwp9AtXgqXm+aRviiwDKiG+ uFoxQhy0zifNR/Ayg/uHh70YR6pCSehwCimVylw= X-Google-Smtp-Source: AGHT+IHveQ2xX6UQcHHwDYxz7n+bD8S5F2TF8qwzTFL1fOrQPN8qMZI5qBMygE6ktQepIvsrJSEg5e5GUIdAn6+Eb8o= X-Received: by 2002:a2e:8447:0:b0:2cd:900c:d5f2 with SMTP id u7-20020a2e8447000000b002cd900cd5f2mr3639691ljh.90.1705447793941; Tue, 16 Jan 2024 15:29:53 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 16 Jan 2024 23:29:42 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jan 16, 2024 at 2:32=E2=80=AFAM Stefan Monnier wrote: > As I said at the very beginning of this long thread, I'm not completely > sure how well my proposal will play out: the upsides are in plain sight, > but it may bump into real problems. [ I'm actually surprised by Eli's > optimism about it =F0=9F=99=82 ] > But we won't know until we try it. It solves some things (that are already solved anyway). But I think the downsides are also in plain sight. It doesn't solve common problems in Eglot and Markdown-mode. It's awkward to explain the hook and dir-locals situations. Some assertive docs on what the new foo-mode extra parent means could make it better though. I think Dmitry's 5-legged chair analogy is reasonably accurate. We can build it easily, yes. People will sit on it, sure. But it'll never go with the furniture or be ergonomic, even if they never bump their pinky toe in the extra leg. We have boring old 4-legged chairs readily available (base modes) and we can think of more elegant chairs. What do you think of Dmitry's patch? From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 19:04:01 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 00:04:01 +0000 Received: from localhost ([127.0.0.1]:50136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPtPU-0008Ql-On for submit@debbugs.gnu.org; Tue, 16 Jan 2024 19:04:01 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPtPS-0008QV-Nb for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 19:03:59 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D08AF10009E; Tue, 16 Jan 2024 19:03:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705449830; bh=BQpn9cQbjcorohH1Lm9qHFaXl1K8Pmy/on+BoG218z8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JMqbTEAO6aPmtRtYfyhot9+mAicFhzz08OtokM32zjMoT+/AeUhvWxKEKBzoMoCLz b1T9D/J2Tfw6CCAHeI0seyH3CzMtj4911DHUSB/AyF1Eit6rBpJ1GIH46bAexq59jG 1yu75QbfwwzFhRo3KCBGo+WzzznzKAtyG+GldSnBPsd7NlBGZdqDtHEBsW/p1zCBRk QWsGi6EpbsLaLN+9O1N/8y14SSflPPAr2dNw5RS46Uw+te2amz5iiAlPhDs4NMk81j ypYUueUZSJPipU/ckYVQXhwCs3l3wsb0eCS96tSL8qsUv2OxqJday2lZiLUgdBOavM lo/3eLBL6rZWA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C91D810004C; Tue, 16 Jan 2024 19:03:50 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B2EAB12049C; Tue, 16 Jan 2024 19:03:50 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 16 Jan 2024 23:29:42 +0000") Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> Date: Tue, 16 Jan 2024 19:02:50 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.525 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It solves some things (that are already solved anyway). But I think the > downsides are also in plain sight. It doesn't solve common problems > in Eglot and Markdown-mode. It's not designed to solve all problems. [ The needs of Markdown-mode are different from those targeted by the current bug. They're are of the form "find mode for type", as addressed by things like `major-mode-remap-alist`, whereas the current bug is about classifying modes. ] > We have boring old 4-legged chairs readily available (base modes) and > we can think of more elegant chairs. What do you think of Dmitry's patch? I answered in the email to which your above email replied. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 19:49:38 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 00:49:38 +0000 Received: from localhost ([127.0.0.1]:50176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPu7e-0000rs-5a for submit@debbugs.gnu.org; Tue, 16 Jan 2024 19:49:38 -0500 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:43223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPu7c-0000rg-4T for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 19:49:36 -0500 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2cdeb4b9aa4so2673781fa.0 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 16:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705452569; x=1706057369; 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=rIWVj1Mr/4c8RBY/PCE/vtlV/YIxLhBB75cwfdXo7X4=; b=J/Lu7sAt9x52MWhEZ7iq+PZ3GYz7BHqVIY2llgvWuEYLdpypBWHVAPshpWBOdRxsVK pCJev0TgBr0i9YfwZWeBMcr4FGwXtiAhRhIAg8xga7MB3CZaMRSzg1l4D8/tuCj2QXTX mEKZWHEw3VCCUMbxj5Jp4g7X1rIOkRvDPEQtQHz9w47u5glljUpJ0gwPalq/UzNeGFpj EFlSW0W+h9kIxpbBdxwWam6AhMH2/2ghNv5xc9HApK8/gfezC9ToKRYabTL6UmKTbJKe 1x+S9t2KTxK63IvLRkSGkfkVMQuqcCajaaOSQCiTRpwiZ/OG6lgVrpCS+sYde+sAyQ/g LL9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705452569; x=1706057369; 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=rIWVj1Mr/4c8RBY/PCE/vtlV/YIxLhBB75cwfdXo7X4=; b=jKsZgp2sEKcpeYqdB5JkSJPap2mahdioZOp4XmDzpVSbD9wzeawXXXteNyZiKKm0NG 0a9oW+kErjOeEWbJxgsr0bfWZRluNFq/oyZ+GkVRCZdGO/rlwtmj1JtQ6S4xq3IsJPwf skMbXuuupb33ylqK5VspJRtgv4Jc3SHtcRuIIzbnhsbD2JmpVpkNaYkGXVGG8ou50ReZ 2n1mIINSpdCfPGxW66FXAaRqxsaVuJo059jGbzrqDaDRq57BRjYiUGS+WhGMV2Pu+2rC zmruLqWLV02dLbY6gpVsiEw83met8ijMNtqPptsFWFiDYhoxALkckIxH8kyzZtrErDgg VcdA== X-Gm-Message-State: AOJu0YxeuggZrSh6by9LdbJ/CbV2/nuSzZenOrLCZNXr5+16LRUOMESF zvig0/kW+5zhTYEQPUgi4pSHXVZlmfm6RamXIb76BMwnCQVTeFfhleubqB3K/bWyaYCYN4kKyUP ANr8Mcx3+uOid6QXMMKCQ4CMVlOg= X-Google-Smtp-Source: AGHT+IHbgAFhl6Vj/+fz2Agx+uAg8l/fqL1uXh6DAvD5Mw6cKDstrjs0AJhKybyGkl57kAk+SmV74t/X3M0mefvaITo= X-Received: by 2002:a2e:8519:0:b0:2cd:27b1:2235 with SMTP id j25-20020a2e8519000000b002cd27b12235mr9468lji.9.1705452569276; Tue, 16 Jan 2024 16:49:29 -0800 (PST) MIME-Version: 1.0 References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 17 Jan 2024 00:49:16 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jan 17, 2024 at 12:03=E2=80=AFAM Stefan Monnier wrote: > > > It solves some things (that are already solved anyway). But I think th= e > > downsides are also in plain sight. It doesn't solve common problems > > in Eglot and Markdown-mode. > > It's not designed to solve all problems. Sure, and fair enough. But those other problems are real. Two groups exists, give or take. If we take this solution for just one, we make solving the other more difficult. > [ The needs of Markdown-mode are different from those targeted by the > current bug. They're are of the form "find mode for type", as > addressed by things like `major-mode-remap-alist`, whereas the current > bug is about classifying modes. ] We should get a holistic solution where we introduce the concept of language, either explicitly -- Dmitry's patch -- or implicitly -- abstract base modes derived from "prog-mode". I prefer Dmitry's patch, but the base mode approach also covers all cases AFAICS. I don't see the urgency of fixing the problems this patch addresses. Can we quantify these problems? What external package is currently misbehaving so much that it has to be fixed like this and can't wait for a better solution? In contrast, bug#68217 points to a real unsolved problem where discrepant modes may be chosen by the user and the Markdown package, and there's no easy way to coordinate. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 21:06:13 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 02:06:13 +0000 Received: from localhost ([127.0.0.1]:50244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvJl-00081f-8V for submit@debbugs.gnu.org; Tue, 16 Jan 2024 21:06:13 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:40981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvJi-00081Q-C2 for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 21:06:11 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 72B835C019F; Tue, 16 Jan 2024 21:06:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 16 Jan 2024 21:06:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705457164; x=1705543564; bh=Y3UDg60R6Ctg+I/szU9MkoH5zsMbVmjLzVQobwld7Gg=; b= dNkiuMvm0gm1mL3YLgLRTAfx0LZoPnnHOuB8mIXHoY1zFE9ct/7RdYAs2FV9Osbr woBidkeHEbBzBqOlRdm0yMaBqoUm0MYSP2dXKUhYcBAJwdKm61KjQ1RZaTu+gCrW iUzCXp0K6Aw+YKWCS9e09ASpbVgW42Z5st8Iax6jZVDrGD38gHBu1CyoALUBOoYH DNtJY36PJu21N6H6UKkYwrcB2cWkuQ3AxbTvB/fJCgwkPVY99UsTPI8CRPxyGYwJ razNNXl2pPzHmxlyBOXfzX33BNZEP1POd7SlTe/kX2sPGeXtgHBIa0ufXgHPYXjk p8QCxu1RbtnT+Zw8JaU9UQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705457164; x= 1705543564; bh=Y3UDg60R6Ctg+I/szU9MkoH5zsMbVmjLzVQobwld7Gg=; b=L WEDAuCLMmEJokadWFXSCXBCwsd/nWc9PTtPi4qVU1lY7ZWhBL/jMw35OBjBDRI1d T/pQXDPeoAbpf4EATWGUA19VMNMCQN8UxTBmiy+5LNP8jhror2my/f2q+yjRcdwe 03WuGX8NktOgj7OnBXALyJg4k5nRKm7GCSzIk+aSCD3jwRWCcgvozILzE99qvx88 tXerR+YiI56KWYOLxEHV5xSjnsHgF/GaNjQYsNRUbkHDyMJjXJ0L+zqzg3xfdLnG gVccjbAkwuBeJmCM9XbuV6Je3hfseTjVi5S3d0kBeI1cZAYkaTclTPWTsQnqBTDT 1wqvj4IW3Gl6yHN5TZ4cQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejgedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepveffveefieefkedtudefieduhedvveffieetffduuefhkeeikeevleffhefh vddunecuffhomhgrihhnpehrvggrtghtrdguvghvnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 21:06:02 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2024 04:05:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 17/01/2024 00:00, João Távora wrote: > On Tue, Jan 16, 2024, 17:45 Dmitry Gutov wrote: >> >> On 16/01/2024 12:34, João Távora wrote: >>> I see no real categorization or classification. I just see >>> a many-to-one mapping of major modes to languages. >> >> It might even be many-to-many, at least in some cases. >> >> E.g. js-ts-mode being good for both :js and :jsx. > >> >> Not sure how useful this -to-many relation is going to be in the above >> cases, but it's probably a good illustration of the possibility. > > According to https://react.dev, jsx is a "JavaScript syntax > extension". So it would seem JSX is a superset of JS. If > js-ts-mode parses it perfectly, it could be called > jsx-ts-mode instead. The grammar tree-sitter-js supports JSX. So the mode is called js-ts-mode. > But does it? I see Emacs modes specific for jsx out there, I > suppose people use them for a reason. They are older. > There's also tsx-ts-mode > and typescript-ts-mode. Like I said: tsx-ts-mode is probably okay for both :tsx, :jsx and :js but not :typescript (in general, because of certain clashing syntax). > At the end of the day, a language is not so easy to define, > but it's not that problematic either, especially in the editor > (in the compiler, it's much more important). > > The best sources are a standard, when it exists, but each iteration, > sometimes each compiler is also its own language. There's "GNU C", > "ANSI C", C17, C23. All handled by the C modes we have and the best > way we have to designate this is just "C". c++-mode also handles > this code by the way, probably flawlessly, and yet we don't say > c++-mode is for C and C++. > > But if you want, I don't think there's any big problem > in making get-language-for-mode return a list, with > the most important likely language at the top. It would be a problem if we decide that the major mode function runs the language-specific hook, and not set-auto-mode-0 like in my patch (because the mmode function would like run the hooks for all supported languages, rather than just the current one). > I predict it'll be pretty rare, but I guess you could > have this (excuse the ugly CamelCase for demo purposes) It might indeed be rare enough for this to be a problem, and we might even decide to prohibit such usage, keeping the relation many-to-one. > (setq auto-mode-alist '(("\\.js$" . :JavaScript) > ("\\.jsx$" . :JavaScriptReact))) > > (setq m-m-remap-alist '((:JavaScript . js-ts-mode) > (:JavaScriptReact . js-ts-mode))) It indeed should work okay with my proposal, but might be harder to do if the languages are inserted as part of the existing modes hierarchy (e.g. as "abstract" symbols). That is assuming we do want the language hook to run - which seems like important goal from my POV. > And 'buffer-language' becomes more like: > > (or buffer-overriding-language-keyword > (with-current-buffer buffer (get-language-for-mode major-mode)) > (let (kw) > (and buffer-file-name > (keywordp > (setq kw > ;; yes I know this needs regexps > (alist-get buffer-file-name auto-mode-alist))) There is a bunch of variables to look up: auto-mode-alist, magic-mode-alist, interpreter-mode-alist, magic-fallback-mode-alist. I didn't want to duplicate the logic from set-auto-mode, but this of course could be done. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 21:41:15 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 02:41:15 +0000 Received: from localhost ([127.0.0.1]:50262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvrb-0005md-SL for submit@debbugs.gnu.org; Tue, 16 Jan 2024 21:41:15 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:52739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvra-0005mO-Gi for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 21:41:11 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 855635C00C7; Tue, 16 Jan 2024 21:41:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 16 Jan 2024 21:41:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705459264; x=1705545664; bh=7YYlokI3IpQ2hksg3zgDIxTnof7mXFfpkdTAieX63mU=; b= J3Oqcrycb/IhThM1KN7cefKd9IEILzgOlTzuCrBZWnVthX/ElccY2UwBj7yweJit +OvW1+cAiGC4/I2d7QX4gPtl5GIPjWhL03IGhBbgRXr614c6fLqAGDlBl3aF/1AK Xqdirv7hLT5ajMN/xMAW4a04hrqVFuHVTJ6l7VvCskQtK38e3HlfzKqJB1w6mTO3 NH9bwHRaK0gQ5FnuqdZzEpeH7WhsgMnwi6t9NL+tGO3YMFkXxfPqiAoTOHYyE2EL sRbeH7uhTAzFCuqeV4uk+f3yTV49GqiJfoRfyWLAtZfyWw+oh9reVbvMhuZhOmFr GKdqI1UfVOopwKHMxssmsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705459264; x= 1705545664; bh=7YYlokI3IpQ2hksg3zgDIxTnof7mXFfpkdTAieX63mU=; b=P bH4YAbAVhbr9roywtlCHgqq4AGvAFQRXbpra3ffNkWd0u3pTqUpDo7WAPmGvVOEE /5OonHyAAadV7LesaU5jGL2Cr5reNPfK08CK1ILGjdjEkw9siisom6WEoFH2eBAe /b6iw2stSIaxfqyeyCrjvTOB4PT3Qy2TvpAE3CueMPQBnW5n2lmEJXsQamVY2qSY dkMAUQxsVmoen9nmuRho2Newms92hcuDny0MFb1zzzVfoYlCavW0q20IvInucZtT kY+ZExvt853jObfPXvxBQYeSrAcjAlwodES7zFEMJIYaZW8619TyannPG8toGkWF qCkZHB0QklvH3OUmtu43g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejgedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 21:41:02 -0500 (EST) Message-ID: <4105c743-45d0-48a0-a8bb-1ab457b9a256@gutov.dev> Date: Wed, 17 Jan 2024 04:41:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 16/01/2024 13:06, João Távora wrote: > Agree. And this is why I'm not crazy about the solution either. But as > to cluttering the function namespace we could say that (:abstract t) modes > do _not_ generate a function (or do not generate them in the public > namespace -- as I think the function still has to exist for any > concrete submodes down the line to call it). An "abstract" mode is supposedly one that doesn't do anything. So it doesn't have to be callable. Anyway, that's +1 feature required for the implementation. >>>> This choice is coupled with the corresponding logic in 'buffer-language' >>>> (whether to keep the replace-regexp-in-string branch). >>> >>> Yes. I think we should err on the side on convenience. What exactly are >>> the defects can we get? I can't see anything else but the tuareg-mode, and we >>> can plug that on our side. Maybe you can see more. >> >> For example, it would sometimes return ugly non-existent languages like >> :help-fns--edit-value, :org-lint--report or :xref--xref-buffer. > > What if we filter by prog-mode? It would leave the ':ruby-base' and > ':python-base' as false positives, I guess. But then we could reasonably > say that anything ending with '-base' is abstract (or use the > aforementioned explicit abstract prop). We would also filter out :css, for example. TeX modes also do not derive from prog-mode. TeX does have an LSP server, however. > It would also make ':lisp-data' a language. But that's not bad. > lisp-data-mode is actually a useful concrete prog-mode derivative, > so I think it's OK to have ':lisp-data' as a language. > > We can then have exceptions for some notable cases. 'lisp-mode' is > as we know, for Common Lisp only. >>>> Are there specific uses for get-mode-for-language when there is no >>>> existing buffer? >>> >>> Yes, I'd say this markdown-mode use is exactly that. Markdown inserts >>> some text into a buffer and all it knows is the language it's supposed >>> to fontify it with. The major mode has that logic, so it must invoke >>> the correct (and preferred) major-mode function. >> >> Sorry, I meant get-language-for-mode (which is the one implemented as >> buffer-language currently). >> >>> Another use is allowing the user to choose major modes for languages, >>> say from a tutorial or wizard or at Emacs startup. Say, I prefer >>> ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summarize >>> those preferences. >> >> This would require capabilities like "get all modes for a language" (not >> one of the set of functions mentioned so far, and it'll need a full scan >> of major-mode-remap-alist) and "get current mode for a language" (this >> one matches markdown-mode's function you posted). > > Yes. I don't see the full scan of m-m-remap-alist as problematic > from a effiency perspective. If we decide it's the database, it's > the database. It's unfortunate that the "alist" implementation is > hardcoded in the name (which is why I would prefer a (:language "Foo") > kwarg to define-derived-mode) but we can abstract the alist aspect > away with accessors and do the usual "Do not change this variable > directly, use these accessors instead". I'm not saying in advance that it will be slow. Just that it's a different function. >> BTW, get-current-mode-for-language could be implemented in terms of >> set-buffer-language. > > What does get-current-mode-for-language do exactly? The major-mode currently configured to be used for the language (through m-m-a-alist, in the current proposal). set-auto-mode will choose it. >>>> We could have both functions: buffer-language and get-language-for-mode >>>> ('get-mode-language'?). Or define one initially and add the other as needed. >>> >>> Yes. buffer-language isn't bad, it's a useful helper. But buffer-language >>> should be just >>> >>> (with-current-buffer buffer (get-language-for-mode major-mode)) >>> >>> Right? Modulo some caching if it turns out to be very inneficient >>> (which I really doubt) >> >> Again: this won't work for files where no suitable major mode is >> available (e.g. not installed yet). > > Right. So maybe > > (or (with-current-buffer buffer (get-language-for-mode major-mode)) > (let (kw) > (and buffer-file-name > (keywordp (setq kw (alist-get buffer-file-name auto-mode-alist))) > kw)) > (consult-oracles) > (error "Don't know what language this is, sorry")) Replied to this one in another email: referring to the results of the computation of set-auto-mode is easier. But that's a technical detail. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 16 22:45:48 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 03:45:48 +0000 Received: from localhost ([127.0.0.1]:50330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPws7-00031U-Js for submit@debbugs.gnu.org; Tue, 16 Jan 2024 22:45:48 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:34983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPws6-0002pa-0S for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 22:45:46 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 08AC55C008C; Tue, 16 Jan 2024 22:45:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 16 Jan 2024 22:45:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705463139; x=1705549539; bh=x0OxOnCC7oYQJYrT8fEn2eBeg59Bc3XEjZGkjUb0TAY=; b= TlRbu6Ui1xqGHXUpCFVSdqdVH3I5UHjPRmZxn9qeyCuwXc/kWzdfDnxCBf6WmQgB cHyZpy8elybi7/wFrdC9Gj4ciUjjY29FumMxIFTUUc/gjQNhIreUnXN8eMoLI2P2 LSvBpCsD+eNAohX3rbB9KXerkVWBvQutmRsHhwYHbPGpJ4ku9FT+NLdjWKWvViEO jZsWuUsvw2i0W4pgQLLCm1Pm9MF3O3y7N0SXmN0QRrsZAB6zD0VPSoUj6cKQNz1t hTGWicC9eNrdsyIWGUWg+hRUz2x0owcuo/VVcKz5nAk9XnXQJpSasOqqtBSfs6Jx 6DYTUNKVgVL5/OJI8P7wgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705463139; x= 1705549539; bh=x0OxOnCC7oYQJYrT8fEn2eBeg59Bc3XEjZGkjUb0TAY=; b=e ZMZnMKXSWjxwT5H1Jau/w2+fTYFYa1ujj7T2B8TXtz1Y77KPAWH59JmrDhmksHD7 3Zk3kmXzY8kcABr0SWvF4wOALs4BKw+yZl10IwqjUMQ2t+vR6zi40jaIswwoe3gq 8gMuIdnxdoTfO/ALZRFPzRaVfSXEpOrfzON4qieXKRxVzZ47g4kPhfmICytp2h2K uAWctJgGQtn7Zi9iXRZmV2IBsbMeqLWSxkrKxewAXr6n1IfaJZ6Y0YkbTYNN4lP9 DnAOROC1zCfXhohZX+GdESou2khGvYkSFiSPcqUFYhAztiY8Hj6jS96HCQQMCFtV Z//K4TwLxqmhfWbdGfIpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejgedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 22:45:36 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2024 05:45:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier , Stefan Kangas References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 16/01/2024 04:32, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >>> Please don't call it "language". That'd be confusing. LSP is about >>> programming languages, so "language" is natural there. But in Emacs, >>> a major mode is more general than that. For example, it is not >>> unthinkable to consider mail-mode to be the extra-parent of >>> message-mode (or vice versa) -- but what is the "language" in that >>> case? >> Isn't the language for such modes in this paradigm just the empty set? > > I'm not too worried about those cases, indeed. > I'm more worried about the taxonomy of languages. > We currently have the taxonomy of major modes, with which we're pretty > familiar, and we've had many years to learn about its downsides, > complexity, as well as how to deal with them, but for languages we're > only familiar with the easy cases, which makes us judge the idea in > a way that may prove naive. Some of us perhaps familiar with more cases than others. > IME, deciding what is the type of the content of a buffer is usually > trivial but with some notable caveats, such as XPM or Postscript files, > or "container formats" (like `.deb` or `.odt`, as well as things like > DocBook which can be considered either as their own format or as XML), Sounds like DocBook could be viewed using different major modes. I'm not sure whether they should be classified as different languages in general in such cases, but here is sounds like :doc_book vs :xml. > or "sublanguages" such as C being a subset of C++, or Javascript being > a subset of Typescript. And I suspect the info we need will not always > be quite the same. So far my understanding is that "languages" would not have a hierarchy - no relation of being a "subset" or etc, because different applications will likely need different relations between such languages. Or none at all, most of the time. When a major mode is suitable for a number of languages, it can be expressed externally, e.g. using several entries in major-mode-alist-alist. > So while there might be a good case to be made to add some API functions > to query the language/type(s) of a given buffer (I'm not sure we'd need > the language of a given major mode, OTOH), or to find the preferred > mode(s) for a given language/type, I think it's worthwhile to try and > tweak our major mode taxonomy because it is information we must have > and information we know we will always have, so we should strive to make > it as good as we can. > > It shouldn't make it any harder to add language/type API functionality. > On the contrary it should make it easier. > > [ As suggested elsewhere in this thread, we could even try and merge > those taxonomies, e.g. using extra parents of the form `LANG-lang`. ] Inserting an extra parent called LANG-lang could work to contain the (mode->lang) mapping, but only if we decide that a mode can correspond to only one language, or if we are not going to run the language hook in the mode function. But if we don't, the extra complexity seems not worth it: we'll need the lang->mode mapping somewhere else anyway. And looking there (in major-mode-remap-alist) we could fetch the reverse relation just as well. This also wouldn't bring any of the other features I enumerated together with my patch. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 05:20:56 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 10:20:56 +0000 Received: from localhost ([127.0.0.1]:50884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ32V-0001AH-OF for submit@debbugs.gnu.org; Wed, 17 Jan 2024 05:20:56 -0500 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:43484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ32T-0001A4-Oj for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 05:20:54 -0500 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cd04078ebeso110574671fa.1 for <68246@debbugs.gnu.org>; Wed, 17 Jan 2024 02:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705486847; x=1706091647; 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=Qs/Rs1n5qQ7STKKy0IdALoVEvJaWV58iZEJRKqAmAE0=; b=JDREzb5lJDS+DTjkZW1hXL7u5N7SVKgqo3rOIwspwry/NmX3XlF6P43naUeoQW2wl2 XO7/RNx8JQD2aHOe1lHUZfOUO6SD/Oorzjs8XNLyUD9V1cU/3zG6psn5Wh2wEVgPfs6Y qitg9TaXT2uppAD2Lp6FZOlGoLNyVCP8VMJWLqsNOj873AY5S76nTxKJ/KL0munodg0M 5rrE2ffANmycadBkQMKtmL+3bXDshkTKSyQZ+3vGCIfgHLwxGdJpBYALSbP/ZypvB/yB ImuxoAv8Lo3T0riz0ShTCO++THjfexS5Mk+k6Z4MQFOxyiwjCMz/KhQTIFlL1umXG60m x3QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705486847; x=1706091647; 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=Qs/Rs1n5qQ7STKKy0IdALoVEvJaWV58iZEJRKqAmAE0=; b=Wknqjo2wWvSLMNwJ44UWUwQoR0O0ugX3h6KBKTCWj8/Un7gRRLEMXVf6I4ZpASee46 WX15IEVXqQKNOELc7rIS0XSXUvKO1BANZ+2AvVvgctjk/ppbp9i1QZH6xDpaX3ptX8ix nA+A8dYQd81IiggyokhOF0ICdMCO6hX2TElKaw4PBeFIUYDkwpiFkZoEh38wBhuKMo3l UETtrjlyuL19age3/zGbyEl58MgSkA8GoFcBb1IPoC6cneZGftbguwljG1xEVX5F3P66 OY0+vndePKDCgZHQddTWuOzDooPOB1MZ/sQkv3akhGColcT50NlgqjwOpzs9XYXtJme0 2qUw== X-Gm-Message-State: AOJu0Ywj7+Wh3Aanotkrugfz7trFZ1GF1kS8y+NVJBBjIkPWAmgW4deV x91iJwHUwyBa3C+SllrjAYMCpj1vjhAq68epf7k= X-Google-Smtp-Source: AGHT+IEbzLKyyRKr3vghzxfzfoizfeXWJpWjRDuNovzeSL+CHs0YeP9XFTIhxRvdMXHb7QjNCiO53+6MX3MI2wYooXo= X-Received: by 2002:a2e:9bc4:0:b0:2cd:1c04:4f6 with SMTP id w4-20020a2e9bc4000000b002cd1c0404f6mr473667ljj.24.1705486846508; Wed, 17 Jan 2024 02:20:46 -0800 (PST) MIME-Version: 1.0 References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <4105c743-45d0-48a0-a8bb-1ab457b9a256@gutov.dev> In-Reply-To: <4105c743-45d0-48a0-a8bb-1ab457b9a256@gutov.dev> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 17 Jan 2024 10:20:34 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Wed, Jan 17, 2024 at 2:41=E2=80=AFAM Dmitry Gutov wro= te: > An "abstract" mode is supposedly one that doesn't do anything. So it > doesn't have to be callable. No. Not "abstract" as in "Java interface", abstract as in "Java abstract class". > Anyway, that's +1 feature required for the implementation. Almost trivial feature. See patch after sig. It'll make this work: (define-derived-mode foo-mode prog-mode "Fooey" :abstract t (message "Hey from foo-mode")) (define-derived-mode bar-mode foo-mode "Barey" (message "Hey from bar-mode")) 'foo-mode' can't be called, but 'bar-mode can, of course. And it will call its parent. > > What if we filter by prog-mode? It would leave the ':ruby-base' and > > ':python-base' as false positives, I guess. But then we could reasonab= ly > > say that anything ending with '-base' is abstract (or use the > > aforementioned explicit abstract prop). > > We would also filter out :css, for example. Sure? I see a super-normal css-base-mode inheriting from prog-mode. > TeX modes also do not derive > from prog-mode. TeX does have an LSP server, however. At the end of the day we have to come to a conclusion of what we want to do. I want to find major modes that correspond to languages, right? So: * these outliers start inheriting from prog-mode * we inject new lang-mode between prog-mode and fundamental-mode and make outliers derive from that. * we say these outliers aren't languages * we code exceptions for these outliers It could even be that (derived-mode-add-parents 'tex-mode '(prog-mode)) is exactly what's needed here, showcasing how I think this particular heavy hammer should be used for the exception, not the rule. > > Yes. I don't see the full scan of m-m-remap-alist as problematic > > from a effiency perspective. If we decide it's the database, it's > > the database. It's unfortunate that the "alist" implementation is > > hardcoded in the name (which is why I would prefer a (:language "Foo") > > kwarg to define-derived-mode) but we can abstract the alist aspect > > away with accessors and do the usual "Do not change this variable > > directly, use these accessors instead". > > I'm not saying in advance that it will be slow. Just that it's a > different function. Ah. Right. And I think it's a good one. Eglot needs it, and so does Yasnippet, probably. > >> BTW, get-current-mode-for-language could be implemented in terms of > >> set-buffer-language. > > > > What does get-current-mode-for-language do exactly? > > The major-mode currently configured to be used for the language (through > m-m-a-alist, in the current proposal). set-auto-mode will choose it. Perfect. But the, "set-buffer-language" comment? Does a buffer object have to exist for that job to be done? > > Right. So maybe > > > > (or (with-current-buffer buffer (get-language-for-mode major-mode)) > > (let (kw) > > (and buffer-file-name > > (keywordp (setq kw (alist-get buffer-file-name auto-mode-a= list))) > > kw)) > > (consult-oracles) > > (error "Don't know what language this is, sorry")) > > Replied to this one in another email: referring to the results of the > computation of set-auto-mode is easier. But that's a technical detail. For sure, reuse as much code as possible. I was just illustrating the intended fallback logic. Jo=C3=A3o diff --git a/lisp/emacs-lisp/derived.el b/lisp/emacs-lisp/derived.el index dec5883767d..a9b67965416 100644 --- a/lisp/emacs-lisp/derived.el +++ b/lisp/emacs-lisp/derived.el @@ -143,6 +143,9 @@ define-derived-mode :interactive BOOLEAN Whether the derived mode should be `interactive' or not= . The default is t. + :abstract BOOLEAN + You'll never be able to use the CHILD mode directly + in a buffer, just use as a PARENT for other modes. BODY: forms to execute just before running the hooks for the new mode. Do not use `interactive' here. @@ -192,7 +195,9 @@ define-derived-mode (hook (derived-mode-hook-name child)) (group nil) (interactive t) - (after-hook nil)) + (abstract nil) + (after-hook nil) + (function-name child)) ;; Process the keyword args. (while (keywordp (car body)) @@ -201,9 +206,13 @@ define-derived-mode (:abbrev-table (setq abbrev (pop body)) (setq declare-abbrev nil)) (:syntax-table (setq syntax (pop body)) (setq declare-syntax nil)) (:after-hook (setq after-hook (pop body))) + (:abstract (setq abstract (pop body))) (:interactive (setq interactive (pop body))) (_ (pop body)))) + (when abstract + (setq function-name (gensym "--internal-")) + (put child 'abstract-mode function-name)) (setq docstring (derived-mode-make-docstring parent child docstring syntax abbrev)) @@ -245,13 +254,12 @@ define-derived-mode (put ',child 'derived-mode-parent ',parent)) ,(if group `(put ',child 'custom-mode-group ,group)) - (defun ,child () + (defun ,function-name () ,docstring ,(and interactive '(interactive)) ; Run the parent. (delay-mode-hooks - - (,(or parent 'kill-all-local-variables)) + (,(or (get parent 'abstract-mode) parent 'kill-all-local-variables)) ; Identify the child mode. (setq major-mode (quote ,child)) (setq mode-name ,name) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 05:31:59 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 10:32:00 +0000 Received: from localhost ([127.0.0.1]:50918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ3DD-00049S-CE for submit@debbugs.gnu.org; Wed, 17 Jan 2024 05:31:59 -0500 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:49471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ3DC-00049D-1Q for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 05:31:58 -0500 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2ccbc328744so131021571fa.3 for <68246@debbugs.gnu.org>; Wed, 17 Jan 2024 02:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705487511; x=1706092311; 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=iLJkmqzZE/WyYpk2wcp81AqEV2bnspaO061P80ZGbOM=; b=AorLhywfhdWgo7eN4SK3l2oz1lh/l5MTc6b/Cjpx7VphHqxFJEc1OyAeUVd21hipvE exXOiVWpxzeJ1ONg5tE6K5ttYCdiDPEuC8aUuKNKEvSb2EoKLwUCzrjNNQCvXHAto95z bkKRJGJU+UuZVxpzDXJsKyp4M99qzLx1TtxoQKSJrKjvp+WMTRFZ9w1Zd5Q+0FY2q+E/ TUjzKLbxKA+Io8VXbpm7kIqm4aikbRJUC65qclL6bH4K/2OrRgpsJFR4eQkyZg5VuSmD 6TKSFukaG5J47BXoGQyhqhvp/q3/w6Kkd/jZ409KpCidhkqZLEUOBK8Gwu9saBG/ckTJ 8pEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705487511; x=1706092311; 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=iLJkmqzZE/WyYpk2wcp81AqEV2bnspaO061P80ZGbOM=; b=a2/oZuP0NCV8QZfAEeWPHiJIcnihm2+IeiIVdTaOLk7uJUztYFWpiV3TzN0uRuIdv7 XVRQGg6ojcCTF8iFUfSQbcdpYjOb2k0Y+ZLCoiR1QSgihadODa03t6sgUq61G68cVhip Fnm1KDiuHhxISrp9Ok43AiBTjSbIRiFzfgs7Lag5UqIG3sx57HIwrXyUa4VPZY/jzG7n gOjZ8KeB6oz/qSpOZFFT26zb7NlpidQ5rGLCX0HBx8pmTxzCA+jVBIj9tC2QMLcHXGav FpcuB+IQH8ASbyH54725CVJm4rAmKZHP/f/ZNqs0WB3znop8KRhiS0NdrcECd7koiJdP Y+Eg== X-Gm-Message-State: AOJu0YzMf4H/Yj14yp7vQLlQ40jCiZAXN6PgPgS6/iIdhNcOUEj4DZwl higtsnKsC2UD94M1mlnjj73illzjAQ9vAmwhF9E= X-Google-Smtp-Source: AGHT+IFUAguH3hyda+oQuyDAE4RQXrIxCtffwxH4G2HcQiIbtShUiUKp9PXWrTtPZhYmtyOEp+KoUTOV2G7B98i3HfY= X-Received: by 2002:a2e:824b:0:b0:2cd:13bf:78df with SMTP id j11-20020a2e824b000000b002cd13bf78dfmr4073315ljh.11.1705487510807; Wed, 17 Jan 2024 02:31:50 -0800 (PST) MIME-Version: 1.0 References: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 17 Jan 2024 10:31:39 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Wed, Jan 17, 2024 at 2:06=E2=80=AFAM Dmitry Gutov wro= te: > > On 17/01/2024 00:00, Jo=C3=A3o T=C3=A1vora wrote: > > On Tue, Jan 16, 2024, 17:45 Dmitry Gutov wrote: > >> > >> On 16/01/2024 12:34, Jo=C3=A3o T=C3=A1vora wrote: > >>> I see no real categorization or classification. I just see > >>> a many-to-one mapping of major modes to languages. > >> > >> It might even be many-to-many, at least in some cases. > >> > >> E.g. js-ts-mode being good for both :js and :jsx. > > > >> > >> Not sure how useful this -to-many relation is going to be in the above > >> cases, but it's probably a good illustration of the possibility. > > > > According to https://react.dev, jsx is a "JavaScript syntax > > extension". So it would seem JSX is a superset of JS. If > > js-ts-mode parses it perfectly, it could be called > > jsx-ts-mode instead. > > The grammar tree-sitter-js supports JSX. So the mode is called js-ts-mode= . OK. In this case, I would just say js-ts-mode is for JavaScript. A future trivial js-tsx-mode would be for JavaScriptReact. Eglot doesn't support the "JavaScriptReact" LSP language-id because of this, and noone has complained (they have about ts and tsx tho). > tsx-ts-mode is probably okay for both :tsx, :jsx and :js but not > :typescript (in general, because of certain clashing syntax). Right. Which makes sense. Like my-c++-mode is "probably okay" for C, but that doesn't mean my-c++-mode isn't the mode for the C++ language (or family of languages commonly denominated as "C++") Ergo, as I see it, tsx-ts-mode is the mode for TypeScriptReact, a language which happens to be a superset of some other languages. > > At the end of the day, a language is not so easy to define, > > but it's not that problematic either, especially in the editor > > (in the compiler, it's much more important). > > > > The best sources are a standard, when it exists, but each iteration, > > sometimes each compiler is also its own language. There's "GNU C", > > "ANSI C", C17, C23. All handled by the C modes we have and the best > > way we have to designate this is just "C". c++-mode also handles > > this code by the way, probably flawlessly, and yet we don't say > > c++-mode is for C and C++. > > > > But if you want, I don't think there's any big problem > > in making get-language-for-mode return a list, with > > the most important likely language at the top. > > It would be a problem if we decide that the major mode function runs the > language-specific hook, and not set-auto-mode-0 like in my patch > (because the mmode function would like run the hooks for all supported > languages, rather than just the current one). I see. Right. > > I predict it'll be pretty rare, but I guess you could > > have this (excuse the ugly CamelCase for demo purposes) > > It might indeed be rare enough for this to be a problem, and we might > even decide to prohibit such usage, keeping the relation many-to-one. I'd think that is fine. > > (setq auto-mode-alist '(("\\.js$" . :JavaScript) > > ("\\.jsx$" . :JavaScriptReact))) > > > > (setq m-m-remap-alist '((:JavaScript . js-ts-mode) > > (:JavaScriptReact . js-ts-mode))) > > It indeed should work okay with my proposal, but might be harder to do > if the languages are inserted as part of the existing modes hierarchy > (e.g. as "abstract" symbols). I don't follow. Are you referencing the other mail? That (:abstract t) idea was mostly crafted for the base-mode approach. It's not strictly needed with your patch (though I don't see how it hurts either). > That is assuming we do want the language > hook to run - which seems like important goal from my POV. Not absolutely essential to fix current problems, but yes I agree it's natural enough that it should be in the proposal. > > And 'buffer-language' becomes more like: > > > > (or buffer-overriding-language-keyword > > (with-current-buffer buffer (get-language-for-mode major-mode)) > > (let (kw) > > (and buffer-file-name > > (keywordp > > (setq kw > > ;; yes I know this needs regexps > > (alist-get buffer-file-name auto-mode-alist))) > > There is a bunch of variables to look up: auto-mode-alist, > magic-mode-alist, interpreter-mode-alist, magic-fallback-mode-alist. I > didn't want to duplicate the logic from set-auto-mode, but this of > course could be done. I was just illustrating the fallback logic. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 12:09:13 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 17:09:13 +0000 Received: from localhost ([127.0.0.1]:53198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ9Pd-0001IN-91 for submit@debbugs.gnu.org; Wed, 17 Jan 2024 12:09:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ9Pb-0001I9-N2 for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 12:09:12 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9123C100068; Wed, 17 Jan 2024 12:09:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705511343; bh=7xgEJiqn57WDdYqS6U/PVtuahchK70mP+d5+bwur2fY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DoltqL9SCro1eepFzl4oelVGtkV92apGZEhBiIGcl1k/JO/LVvFVsVXfu0Ri9NZyf 9cT7naK0M/MG4ePwXKAJL6hqKU4xSAQaoHq3hy/3jMr3lznSgBEoH/fqueOFhX+We1 rZ9oTJHiwnLsKx8AvBni03NaiMcjSpMlz4co963Lomv0hXHcjxXZENxyAgpjT+74cP 2pJyQakIXn7t3UUTOSpyRaT+71wz442sQhprsP6dUKFKicsOSR3KbcBQfhzQfzq9IO pA7+ZSiF2zbVr9Rv030kK8TaxbDTeKr2gaZGYPCFRmNB5oD8sblGUBuoQJ80v+W5i+ McNF5NwfhPsJw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6BB1110001D; Wed, 17 Jan 2024 12:09:03 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 589561209EF; Wed, 17 Jan 2024 12:09:03 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Dmitry Gutov's message of "Mon, 15 Jan 2024 04:10:16 +0200") Message-ID: References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> Date: Wed, 17 Jan 2024 12:08:02 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.460 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > @@ -3150,6 +3150,9 @@ auto-mode-alist > Visiting a file whose name matches REGEXP specifies FUNCTION as the > mode function to use. FUNCTION will be called, unless it is nil. > > +FUNCTION can also be a keyword denoting a language, to be looked > +up in `major-mode-remap-alist'. Side note: the intention is OK but `major-mode-remap-alist' is a defcustom and should remain nil by default. It's there for the users to express which major modes they prefer. So if we want a mapping between some new language/type concept and major modes, it should be stored elsewhere (could be a plain alist that's handled as a kind of "implicit tail of `major-mode-remap-alist`"). > @@ -3206,10 +3209,10 @@ interpreter-mode-alist > ("emacs" . emacs-lisp-mode))) > "Alist mapping interpreter names to major modes. > This is used for files whose first lines match `auto-mode-interpreter-regexp'. > -Each element looks like (REGEXP . MODE). > +Each element looks like (REGEXP . MODE-OR-LANGUAGE). > If REGEXP matches the entire name (minus any directory part) of > the interpreter specified in the first line of a script, enable > -major mode MODE. > +MODE-OR-LANGUAGE. There's a similar need for "content type" rather than "language". If we want to mention "language" we should also take the opportunity to mention other related categorizations like "content type". > - (funcall (alist-get mode major-mode-remap-alist mode)) > + ;; XXX: When there's no mapping for `:', we could also > + ;; look for a function called `-mode'. > + (funcall (alist-get mode major-mode-remap-alist (if (keywordp mode) > + #'fundamental-mode > + mode))) > + (when (keywordp mode) ;Perhaps do that unconditionally. > + (run-hooks (intern (format "%s-language-hook" (buffer-language))))) That seems wrong: - Why should this hook run when `auto-mode-alist` says `:js` but not when doing `M-x javascript-mode` (or other ways to enable this mode)? - Why run this hook *after* the mode's `:after-hook` and after things like `after-change-major-mode-hook`? I think it should remain the major mode's responsibility to decide which hooks it runs. > +(defun buffer-language () > + "Return the language of the current buffer. > +A language is a lowercase keyword with the name of the language." > + ;; Alternatively, we could go through all the matchers in > + ;; auto-mode-alist, interpreter-mode-alist, > + ;; magic-fallback-mode-alist here, possibly using a cache keyed on > + ;; buffer-file-name. But that's probably an overkill: if the user > + ;; changes the settings, they can call `M-x revert-buffer' at the end. > + (if (keywordp (car set-auto-mode--last)) > + (car set-auto-mode--last) > + ;; Backward compatibility. > + (intern (format ":%s" (replace-regexp-in-string "\\(?:-ts\\)?-mode\\'" "" > + (symbol-name major-mode)))))) I'm not comfortable enshrining the "-ts-mode" convention here. Also I think if we want a `buffer-language` function, it should not rely on how the mode was installed (e.g. `set-auto-mode--last`) but only on the major mode itself, i.e. something like (defun buffer-language () (or buffer-language (some heuristic based on major-mode and/or derived-modes))) [ Of course, I already mentioned that I also suspect that there can/will be sometimes several languages (or none). ] > +(defun set-buffer-language (language) > + "Set the language of the current buffer. > +And switch the major mode appropriately." > + (interactive > + (list (let* ((ct (mapcan > + (lambda (pair) (and (keywordp (car pair)) > + (list (symbol-name (car pair))))) > + major-mode-remap-alist)) > + (lang (completing-read "Language: " ct))) > + (and lang (intern lang))))) > + (set-auto-mode-0 language)) I see several issues with this function (name and implementation), but I wonder when we'd ever need such a thing. > ;;;###autoload > (dolist (name (list "node" "nodejs" "gjs" "rhino")) > - (add-to-list 'interpreter-mode-alist (cons (purecopy name) 'js-mode))) > + (add-to-list 'interpreter-mode-alist (cons (purecopy name) :js))) BTW, my suggested patch basically proposes to use `-mode` instead of `:LANG>` which saves us from those changes since that matches our historical conventions. Another issue I see if we don't use something like `derived-mode-add-parents` is that all the various places where we use mode-indexing, such as `.dir-locals.el`, `ffap`, YASnippet, etc... will need to be extended with a way to use "languages" as well, and then we also need to define a sane precedence between settings that apply to a given mode and settings that apply to a given language (setting for `js-ts-mode` should presumably take precedence over settings for `:js` which should take precedence over settings for `prog-mode`). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 18:37:31 2024 Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 23:37:31 +0000 Received: from localhost ([127.0.0.1]:53951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQFTP-0006JA-4b for submit@debbugs.gnu.org; Wed, 17 Jan 2024 18:37:31 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:34151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQFTN-0006Iv-5H for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 18:37:29 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 81C713200B09; Wed, 17 Jan 2024 18:37:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 17 Jan 2024 18:37:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705534640; x=1705621040; bh=+sdSee8wF8e8E417RjTuSQAFeTwSa+SM+ame1GWWX/Q=; b= sWteNvtialvloOJFXTJOpYlmZPZ5svQwQ8CfHobaZo9sy5aqxRcHfGeyhXNpKoUX gpaPaQjwGCq27XBqlJz4iQKhx0362ByoJtOF33nacwu/ot9nkdiHSS/SxNlNsXLm uYqAlo7Q6fHgxqT9fMK0PYhc36OruhTGObtcK3F5fBQGQvN9K/1c8o/mO91LYbpk /L4S+dq3cm6EG57QOaH7wCdg07dE+pPv8l/n8d5GBwqvfuW6bhJguKaJHNh5KMzn Qg8FUCPgxokJIiF6oHnYHFsapBCNirWkd05oUWeUH6k337TkealNcpcwljv7vjjr u7Ysvjaj1VVGJXAKyVpQTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705534640; x= 1705621040; bh=+sdSee8wF8e8E417RjTuSQAFeTwSa+SM+ame1GWWX/Q=; b=A c25zlJJgWvcsEYKRm+Pf8AJeFsx9U4Ip6fGMKDO2/DufJc2TOiNrD9uMfbga11Hk RG54ivhSNQ2Rt2HSo2v3Bqch08zlqIkMe3ME1Nt03wqyifA1NmgZHgMYY4bPs/aO bPJxvxgS+J/wopat0NZ5D0ExikDjQvh+JEq5x/8Wj0Y8PuBqAhZbL8bq1+dKtiSx 3bG9vubGf5tPbbi5kKkU/HIsSc6DJMa6VevM60aCAIIrUV3/CdwS50zhvODbH8RD Zdq2O2vx+yYN95gHc+L028uHlKHkl/Q1swGNj+vIMT+Vm7dxVjMUKqxYccGsrZzL e0OEuRPcq8wE3ai4+3BGw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejiedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepveffveefieefkedtudefieduhedvveffieetffduuefhkeeikeevleffhefh vddunecuffhomhgrihhnpehrvggrtghtrdguvghvnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Jan 2024 18:37:17 -0500 (EST) Message-ID: Date: Thu, 18 Jan 2024 01:37:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 17/01/2024 12:31, João Távora wrote: > On Wed, Jan 17, 2024 at 2:06 AM Dmitry Gutov wrote: >> >> On 17/01/2024 00:00, João Távora wrote: >>> On Tue, Jan 16, 2024, 17:45 Dmitry Gutov wrote: >>>> >>>> On 16/01/2024 12:34, João Távora wrote: >>>>> I see no real categorization or classification. I just see >>>>> a many-to-one mapping of major modes to languages. >>>> >>>> It might even be many-to-many, at least in some cases. >>>> >>>> E.g. js-ts-mode being good for both :js and :jsx. >>> >>>> >>>> Not sure how useful this -to-many relation is going to be in the above >>>> cases, but it's probably a good illustration of the possibility. >>> >>> According to https://react.dev, jsx is a "JavaScript syntax >>> extension". So it would seem JSX is a superset of JS. If >>> js-ts-mode parses it perfectly, it could be called >>> jsx-ts-mode instead. >> >> The grammar tree-sitter-js supports JSX. So the mode is called js-ts-mode. > > OK. In this case, I would just say js-ts-mode is for JavaScript. > > A future trivial js-tsx-mode would be for JavaScriptReact. > Eglot doesn't support the "JavaScriptReact" LSP language-id > because of this, and noone has complained (they have about ts and > tsx tho). This is indeed an approach that would work for all such cases, at the cost of extra typing and additional file organization (e.g. each major mode needs to be sorted into some file - it's no problem for js-jsx-ts-mode, but somewhat different for a potential new obscure language without close relatives). >> tsx-ts-mode is probably okay for both :tsx, :jsx and :js but not >> :typescript (in general, because of certain clashing syntax). > > Right. Which makes sense. Like my-c++-mode is "probably okay" > for C, but that doesn't mean my-c++-mode isn't the mode for the C++ > language (or family of languages commonly denominated as "C++") > > Ergo, as I see it, tsx-ts-mode is the mode for TypeScriptReact, > a language which happens to be a superset of some other languages. What we couldn't do in this model, is create one small major mode called c-like-mode (which sets up a minimal syntax table), and use it for a bunch of languages like C, C++, JS, etc, delegating the major features such as syntax highlighting, indentation, imenu and completion to the LSP protocol (e.g. via Eglot). With no extra files required for many additional languages, just new entries in eglot-server-programs. Of course it's not critical that we'd be able to do this, but seems interesting as a concept. >>> (setq auto-mode-alist '(("\\.js$" . :JavaScript) >>> ("\\.jsx$" . :JavaScriptReact))) >>> >>> (setq m-m-remap-alist '((:JavaScript . js-ts-mode) >>> (:JavaScriptReact . js-ts-mode))) >> >> It indeed should work okay with my proposal, but might be harder to do >> if the languages are inserted as part of the existing modes hierarchy >> (e.g. as "abstract" symbols). > > I don't follow. Are you referencing the other mail? That > (:abstract t) idea was mostly crafted for the base-mode approach. > It's not strictly needed with your patch (though I don't see how > it hurts either). Yep. If we're referencing my patch, then many-to-many should work with it, of course. >> That is assuming we do want the language >> hook to run - which seems like important goal from my POV. > > Not absolutely essential to fix current problems, but yes I agree > it's natural enough that it should be in the proposal. > >>> And 'buffer-language' becomes more like: >>> >>> (or buffer-overriding-language-keyword >>> (with-current-buffer buffer (get-language-for-mode major-mode)) >>> (let (kw) >>> (and buffer-file-name >>> (keywordp >>> (setq kw >>> ;; yes I know this needs regexps >>> (alist-get buffer-file-name auto-mode-alist))) >> >> There is a bunch of variables to look up: auto-mode-alist, >> magic-mode-alist, interpreter-mode-alist, magic-fallback-mode-alist. I >> didn't want to duplicate the logic from set-auto-mode, but this of >> course could be done. > > I was just illustrating the fallback logic. Not 100% clear where 'buffer-overriding-language-keyword' would come from. If set-buffer-language was the main entry point for overriding a buffer's language, however, its approach of overriding the cached info (currently set by set-auto-mode-0) seems the easiest. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 17 19:47:30 2024 Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 00:47:30 +0000 Received: from localhost ([127.0.0.1]:54001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQGZ7-0004uV-E9 for submit@debbugs.gnu.org; Wed, 17 Jan 2024 19:47:29 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:40493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQGZ5-0004uH-4P for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 19:47:27 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AB5B55C01E4; Wed, 17 Jan 2024 19:47:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 17 Jan 2024 19:47:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705538840; x=1705625240; bh=iHTEoq2RjcPLmqNyw8ZblEXUbfnBteP2JmN/G43U7sk=; b= p4QL/JSTyrSo9Youtk2Pd4gRKGrtsH1qPZOjkmyx8r4yINBCh5Wewh+hL7+fgLdC Zc5V0+3COnZKuq8PuviTziWGvNbOai4ifqDeVC6B5ld5J8mR3zfEv+/OVQNmGQyb hGiEZTfKEwOnmp5u0qq4buqnJ0p5vSQM3dWL+LGSWsJ7/Q26FTvFx9r8ei0A/icu y+a0uLPTZ6CAVQWU9YqXBbLlguVFN8lHZgy9qQG3/MeacDO6e/eYx4uq+611OhdB oLnXr78sVJI8QdD7fF9ZobB9V6jzo/FJB08iNwYMQqGuHeq2W1YZu31kIY6J6cdx uh+PFVHNKlqArzc/z40mOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705538840; x= 1705625240; bh=iHTEoq2RjcPLmqNyw8ZblEXUbfnBteP2JmN/G43U7sk=; b=k rHnCbROd7smR2PYtou4ncgCjbdSRpm8ZH7wNLYayA9I/kZ6ho2cXHCkj2mO5qf/C u9pU1QyiDE6x1OnQZkWP/fVfdnhMK0Pq3g49EO8Cxh6ajkjadhMgbkQqDVLZpdQ1 vzxQ+TBYRAvq2th/5N9nVCnHz2p9sxpF76kJmpgyyeS2+6uW33Rocy2niBGwY3AZ LjVU06tosgpAjwxWkO7nxoFjt4d0eICyQmxz5KpgsAQQNMO53ghLT90dstA1Xmtl MrzJhy35dVr/qzIBJ3DLRtYi7pPl//FLACoAuw34kIhlDGDfZTvlwv1B9QK554fu Udwe4oHQsPSdOSs8c25aw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejiedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Jan 2024 19:47:18 -0500 (EST) Message-ID: <46a9581a-9c5b-4a55-8717-ffd7d1c0a4bc@gutov.dev> Date: Thu, 18 Jan 2024 02:47:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <4105c743-45d0-48a0-a8bb-1ab457b9a256@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 17/01/2024 12:20, João Távora wrote: > On Wed, Jan 17, 2024 at 2:41 AM Dmitry Gutov wrote: > >> An "abstract" mode is supposedly one that doesn't do anything. So it >> doesn't have to be callable. > > No. Not "abstract" as in "Java interface", abstract as in "Java > abstract class". > >> Anyway, that's +1 feature required for the implementation. > > Almost trivial feature. See patch after sig. It'll make this work: > > (define-derived-mode foo-mode prog-mode "Fooey" :abstract t > (message "Hey from foo-mode")) > (define-derived-mode bar-mode foo-mode "Barey" > (message "Hey from bar-mode")) > > 'foo-mode' can't be called, but 'bar-mode can, of course. And it > will call its parent. What would such an "abstract" parent do anyway? Still set up keymaps etc? >>> What if we filter by prog-mode? It would leave the ':ruby-base' and >>> ':python-base' as false positives, I guess. But then we could reasonably >>> say that anything ending with '-base' is abstract (or use the >>> aforementioned explicit abstract prop). >> >> We would also filter out :css, for example. > > Sure? I see a super-normal css-base-mode inheriting from > prog-mode. > >> TeX modes also do not derive >> from prog-mode. TeX does have an LSP server, however. > > At the end of the day we have to come to a conclusion of what > we want to do. I want to find major modes that correspond > to languages, right? So: Right. But I suppose it's more or less the set of modes that correspond to file types (files on disk). Even text-mode, often used as a fallback, could have a language ("plain text") - you can see this file type (or "language mode") in the dropdown list of choices in editors that support switching between them with a mouse (e.g. VS Code). > * these outliers start inheriting from prog-mode > * we inject new lang-mode between prog-mode and fundamental-mode and make > outliers derive from that. > * we say these outliers aren't languages > * we code exceptions for these outliers > > It could even be that > > (derived-mode-add-parents 'tex-mode '(prog-mode)) > > is exactly what's needed here, showcasing how I think this > particular heavy hammer should be used for the exception, not > the rule. Also, arguably, Makefile-mode should not be a prog-mode derivative because its indent-line-function is not meaningful. But we want to support it with LSP anyway (I think), and with other features that dispatch based on the current language. >>>> BTW, get-current-mode-for-language could be implemented in terms of >>>> set-buffer-language. >>> >>> What does get-current-mode-for-language do exactly? >> >> The major-mode currently configured to be used for the language (through >> m-m-a-alist, in the current proposal). set-auto-mode will choose it. > > Perfect. But the, "set-buffer-language" comment? Does a buffer object > have to exist for that job to be done? No, you could just do something like (defun get-current-mode-for-language (lang) (with-temp-buffer (set-buffer-language lang) major-mode)) From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 18 00:06:13 2024 Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 05:06:13 +0000 Received: from localhost ([127.0.0.1]:54141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQKbV-0007Qz-1W for submit@debbugs.gnu.org; Thu, 18 Jan 2024 00:06:13 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:39459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQKbP-0007QS-9q for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 00:06:11 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 79B2C5C008F; Thu, 18 Jan 2024 00:06:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 18 Jan 2024 00:06:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705554360; x=1705640760; bh=eqEoiVaxRMzqlEgewSc5MeTZ940IF/ix07oysZknEBY=; b= qD6qI6P/qQEJvBrv3SUxaZIsVo2LKA5zDkvAl6HTiTL/WEFzha/m5R9oy8D0DMZf dxxktVnPIbXorAfvvQe9UljvMjEh4UTNTVzjQGa1/mU6m6C1R7kVpkeEUzk5ijGn QDhDZ81n89CvDmDkdOfkwTbNczyJQqfaN8q+PZq6xGQ109qujTNq2HjNrY+1kBJz j18RFUlGGoFI2EmVm4eAUDGmPMpEgQyxYQxMmvm/7+WL486J2wFZQN5dbox8LqHZ J13BYh3pqMzHUIkLXn6euSB+EFb+oNnIXOMsQ6WVXxBsdUE1QZfgoCqRgil3hDbJ ZiywSx+f2pUN2nvjRZi2Xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705554360; x= 1705640760; bh=eqEoiVaxRMzqlEgewSc5MeTZ940IF/ix07oysZknEBY=; b=f 13KQA/DjxjYtSw3w2Ovbif0EzICQKHqxvq7aj1wEr2slMkWOEgZM2fY4o0jB6G61 h+8xQIDu5n22q7EEVHt/djb9eu0CEqPg3OxMTQgiW/JLfa9HVhjI4hCFLogqa3rk BGyLOhhilrwKSSPag2VQX0I7q9kNcLIaTX57v4VbJUNdHLR3IDcAENMwOA2NhRor 0NSlq6AnW7DCCWvdkXY/ioSTG7wD9C4E2PeHJaeYSUlB+D6n0o/ohhZqXRMr/qNt Yu8rUJDOWWSq/8bxY4kfk+1sxVjMzFzO9qu7WkY7+XFNmd9ygUo6/9gwWjPnCF2c 179STqRwH49TTAh5K9Xhg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejiedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Jan 2024 00:05:58 -0500 (EST) Message-ID: <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> Date: Thu, 18 Jan 2024 07:05:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 17/01/2024 19:08, Stefan Monnier wrote: >> @@ -3150,6 +3150,9 @@ auto-mode-alist >> Visiting a file whose name matches REGEXP specifies FUNCTION as the >> mode function to use. FUNCTION will be called, unless it is nil. >> >> +FUNCTION can also be a keyword denoting a language, to be looked >> +up in `major-mode-remap-alist'. > > Side note: the intention is OK but `major-mode-remap-alist' is > a defcustom and should remain nil by default. It's there for the users > to express which major modes they prefer. So if we want a mapping > between some new language/type concept and major modes, it should be > stored elsewhere (could be a plain alist that's handled as a kind of > "implicit tail of `major-mode-remap-alist`"). Good point. The user can customize it and lose the non-default modes configured for a language. The way I introduced languages as keywords was an experiment, really. Mostly to save on typing - because the first plan was to have a parallel set of alists (since we can't right away deprecate the file -> mmode mappings right away). The language-specific version of major-mode-remap-alist looks necessary after all. >> @@ -3206,10 +3209,10 @@ interpreter-mode-alist >> ("emacs" . emacs-lisp-mode))) >> "Alist mapping interpreter names to major modes. >> This is used for files whose first lines match `auto-mode-interpreter-regexp'. >> -Each element looks like (REGEXP . MODE). >> +Each element looks like (REGEXP . MODE-OR-LANGUAGE). >> If REGEXP matches the entire name (minus any directory part) of >> the interpreter specified in the first line of a script, enable >> -major mode MODE. >> +MODE-OR-LANGUAGE. > > There's a similar need for "content type" rather than "language". If we > want to mention "language" we should also take the opportunity to > mention other related categorizations like "content type". Are "content type" and "language" going to be different things? They seem the same to me. >> - (funcall (alist-get mode major-mode-remap-alist mode)) >> + ;; XXX: When there's no mapping for `:', we could also >> + ;; look for a function called `-mode'. >> + (funcall (alist-get mode major-mode-remap-alist (if (keywordp mode) >> + #'fundamental-mode >> + mode))) >> + (when (keywordp mode) ;Perhaps do that unconditionally. >> + (run-hooks (intern (format "%s-language-hook" (buffer-language))))) > > That seems wrong: > - Why should this hook run when `auto-mode-alist` says `:js` but not > when doing `M-x javascript-mode` (or other ways to enable this mode)? > - Why run this hook *after* the mode's `:after-hook` and after > things like `after-change-major-mode-hook`? > > I think it should remain the major mode's responsibility to decide which > hooks it runs. On one hand, this is an artefact of not implementing the language-classification inside define-derived-mode. OTOH, the major mode can only run the language hook, I think, if any major mode can correspond only to one language. Though I suppose if set-auto-mode-0 saves the currently "detected" language somewhere, the major mode definitions could pick it up and call the corresponding hook. Hmm, perhaps in that case the major modes won't need any special attribute in their definitions (to specify their language): any major mode would run -language-hook where is the language detected for the buffer or assigned explicitly. >> +(defun buffer-language () >> + "Return the language of the current buffer. >> +A language is a lowercase keyword with the name of the language." >> + ;; Alternatively, we could go through all the matchers in >> + ;; auto-mode-alist, interpreter-mode-alist, >> + ;; magic-fallback-mode-alist here, possibly using a cache keyed on >> + ;; buffer-file-name. But that's probably an overkill: if the user >> + ;; changes the settings, they can call `M-x revert-buffer' at the end. >> + (if (keywordp (car set-auto-mode--last)) >> + (car set-auto-mode--last) >> + ;; Backward compatibility. >> + (intern (format ":%s" (replace-regexp-in-string "\\(?:-ts\\)?-mode\\'" "" >> + (symbol-name major-mode)))))) > > I'm not comfortable enshrining the "-ts-mode" convention here. We can still go the "strict" approach, where when no language is assigned, we don't try to guess it. > Also I think if we want a `buffer-language` function, it should not rely > on how the mode was installed (e.g. `set-auto-mode--last`) but only on > the major mode itself, i.e. something like > > (defun buffer-language () > (or buffer-language Where would the buffer-language variable be set, if not inside set-auto-mode-*? > (some heuristic based on major-mode and/or derived-modes))) If we're sure we don't want several languages to be able to refer to the same major mode... > [ Of course, I already mentioned that I also suspect that there can/will > be sometimes several languages (or none). ] I'm not clear on this. You mentioned complex cases - like an xml inside an archive? But depending on the usage, only one of the languages might be "active" at a given time. Or a combination of languages would simply be another language, basically. A more specific scenario might clarify this better. >> +(defun set-buffer-language (language) >> + "Set the language of the current buffer. >> +And switch the major mode appropriately." >> + (interactive >> + (list (let* ((ct (mapcan >> + (lambda (pair) (and (keywordp (car pair)) >> + (list (symbol-name (car pair))))) >> + major-mode-remap-alist)) >> + (lang (completing-read "Language: " ct))) >> + (and lang (intern lang))))) >> + (set-auto-mode-0 language)) > > I see several issues with this function (name and implementation), but > I wonder when we'd ever need such a thing. It seemed like a missed opportunity not to provide a more high-level command to switch to a specific language for the buffer. E.g. how we sometimes use 'M-x foo-major-mode' when a file type's been misdetected, or the buffer is non-file-visiting (perhaps very temporary). A command which does this with exhaustive completion across the configured languages seems handy. At least that's my impression from briefly testing it out. Also, get-current-mode-for-language can be implemented in terms of set-buffer-language (see my earlier email to Joao). >> ;;;###autoload >> (dolist (name (list "node" "nodejs" "gjs" "rhino")) >> - (add-to-list 'interpreter-mode-alist (cons (purecopy name) 'js-mode))) >> + (add-to-list 'interpreter-mode-alist (cons (purecopy name) :js))) > > BTW, my suggested patch basically proposes to use `-mode` instead > of `:LANG>` which saves us from those changes since that matches our > historical conventions. -mode is lexically indistinguishable from -mode. If we used the names like -lang, at least one could tell whether one of the parents of a given -mode is a language. > Another issue I see if we don't use something like > `derived-mode-add-parents` is that all the various places where we use > mode-indexing, such as `.dir-locals.el`, `ffap`, YASnippet, etc... will > need to be extended with a way to use "languages" as well, and then we > also need to define a sane precedence between settings that apply to > a given mode and settings that apply to a given language (setting for > `js-ts-mode` should presumably take precedence over settings for > `:js` which should take precedence over settings for `prog-mode`). That's a good point: if "languages" as a separate notion gets added, it would make sense to use them in more places (not 100% necessary, but good for consistency). With the associated complexity that you mention. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 18 09:17:39 2024 Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 14:17:39 +0000 Received: from localhost ([127.0.0.1]:54586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQTD8-0003wc-4U for submit@debbugs.gnu.org; Thu, 18 Jan 2024 09:17:39 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQTD2-0003wK-Pf for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 09:17:36 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 09A5A444184; Thu, 18 Jan 2024 09:17:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705587441; bh=cqmEuhVpX4uYkFYRPGqj9LAqBW1MxphIYjfKuBCGeXM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jVDlx/gDPKtKtkwLbLQNDbCmIYHgg1cCYWPirc2Hy/pibtS+UAusshVSuDhmW+ZcY DW1Oy6csiKrBsUbJNw3pG84Qcnp8C/FJ6onGHgLnmfImBaTut+bJ8u7vKQPJJewOSm 0dhgVXo2fMoOutn0mNSa9TO7w0ZKM2UY1nOdbe+naeC4A6UUlCZ/ulJtMUH7ITy/DJ iMMdeLRT3EJzIp8UiG3LcM8UYyPlMctQPW5eOrgGjPdyoi0lUlE9AdnRq1MHt/r9i2 iiYk5j4np/u2/pWcWzKnIuCcZ/4N3G5CSKkpW3kWXR0s2u0aYrC17kHC8RFxMD5IMb W8Npu9qttR/TA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DB5D4444180; Thu, 18 Jan 2024 09:17:21 -0500 (EST) Received: from pastel (unknown [45.72.229.100]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A0CDC120470; Thu, 18 Jan 2024 09:17:21 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> (Dmitry Gutov's message of "Thu, 18 Jan 2024 07:05:55 +0200") Message-ID: References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> Date: Thu, 18 Jan 2024 09:17:15 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.026 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > away). The language-specific version of major-mode-remap-alist looks > necessary after all. It doesn't have to be specifically about languages. It can just be a "default" set of "major mode" remappings. >>> @@ -3206,10 +3209,10 @@ interpreter-mode-alist >>> ("emacs" . emacs-lisp-mode))) >>> "Alist mapping interpreter names to major modes. >>> This is used for files whose first lines match `auto-mode-interpreter-regexp'. >>> -Each element looks like (REGEXP . MODE). >>> +Each element looks like (REGEXP . MODE-OR-LANGUAGE). >>> If REGEXP matches the entire name (minus any directory part) of >>> the interpreter specified in the first line of a script, enable >>> -major mode MODE. >>> +MODE-OR-LANGUAGE. >> There's a similar need for "content type" rather than "language". If we >> want to mention "language" we should also take the opportunity to >> mention other related categorizations like "content type". > Are "content type" and "language" going to be different things? > They seem the same to me. I think there's the same kind of difference between "language" and "content type" as between "language" and "major mode" :-) > OTOH, the major mode can only run the language hook, I think, if any major > mode can correspond only to one language. Not so. A major mode can easily do (run-mode-hooks (compute-the-hook)) > Though I suppose if set-auto-mode-0 saves the currently "detected" > language somewhere, the major mode definitions could pick it up and > call the corresponding hook. Major modes are not activated solely via `set-auto-mode-0`, so relying on that is a crutch/hack, not something on which to base a design. >> I'm not comfortable enshrining the "-ts-mode" convention here. > We can still go the "strict" approach, where when no language is assigned, > we don't try to guess it. I think the `-mode` heuristic is acceptable, because it's been *the* convention used in Emacs. >> Also I think if we want a `buffer-language` function, it should not rely >> on how the mode was installed (e.g. `set-auto-mode--last`) but only on >> the major mode itself, i.e. something like >> (defun buffer-language () >> (or buffer-language > Where would the buffer-language variable be set, if not inside > set-auto-mode-*? In the major mode? >> (some heuristic based on major-mode and/or derived-modes))) > If we're sure we don't want several languages to be able to refer to the > same major mode... A major mode can (setq major-mode ...) If/when such "generic" major modes become a thing, and the `(setq major-mode ...)` hack becomes too inconvenient, we can devise a better solution (e.g. extending/tweaking the way `derived-mode-*` work). >> [ Of course, I already mentioned that I also suspect that there can/will >> be sometimes several languages (or none). ] > I'm not clear on this. You mentioned complex cases - like an xml inside an > archive? But depending on the usage, only one of the languages might be > "active" at a given time. But depending on what "the language/type/mode" is used for, we may not care really about which language/type/mode is "active" but about which languages/types/modes are applicable (e.g. for `.dir-locals.el`). >>> +(defun set-buffer-language (language) >>> + "Set the language of the current buffer. >>> +And switch the major mode appropriately." >>> + (interactive >>> + (list (let* ((ct (mapcan >>> + (lambda (pair) (and (keywordp (car pair)) >>> + (list (symbol-name (car pair))))) >>> + major-mode-remap-alist)) >>> + (lang (completing-read "Language: " ct))) >>> + (and lang (intern lang))))) >>> + (set-auto-mode-0 language)) >> I see several issues with this function (name and implementation), but >> I wonder when we'd ever need such a thing. > > It seemed like a missed opportunity not to provide a more high-level command > to switch to a specific language for the buffer. E.g. how we sometimes use > 'M-x foo-major-mode' when a file type's been misdetected, or the buffer is > non-file-visiting (perhaps very temporary). > > A command which does this with exhaustive completion across the configured > languages seems handy. At least that's my impression from briefly testing > it out. We can do the same with major modes, of course (just `mapatom` and filter out the non-major modes), so feel free to add such a command, but it doesn't seem like offering it for "languages" is particularly more useful than offering it for "major modes". > Also, get-current-mode-for-language can be implemented in terms of > set-buffer-language (see my earlier email to Joao). That seems to be a roundabout way to go about it. `get-current-mode-for-language/type/mode` should be used by `set-auto-mode` rather than other way around, no? > -mode is lexically indistinguishable from -mode. If we used > the names like -lang, at least one could tell whether one of the > parents of a given -mode is a language. Other than for Eglot, where does this distinction matter? >> Another issue I see if we don't use something like >> `derived-mode-add-parents` is that all the various places where we use >> mode-indexing, such as `.dir-locals.el`, `ffap`, YASnippet, etc... will >> need to be extended with a way to use "languages" as well, and then we >> also need to define a sane precedence between settings that apply to >> a given mode and settings that apply to a given language (setting for >> `js-ts-mode` should presumably take precedence over settings for >> `:js` which should take precedence over settings for `prog-mode`). > That's a good point: if "languages" as a separate notion gets added, it > would make sense to use them in more places (not 100% necessary, but good > for consistency). With the associated complexity that you mention. And if it's not merged into the same hierarchy as major modes, how do you get `:js` (i.e. "language") to be sometimes higher-precedence and sometimes lower precedence than a mode? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 18 14:55:50 2024 Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 19:55:50 +0000 Received: from localhost ([127.0.0.1]:56717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQYUP-0005jx-AB for submit@debbugs.gnu.org; Thu, 18 Jan 2024 14:55:50 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQYUN-0005jj-IJ for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 14:55:48 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 5A4235C012C; Thu, 18 Jan 2024 14:55:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 18 Jan 2024 14:55:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705607740; x=1705694140; bh=FJAlxoYopnpzvDaTkRc6eN8pZK95fEYmRFJ5F1mprKA=; b= bqr6ePULKw2asPHmGHyla1jTu/CzFNhcPrKGPJ8vYj/6+Yhmj6Gms6loacVV4d93 ZZ0YDYMwUjHzV+FYHKArqbQ3tOVoMBdqxrdYOtj6i6fT7jzpYw2IwYzu8ui0ajjm /eGEpQK6GBtppKKXs3Ro9sxaaT+JRJUYl7AbwQVXx12vsz7JHM+EpJG3eL+cbRng vWuuakqLXLXoh7FP1T9bRdwrUKO3gi9uLi75gXEwbxXIpz/JSr1CstbVg800WixQ /Ado2PZ9ZTn9+Cp81pJuSwq7iH8yzRivpQ26jMUoRd2GaCpVmJC/kETwC8G/U3BK t272GiUkUKrwTT00sTYo1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705607740; x= 1705694140; bh=FJAlxoYopnpzvDaTkRc6eN8pZK95fEYmRFJ5F1mprKA=; b=t ewM/aPZLCLT/muCDqutkcOIVqP7aoAHr5S/0FMajuL9rckOH3vVfsp3FoFGqRAVM YsQ6dJodTKv5WuvNvpN0QjH0V7t6Rgc7lQU9XtseIBw8gokqC7845X4PyJQ9jmgi 6VEqZWCOs9tL5U3SRrlMlOOtNqC1fIHdoAh6sdmzWYP9Uw0oO7YSU+fCTo6rxkA9 /0d70c1NG9pIBV2un3Em6HQ/3Bd5DVvdbabURHAoaJPB8BnudXYTlLQgBz5Qktc/ JdFhE9T+EKxLX79oChzdDENSQfocXQP1tvDOKycBXjWh4BhXN/T8sp1cuiE+ZLMv mHRuFbabx+MtNiIEk4Nxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejkedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Jan 2024 14:55:38 -0500 (EST) Message-ID: <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Date: Thu, 18 Jan 2024 21:55:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 18/01/2024 16:17, Stefan Monnier wrote: >> away). The language-specific version of major-mode-remap-alist looks >> necessary after all. > > It doesn't have to be specifically about languages. > It can just be a "default" set of "major mode" remappings. Could be. And it's something we should probably add irrespective of the outcome of this dicsussion. >>>> @@ -3206,10 +3209,10 @@ interpreter-mode-alist >>>> ("emacs" . emacs-lisp-mode))) >>>> "Alist mapping interpreter names to major modes. >>>> This is used for files whose first lines match `auto-mode-interpreter-regexp'. >>>> -Each element looks like (REGEXP . MODE). >>>> +Each element looks like (REGEXP . MODE-OR-LANGUAGE). >>>> If REGEXP matches the entire name (minus any directory part) of >>>> the interpreter specified in the first line of a script, enable >>>> -major mode MODE. >>>> +MODE-OR-LANGUAGE. >>> There's a similar need for "content type" rather than "language". If we >>> want to mention "language" we should also take the opportunity to >>> mention other related categorizations like "content type". >> Are "content type" and "language" going to be different things? >> They seem the same to me. > > I think there's the same kind of difference between "language" and > "content type" as between "language" and "major mode" :-) A "content type" could be serviced by multiple "languages"? Still not sure how that would work. I mean, we could have content-type like text/html or application/json, but neither splits into two languages, really. >> OTOH, the major mode can only run the language hook, I think, if any major >> mode can correspond only to one language. > > Not so. A major mode can easily do > > (run-mode-hooks (compute-the-hook)) I guess that would mean that the language hook is not run automatically, that each major mode would need explicit code to compute it and run. >> Though I suppose if set-auto-mode-0 saves the currently "detected" >> language somewhere, the major mode definitions could pick it up and >> call the corresponding hook. > > Major modes are not activated solely via `set-auto-mode-0`, so relying > on that is a crutch/hack, not something on which to base a design. The major mode could compute which language it is for. But the algorithm could be undecidable if the buffer is not visiting a file yet, doesn't have an interpreter comment, etc. That's where the command set-buffer-language was supposed to come in handy. >>> I'm not comfortable enshrining the "-ts-mode" convention here. >> We can still go the "strict" approach, where when no language is assigned, >> we don't try to guess it. > > I think the `-mode` heuristic is acceptable, because it's been > *the* convention used in Emacs. We are now getting a whole set of new modes for which this heuristic isn't going to work (the tree-sitter based ones), and that list will grow. Perhaps it would be more consistent to drop the heuristic if we don't manage to make it work, somehow, for both kinds of modes. >>> Also I think if we want a `buffer-language` function, it should not rely >>> on how the mode was installed (e.g. `set-auto-mode--last`) but only on >>> the major mode itself, i.e. something like >>> (defun buffer-language () >>> (or buffer-language >> Where would the buffer-language variable be set, if not inside >> set-auto-mode-*? > > In the major mode? Then perhaps we won't need the fallbacks (the part that comes after 'or') - the major mode's setting of the language could perform those "heuristic based" computations as well. >>> (some heuristic based on major-mode and/or derived-modes))) >> If we're sure we don't want several languages to be able to refer to the >> same major mode... > > A major mode can > > (setq major-mode ...) > > If/when such "generic" major modes become a thing, and the `(setq major-mode ...)` > hack becomes too inconvenient, we can devise a better solution > (e.g. extending/tweaking the way `derived-mode-*` work). The major-mode could be fundamental-mode. If the language were to be specifiable through settings external to major modes, we could still do useful things while in fundamental-mode (e.g. do some useful editing with Eglot, provided it supports indentation and completion), or suggest which major modes to install from ELPA. >>> [ Of course, I already mentioned that I also suspect that there can/will >>> be sometimes several languages (or none). ] >> I'm not clear on this. You mentioned complex cases - like an xml inside an >> archive? But depending on the usage, only one of the languages might be >> "active" at a given time. > > But depending on what "the language/type/mode" is used for, we may not > care really about which language/type/mode is "active" but about which > languages/types/modes are applicable (e.g. for `.dir-locals.el`). Would we really care that an xml file inside an archive is applied both archive-subfile-mode and xml-mode dir-locals settings? Offhand, I would really expect the xml-mode settings only. Though the former could be a nice bonus in rare cases. Perhaps dir-locals.el could get a syntax for specifying variables when specific minor modes are enabled as well. >>>> +(defun set-buffer-language (language) >>>> + "Set the language of the current buffer. >>>> +And switch the major mode appropriately." >>>> + (interactive >>>> + (list (let* ((ct (mapcan >>>> + (lambda (pair) (and (keywordp (car pair)) >>>> + (list (symbol-name (car pair))))) >>>> + major-mode-remap-alist)) >>>> + (lang (completing-read "Language: " ct))) >>>> + (and lang (intern lang))))) >>>> + (set-auto-mode-0 language)) >>> I see several issues with this function (name and implementation), but >>> I wonder when we'd ever need such a thing. >> >> It seemed like a missed opportunity not to provide a more high-level command >> to switch to a specific language for the buffer. E.g. how we sometimes use >> 'M-x foo-major-mode' when a file type's been misdetected, or the buffer is >> non-file-visiting (perhaps very temporary). >> >> A command which does this with exhaustive completion across the configured >> languages seems handy. At least that's my impression from briefly testing >> it out. > > We can do the same with major modes, of course (just `mapatom` and filter out > the non-major modes), so feel free to add such a command, but it doesn't > seem like offering it for "languages" is particularly more useful than > offering it for "major modes". If modes are annotated with their languages, the result could be almost as handy indeed, so maybe I will add such command, later. >> Also, get-current-mode-for-language can be implemented in terms of >> set-buffer-language (see my earlier email to Joao). > > That seems to be a roundabout way to go about it. > `get-current-mode-for-language/type/mode` should be used by > `set-auto-mode` rather than other way around, no? If the major modes decide the language, and if we don't mind that this won't work without an installed/available major mode, yes. >> -mode is lexically indistinguishable from -mode. If we used >> the names like -lang, at least one could tell whether one of the >> parents of a given -mode is a language. > > Other than for Eglot, where does this distinction matter? I suppose it comes down to the ease of implementing interaction with any external tools that need to be passed a language name. If a function get-language-for-mode is possible to implement, then you only need to store the mapping language->language-name-spelled-in-specific-way for a number of exceptions, whereas if instead of get-language-for-mode you only have the full hierarchy of modes, then the mode->correct-spelling will likely need to be exhaustive in all cases, in order not to match any parent modes (e.g. prog-mode) that don't denote a language. And when such mappings have to be exhaustive, support for any new language would also need to be done explicitly in all cases. Eglot would need explicit mappings either way because the name of the language server program is always different (though they would be simplified), but something like 'rg -t js Foo' only needs the language name. >>> Another issue I see if we don't use something like >>> `derived-mode-add-parents` is that all the various places where we use >>> mode-indexing, such as `.dir-locals.el`, `ffap`, YASnippet, etc... will >>> need to be extended with a way to use "languages" as well, and then we >>> also need to define a sane precedence between settings that apply to >>> a given mode and settings that apply to a given language (setting for >>> `js-ts-mode` should presumably take precedence over settings for >>> `:js` which should take precedence over settings for `prog-mode`). >> That's a good point: if "languages" as a separate notion gets added, it >> would make sense to use them in more places (not 100% necessary, but good >> for consistency). With the associated complexity that you mention. > > And if it's not merged into the same hierarchy as major modes, how do > you get `:js` (i.e. "language") to be sometimes higher-precedence and > sometimes lower precedence than a mode? I'm not sure it's a requirement. If we decide that languages are "above" major modes, it would make just as much sense to first apply language settings, and then those for the major mode and its parents. Even though a language is often more specific than prog-mode. It can be different for other hierarchies (e.g. js-base-mode would be "below" language). We wouldn't want to specify the parent for each language as well, right? E.g. I suppose if js-language was a major mode which also inherits from prog-mode, a priority resolution algorithm could then decide that it's also lesser priority when applying local variables for any modes which add js-language as its extra parent. But that seems like more work (both for the writers to implement and for the users to understand) for relatively minor gain. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 18 16:25:04 2024 Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 21:25:04 +0000 Received: from localhost ([127.0.0.1]:56851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQZsm-0007KF-0b for submit@debbugs.gnu.org; Thu, 18 Jan 2024 16:25:04 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQZsk-0007Je-2S for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 16:25:02 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3BC3B10007D; Thu, 18 Jan 2024 16:24:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705613087; bh=415vTDOJ6NCHmwDEkrEw/fOVND7qfzyM3TUPBbn9UFU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o+eFHQwMN7v9ODoiXfSGriJOLhscp+bnq+fPULCxSBZ9cAoHaq+unoUmC+ydOrAJQ K+pioDj6BgB39y+QgZ+JzCQjey6V8iE8mXeC/jZOeeGy9Nsw15cI3CHUloA7S7w0V2 bcf6zE6oWnuRCrKY1yDnkGN2MJ+gJnfxrF8FdIk5tS2u/GrPWfn4LOHplWFHhCQQva QDxbvhvps5C3eAC2R9q53cZ6h4PKsk9dNE3lx+nw4r/3+G8fto1uo5dc7quxqkwsw1 gNesHD0+k0B0n4i/JRAsd1T2DmXKX8KH3FZymGGNE9GquJtbeDSBr1qevUEjMi39Hj +VXChad7V2Yxg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7BC2510001D; Thu, 18 Jan 2024 16:24:47 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45DE7120224; Thu, 18 Jan 2024 16:24:47 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> (Dmitry Gutov's message of "Thu, 18 Jan 2024 21:55:34 +0200") Message-ID: References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Date: Thu, 18 Jan 2024 16:24:46 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.140 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Still not sure how that would work. I mean, we could have content-type > like text/html or application/json, but neither splits into two > languages, really. Not sure what you mean by "split", but just as with major modes and "languages", MIME content-types have inclusion properties, such as application/atom+xml =E2=8A=82 application/xml =E2=8A=82 text/plain >>> OTOH, the major mode can only run the language hook, I think, if any ma= jor >>> mode can correspond only to one language. >> Not so. A major mode can easily do >> (run-mode-hooks (compute-the-hook)) > I guess that would mean that the language hook is not run automatically, > that each major mode would need explicit code to compute it and run. Not necessarily, e.g. you could specify the language to `define-derived-mode` with something like :language (compute-the-language) and then have `define-derived-mode` compute the hook name from that. This said, I suspect that generic major modes supporting many languages will not be very numerous (after all, that's the point of being generic, no?), so it should be OK if they have to do some things manually. >>> Though I suppose if set-auto-mode-0 saves the currently "detected" >>> language somewhere, the major mode definitions could pick it up and >>> call the corresponding hook. >> Major modes are not activated solely via `set-auto-mode-0`, so relying >> on that is a crutch/hack, not something on which to base a design. > The major mode could compute which language it is for. But the algorithm > could be undecidable if the buffer is not visiting a file yet, doesn't ha= ve > an interpreter comment, etc. That's where the command set-buffer-language > was supposed to come in handy. That still doesn't justify the major mode relying on `set-auto-mode-0`. AFAICT you seem to want to standardize how the user controls the language of language-generic major modes. I'm not sure we need such a standard. Do we even have such a generic major mode yet? >>>> I'm not comfortable enshrining the "-ts-mode" convention here. >>> We can still go the "strict" approach, where when no language is assign= ed, >>> we don't try to guess it. >> I think the `-mode` heuristic is acceptable, because it's been >> *the* convention used in Emacs. > We are now getting a whole set of new modes for which this heuristic isn't > going to work Cue the patch I submitted when I open this bug report =F0=9F=99=82 Now `-mode` is again included in `derived-mode-all-parents` for those new modes. Admittedly, it doesn't fully give a solution to the problem of computing "the" language of a buffer. But that gets us back to one of my recent questions: beside Eglot, which other package needs that? Is "the" language always unique and always the same for all those packages? Is it really the only thing those packages need? In the case of Eglot, at least it doesn't seem to be the case: we don't just need the language, but also the name of the language server to use. And for some buffers there can be several applicable language servers, and they don't necessarily all accept the same language. So we need either the major mode to provide the name of the server, or a central database that maps from language/type/mode to server name. In both cases, adding the language info to the server name is a non-issue. And in neither case is it necessary to know "the" language in order to find the server. My patch makes the central database work better. > The major-mode could be fundamental-mode. If the language were to be > specifiable through settings external to major modes, we could still do > useful things while in fundamental-mode (e.g. do some useful editing with > Eglot, provided it supports indentation and completion), or suggest which > major modes to install from ELPA. I don't see the interest of using specifically `fundamental-mode` for that. In any case, this seems too hypothetical at this stage to have a good idea of what we'd need in such circumstances. > Would we really care that an xml file inside an archive is applied both > archive-subfile-mode and xml-mode dir-locals settings? No, I wasn't thinking of XML files inside archives, but about files which are both archives and something else (e.g. ODT). The same applies for most other "generic" data containers, like XML and JSON. > Perhaps dir-locals.el could get a syntax for specifying variables when > specific minor modes are enabled as well. Or we could do something like (defun derived-mode-p (modes) (provided-mode-derived-p (or (funcall major-mode-function) major-mode) modes) or (defun derived-mode-current-all-parents () (or (funcall major-mode-all-parents-function) (derived-mode-all-parents major-mode))) So your XML major mode can indicate that the current buffer is actually in `xml+atom-mode` (which is a child of `xml-mode`). Anyway, as I mentioned elsewhere, I think this discussion of "languages" is only tangentially related to my proposed patch. There is some overlap, but they serve different purposes, and they're not mutually exclusive. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 18 20:28:30 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 01:28:31 +0000 Received: from localhost ([127.0.0.1]:57042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQdgM-000660-8A for submit@debbugs.gnu.org; Thu, 18 Jan 2024 20:28:30 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQdgJ-00065m-BH for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 20:28:28 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 42F295C0078; Thu, 18 Jan 2024 20:28:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 18 Jan 2024 20:28:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705627700; x=1705714100; bh=USdfc+qfe5GM7Dc4guaWoh/tf/2JKmQL7CpCB6jAlrA=; b= rq9h2H32TMpj+n7vO0/vaCZcRWpLj+CPkAUUOMYrl2OAy0XtPP2ArdJ10BoCbM7L bhoOJvwJdp6UZ89VX73z/mgGaq3c52RjELuLJQC75VcJhy1arZrxysqf7rbdMvd0 ao8mlMjRKIQmQ1VnaeZGlZCCBUcBqy8jrtlIRnhSIavMPK7x3C1yBEMxDKOk3tLc gR0mZnDlPSCaSBk90c5allhUINZVPt8PfbFl9kqH2mZurlhil5u1pAE1vaEaGNku raMzD8MGStQAS49ZkX+LHBPY6+Ww27KGTOV5/60m4wzWJ8F+gmqxUUvYdN0ErdgD Bz1mUeE8KyonwyTz6ppstw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705627700; x= 1705714100; bh=USdfc+qfe5GM7Dc4guaWoh/tf/2JKmQL7CpCB6jAlrA=; b=Z k05GiNDSfZZ3S2dz15sqqM6mNPGUrA0DjjSnKaTYR6JElOqxbwcdTR42q5L4Zc+U BRBe9c8lo91uHaE3O3QoealZu9szVSc1cTODBdDyi++eLllQTp6HHXJNEYY/xUv2 p0GozSyfQCUhs8GIvgJ0LCGz7/IglEe9K7omtNeJLREbTR/CN5E0NNiRxQnF7ycS CmFBN9lLTLNGXPFMv4IoLfFgcJ+bBozPpMOGOwOl6y8adlCPGQ2z2Qezq5fwiH3d /Lx0724vS+9OJEwlbmXLilzd3SVDCwKpohp2QJDs6KLO46vzmSN9lDiRteDQvagq SvCPg+W9y0d2bgQiY3gFw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Jan 2024 20:28:17 -0500 (EST) Message-ID: Date: Fri, 19 Jan 2024 03:28:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 18/01/2024 23:24, Stefan Monnier wrote: >> Still not sure how that would work. I mean, we could have content-type >> like text/html or application/json, but neither splits into two >> languages, really. > > Not sure what you mean by "split", but just as with major modes and > "languages", MIME content-types have inclusion properties, such as > > application/atom+xml ⊂ application/xml ⊂ text/plain I meant to try to clarify your meaning when you said that content-types are to languages the same as what languages are to major modes. That might mean that a content-type corresponds to a number of languages, just like a language corresponds to a number (open set) of major modes. But I don't see how. Please enlighten. Speaking of the relation of inclusion, as I said before we might not want to make languages hierarchical (even though it might help for certain cases), because the relation might not be universal across uses. And if you had the idea of expressing it through major mode inheritance as well, it's likely to have adverse effects, something like: (derived-mode-add-parents 'c++-ts-mode 'c++-lang) + (derived-mode-add-parents 'c++-lang 'c-lang) = (provided-mode-derived-p 'c++-ts-mode 'c-lang) Which can lead some callers to decide that c++-ts-mode's language is C. >>>> OTOH, the major mode can only run the language hook, I think, if any major >>>> mode can correspond only to one language. >>> Not so. A major mode can easily do >>> (run-mode-hooks (compute-the-hook)) >> I guess that would mean that the language hook is not run automatically, >> that each major mode would need explicit code to compute it and run. > > Not necessarily, e.g. you could specify the language to > `define-derived-mode` with something like > > :language (compute-the-language) > > and then have `define-derived-mode` compute the hook name from that. > This said, I suspect that generic major modes supporting many languages > will not be very numerous (after all, that's the point of being generic, > no?), so it should be OK if they have to do some things manually. Okay. The side-effect of this approach is that we basically declare a mode's language twice: once in the attribute above, and once in the major-mode-remap-alist which is put into autoloads. But it's probably minor enough. And if languages are distinct from major modes in naming, the :language attribute in define-derived-mode could make it run the corresponding hook at the end. Which seems good. >>>> Though I suppose if set-auto-mode-0 saves the currently "detected" >>>> language somewhere, the major mode definitions could pick it up and >>>> call the corresponding hook. >>> Major modes are not activated solely via `set-auto-mode-0`, so relying >>> on that is a crutch/hack, not something on which to base a design. >> The major mode could compute which language it is for. But the algorithm >> could be undecidable if the buffer is not visiting a file yet, doesn't have >> an interpreter comment, etc. That's where the command set-buffer-language >> was supposed to come in handy. > > That still doesn't justify the major mode relying on `set-auto-mode-0`. > > AFAICT you seem to want to standardize how the user controls the language of > language-generic major modes. I'm not sure we need such a standard. > Do we even have such a generic major mode yet? In my picture that was just the natural conclusion. What I was trying to do, is put a level of control above the major modes - the mapping from languages to modes, and make it more easy to control and configurable. It didn't seem that the presence of a major mode was required to detect the expected language, hence the addition of the new values. At that point it seemed natural to both allow the absence of a configured major mode (why not), and to run the language hook anyway, for reliability. If we really don't need any of that, then the auto-mode-alist and the companion vars don't even have to change, and the only place where the language name could feature (aside from the code looking it up), is the mode definitions. >>>>> I'm not comfortable enshrining the "-ts-mode" convention here. >>>> We can still go the "strict" approach, where when no language is assigned, >>>> we don't try to guess it. >>> I think the `-mode` heuristic is acceptable, because it's been >>> *the* convention used in Emacs. >> We are now getting a whole set of new modes for which this heuristic isn't >> going to work > > Cue the patch I submitted when I open this bug report 🙂 > Now `-mode` is again included in `derived-mode-all-parents` for > those new modes. If the language is called -lang instead (of without suffix), then the major mode could also run the language-specific hook, which in your patch it cannot do. > Admittedly, it doesn't fully give a solution to the problem of computing > "the" language of a buffer. But that gets us back to one of my recent > questions: beside Eglot, which other package needs that? Is "the" > language always unique and always the same for all those packages? > Is it really the only thing those packages need? > > In the case of Eglot, at least it doesn't seem to be the case: we don't > just need the language, but also the name of the language server to use. > And for some buffers there can be several applicable language servers, > and they don't necessarily all accept the same language. > > So we need either the major mode to provide the name of the server, or > a central database that maps from language/type/mode to server name. > In both cases, adding the language info to the server name is > a non-issue. And in neither case is it necessary to know "the" language > in order to find the server. My patch makes the central database > work better. I think I've included some thoughts on this subject in my previous email. They don't seem to be quoted/commented on here. >> The major-mode could be fundamental-mode. If the language were to be >> specifiable through settings external to major modes, we could still do >> useful things while in fundamental-mode (e.g. do some useful editing with >> Eglot, provided it supports indentation and completion), or suggest which >> major modes to install from ELPA. > > I don't see the interest of using specifically `fundamental-mode` for > that. In any case, this seems too hypothetical at this stage to have > a good idea of what we'd need in such circumstances. The latter feature (suggest which major modes to install) has come up recently. It's not that difficult to implement (with a whitelist of packages), and fundamental-mode is most likely *the* major mode which would be used until the suitable major mode is installed. >> Would we really care that an xml file inside an archive is applied both >> archive-subfile-mode and xml-mode dir-locals settings? > > No, I wasn't thinking of XML files inside archives, but about files > which are both archives and something else (e.g. ODT). The same applies > for most other "generic" data containers, like XML and JSON. Okay, ODT. Which we can view with either doc-view-mode or xml-mode. Languages :doc or :xml. We configure one of these langauges to be used by default, and switch to another at will. Not sure it's useful to consider both modes somehow active at the same time. Although this example does underscore the problem of major modes needing to be able to specify/change the current language themselves. At least if we don't want such modes as doc-view to have to be rewritten. On the third hand, external tools (lsp servers, ripgrep, etc) will view such files as a certain type only - just ODT. Which might make us a disservice if the current detected language changes as we change the major mode. Hmm. And since xml-mode itself doesn't know ODT, it won't be able to "compute" that language value either (same would likely be true for other "container" modes). > Anyway, as I mentioned elsewhere, I think this discussion of "languages" > is only tangentially related to my proposed patch. There is some > overlap, but they serve different purposes, and they're not > mutually exclusive. I think the "languages" feature seems to cover the same functionality as your patch, and then some. Although at the expense of the downstream callers having to use the new feature, rather than having things work "automagically" (as soon as they stop supporting Emacs 29.1, that is). From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 00:13:06 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 05:13:07 +0000 Received: from localhost ([127.0.0.1]:57229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQhBi-0002Pz-GY for submit@debbugs.gnu.org; Fri, 19 Jan 2024 00:13:06 -0500 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:42042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQhBf-0002PM-TH for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 00:13:04 -0500 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6db79e11596so376683b3a.0 for <68246@debbugs.gnu.org>; Thu, 18 Jan 2024 21:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705641176; x=1706245976; darn=debbugs.gnu.org; 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=YarmSZRDcZIXn09/6PE9PrJI5I+Iwz56k8XrBEx5JHY=; b=ZCRLXASeUYO8nSNrRMxkQDXl0I/H303g01bgQXeRPkE+V3m+K3Y1FUuOtcyi6BQ4eI 3rBAZtJyNnnRgsqlY53nw7f3VIjEElmcwSyLwoRm912BdEGyFfo2bx9y9YtWT10WMpgR ob+yJbuyOoX9Jq5u/T6t5qvLVkkQSMpVr6j1dI3+ilvhVwtbO9I4vBcSNsndem0CsKtJ ZrTQqOV1rtMupZdLRNDJm+wZCmGiCeMskuiSwi6TdPm0mBx9zvqWAnwr+EvB3lyGRQj0 8KgGegAUk6xJmAVHy4q0kvKH3gJjZuTHJzPOPFORWZuKccFMKcDZdjHjMtSWO3+IVBHk R7Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705641176; x=1706245976; 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=YarmSZRDcZIXn09/6PE9PrJI5I+Iwz56k8XrBEx5JHY=; b=sMEo3y2dK14dHrz4ROuQzf7kTCoRS1qtQjkep+qq/b/3VzM5G7sMOF1UF2L20Q7fwd dTeURZ4GX5CutSYlr8BrtcOsHoO215Uyue2ihZd8Gya+cvRXJU2bynYNNKoI31qToxQ9 CSei+il1TkUKlXa+oLwpFJpU0Q3Kj/sscj8eTv8OHtKOtqpwz6WzbKD7QsDTmyh7l+/H bC46IFF/3yRyMoT0iCSqDEDbH6bsqpAnuAB1txt+aLDUUiDGztH70T1WRnQJCg1GSsoE loHvv6eUCL2Njn+gxulQVJI776yF9Apsd9bjxTzqRifjzgK8R0puAhpu9JpQVC8zuenW SPcg== X-Gm-Message-State: AOJu0YxUyFFfWGcHLhvoo8wlHVK1Z0xUduPzybGshWWhGYMphM+hlM8y /snGaLwDF4sJaxYnKQIrTzm0SP9huQQ7HDAICix408Wf2fS/fwik X-Google-Smtp-Source: AGHT+IGFUlPXQhdIDUBuTs+iexfL4O9g4nKrBrBtuEbvMphrKMfRg42EYlL0qdb8DE2eyO1j+MjT3w== X-Received: by 2002:a05:6a00:a8b:b0:6d9:ad3d:7d8 with SMTP id b11-20020a056a000a8b00b006d9ad3d07d8mr601569pfl.19.1705641175800; Thu, 18 Jan 2024 21:12:55 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id fh4-20020a056a00390400b006d9b4a0b6e3sm4159340pfb.80.2024.01.18.21.12.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2024 21:12:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: Date: Thu, 18 Jan 2024 21:12:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3C29CB93-925C-4C65-BCEA-6506F2D9E4BD@gmail.com> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> To: Stefan Monnier X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Stefan Kangas , joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 15, 2024, at 6:32 PM, Stefan Monnier = wrote: >=20 >>> Please don't call it "language". That'd be confusing. LSP is about >>> programming languages, so "language" is natural there. But in = Emacs, >>> a major mode is more general than that. For example, it is not >>> unthinkable to consider mail-mode to be the extra-parent of >>> message-mode (or vice versa) -- but what is the "language" in that >>> case? >> Isn't the language for such modes in this paradigm just the empty = set? >=20 > I'm not too worried about those cases, indeed. > I'm more worried about the taxonomy of languages. > We currently have the taxonomy of major modes, with which we're pretty > familiar, and we've had many years to learn about its downsides, > complexity, as well as how to deal with them, but for languages we're > only familiar with the easy cases, which makes us judge the idea in > a way that may prove naive. I don=E2=80=99t have anything insightful to contribute, but want to = point out that in Emacs, =E2=80=9Clanguage=E2=80=9D doesn=E2=80=99t = always mean programming language. =E2=80=9CLanguage=E2=80=9D can also = mean Chinese, English, etc, and Emacs are quite often used for editing = natural language text. So it warrants some caution when using = =E2=80=9Clanguage=E2=80=9D to mean programming language specifically. >=20 > IME, deciding what is the type of the content of a buffer is usually > trivial but with some notable caveats, such as XPM or Postscript = files, > or "container formats" (like `.deb` or `.odt`, as well as things like > DocBook which can be considered either as their own format or as XML), > or "sublanguages" such as C being a subset of C++, or Javascript being > a subset of Typescript. And I suspect the info we need will not = always > be quite the same. >=20 > So while there might be a good case to be made to add some API = functions > to query the language/type(s) of a given buffer (I'm not sure we'd = need > the language of a given major mode, OTOH), or to find the preferred > mode(s) for a given language/type, I think it's worthwhile to try and > tweak our major mode taxonomy because it is information we must have > and information we know we will always have, so we should strive to = make > it as good as we can. >=20 > It shouldn't make it any harder to add language/type API = functionality. > On the contrary it should make it easier. >=20 > [ As suggested elsewhere in this thread, we could even try and merge > those taxonomies, e.g. using extra parents of the form `LANG-lang`. = ] >=20 > As I said at the very beginning of this long thread, I'm not = completely > sure how well my proposal will play out: the upsides are in plain = sight, > but it may bump into real problems. [ I'm actually surprised by Eli's > optimism about it =F0=9F=99=82 ] > But we won't know until we try it. >=20 >=20 > Stefan >=20 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 07:44:03 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 12:44:03 +0000 Received: from localhost ([127.0.0.1]:57782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQoE6-0003Mf-Ip for submit@debbugs.gnu.org; Fri, 19 Jan 2024 07:44:02 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQoE3-0003M1-Mt for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 07:44:00 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 89A3E444364; Fri, 19 Jan 2024 07:43:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705668229; bh=lkXlxAWHFP7h0EIRJmiTwimorOMKIulT+SzYg2BkieQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LL5Z29DDKXPDh3VSzadUuo3rzr+/FACEDeRQ6bzYeGdhfFB7fbC8avDAK9ydNkv+E TyDHgtXgIJ8DsMdAs9tUhnglhMO7vAoahQCpG1javmrO+EL1rLAXLxdyVBPZIGxKJp B2t4lWmWBlBhLctE5lcPJxn5zwvebNPJ5CY/uePQhTYSHsdrSabdHjfkRMbY4SBmXS LOiueHn0LHOFBcv0bI5vdFpzJOp7mRd+kUMwRyqnM871Gr2vBjXBCXMl1lIxtSpd/3 zHGxa0uKDs9HKrsfIg6/VCIlxuMcpRxyxa4r6P3Ekn/KwKB5L0TDDArxOD8DTrClJd LMxwk9sjJ4O7Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBCAA444362; Fri, 19 Jan 2024 07:43:49 -0500 (EST) Received: from pastel (104-222-114-253.cpe.teksavvy.com [104.222.114.253]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 804871200CC; Fri, 19 Jan 2024 07:43:49 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (Dmitry Gutov's message of "Fri, 19 Jan 2024 03:28:16 +0200") Message-ID: References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Date: Fri, 19 Jan 2024 07:43:48 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.042 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > That might mean that a content-type corresponds to a number of languages, > just like a language corresponds to a number (open set) of major modes. B= ut > I don't see how. Please enlighten. All three are taxonomies that are related to the content of the buffer. They are almost identical in general, but differ in details because taxonomies are not an exact science and those three have each been defined separately, so the arbitrary decisions that are involved in making a taxonomy have not been the same. > The side-effect of this approach is that we basically declare a mode's > language twice: once in the attribute above, and once in the > major-mode-remap-alist which is put into autoloads. But it's probably > minor enough. Again: not necessarily. You're making assumptions about what the source code will look like, but we get to decide what the source code looks like by defining functions/macros. Even if the information is stored in a redundant way, that doesn't mean the surce of that information can't be the same. So if/when such a duplication proves to be a problem, I can't see why it would be difficult to fix it. >> Cue the patch I submitted when I open this bug report =F0=9F=99=82 >> Now `-mode` is again included in `derived-mode-all-parents` for >> those new modes. > > If the language is called -lang instead (of without suffix), then t= he > major mode could also run the language-specific hook, which in your patch= it > cannot do. I don't follow: why would the name of the mode (and hence hook) make it harder/easier/possible to run the hook? > I think I've included some thoughts on this subject in my previous > email. They don't seem to be quoted/commented on here. I didn't have anything to comment on them :-) >>> The major-mode could be fundamental-mode. If the language were to be >>> specifiable through settings external to major modes, we could still do >>> useful things while in fundamental-mode (e.g. do some useful editing wi= th >>> Eglot, provided it supports indentation and completion), or suggest whi= ch >>> major modes to install from ELPA. >> I don't see the interest of using specifically `fundamental-mode` for >> that. In any case, this seems too hypothetical at this stage to have >> a good idea of what we'd need in such circumstances. > The latter feature (suggest which major modes to install) has come up > recently. It's not that difficult to implement (with a whitelist of > packages), I'm with you so far (my `gnu-elpa` package intended to provide a possible solution for that). > and fundamental-mode is most likely *the* major mode which would > be used until the suitable major mode is installed. Here I don't see it. >> Anyway, as I mentioned elsewhere, I think this discussion of "languages" >> is only tangentially related to my proposed patch. There is some >> overlap, but they serve different purposes, and they're not >> mutually exclusive. > I think the "languages" feature seems to cover the same functionality as > your patch, In the longer term, there might be a fair bit of overlap, yes, tho it all depends on how your proposal works out in the end. My patch is a short term solution with no new API. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 07:53:45 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 12:53:46 +0000 Received: from localhost ([127.0.0.1]:57799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQoNV-0006Pi-Jw for submit@debbugs.gnu.org; Fri, 19 Jan 2024 07:53:45 -0500 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:50481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQoNT-0006PR-4s for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 07:53:43 -0500 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50e7ddd999bso861840e87.1 for <68246@debbugs.gnu.org>; Fri, 19 Jan 2024 04:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705668814; x=1706273614; 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=7mmsYPUvvLyF1ui6OE0PRQuS/MEhm/7Mn4BTs6ivhuU=; b=YWssfc5qtujBt7xsBSw59iw7pHer22T2HQsuYwdPDeRfhppYff1wVqdgUyvNQ+OBRD WMKgxQyomjxgeenco3HbKkn6yNXbuPem1ZFohaVebmxiqiicHocvXwBs0xOUzX1qoNwc 87W4nhvF/5iBoHTOlkoL+wLplwNP4WugT3yrX09/STxEO+QgXc9B38c4JQ2OgewEICyl npJC99pWkcEpnow4g9ADnLba1UoS7tVJT77FCf49vhNxJm/TlN/K9Dm6kMxdEDX/xBfU G5WEe5p4Q3G4yfFlUEaAkoPXGQZTSx9VlBVq3kODsQBlPii7oBcmQRCA9PqwSTW7Afd3 y8yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705668814; x=1706273614; 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=7mmsYPUvvLyF1ui6OE0PRQuS/MEhm/7Mn4BTs6ivhuU=; b=OeLDrJ4aRvfqjyABWSK8J0fMCxG4yAdK140tN9OSMTCvd4QL9n7HIT847M5DcjCWns nK8vx7+UYmCxgZuskE6DaYYWFotbXszqzMxusMmGGNCvKHzYe97E0oZQ1Xws5xWJqG/L 7rXz+fLz12yNI++tzsmqnVZ7voA6AofFoFhVNBfGQEgdP0/mIVhNKyFymxi/fEKyFpQ0 X4qS+lydMk0ZnWLZSvXd2fjtFlWFI6JBjhL6Pz0OtagEzRLU1nweUyM6Tf/1EcJuM3Vg /ylCD1xo38AsOSA6b0jF1FQLgHbERvu9tETeujSgzq4HcH89rSbJUTa5/BSLXl7QPU+2 hT4Q== X-Gm-Message-State: AOJu0Yxx3Xru3jlkXmOQPTiBhMB/TiUOlsR6tk1OfGM8cMatdvUkoEBp ylb7pV8PM/IHgtWxEHYxsJnIU4vehG/RO2FnivQRnZHlhDzqL5xk0j0GKqbZMidNOdLz6AEcwzp 7yOTGRGq+c6vc+JoejQRS3JdY2f0= X-Google-Smtp-Source: AGHT+IGwQRQSwQql6NAfNW8ee8lBl0D4lpymg889L5UjyT5oEsgKG0o2r2eWIRJAwAot9v4zqp0uAuBQMXrMiZNliZk= X-Received: by 2002:a05:6512:1324:b0:50e:86bd:64f7 with SMTP id x36-20020a056512132400b0050e86bd64f7mr783184lfu.12.1705668813983; Fri, 19 Jan 2024 04:53:33 -0800 (PST) MIME-Version: 1.0 References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 19 Jan 2024 12:53:22 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 19, 2024 at 12:43=E2=80=AFPM Stefan Monnier wrote: > In the longer term, there might be a fair bit of overlap, yes, tho it > all depends on how your proposal works out in the end. > My patch is a short term solution with no new API. Problem is, as you know, there's nothing more permanent than a short-term solution. Now, if your patch is expressed carefully in terms of some concepts we could save our skins, so to speak: instead of directly: (derived-mode-add-parents 'foo-ts-mode '(foo-mode)) Why don't we (set-super-special-stefan-parent 'foo-ts-mode 'foo) ? Then (provided-mode-derived-p 'foo-ts-mode '(foo-mode)) should always be true because high-minded conceptual reasons impeccably explained somewhere :-) Then, we can later edit the implementation of set-super-special-stefan-parent to accommodate for 'foo' being a language, the "preferred" or "main" language of whatever mode is given as the first argument. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 08:19:48 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 13:19:48 +0000 Received: from localhost ([127.0.0.1]:57826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQomf-0003yo-SM for submit@debbugs.gnu.org; Fri, 19 Jan 2024 08:19:48 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQome-0003yb-EG for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 08:19:44 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0AB98100068; Fri, 19 Jan 2024 08:19:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705670374; bh=aadhqK/f5imzYsacE7J09DONsxFl8PF1YTBEUKJtpys=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WZPC/AXwSpXSfTvWD8zBwPKVN5s6FvMp/3rwYiWVjuyMBBCZIKIwyW9o+QfBDcZz8 auJiCMXwAhKEmSCZVdtbK33S0+dg0sr9IshOBmJLutTMojvNatYU8Ykz9yBUF8Qs8R HXbTV1GcwrsmEnfUCf6jorWPA3UssF9YU8k6WO3S+AhgGRza37ftPG1d9TftV2TRal O4eReg75CsmteXoMfShD21AZefqbnkqCVy7hY0HmBYN1XEN5j9t5lj4/4XR5YH+mci 1ENqZYL2ZaiOt8tEUmu08d1XU+x7rZBQtF0Xwh1p38OGNn+dmwk+M5n7f/+cuXTpfh a9iN4sghrQVCA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9E40810004C; Fri, 19 Jan 2024 08:19:34 -0500 (EST) Received: from pastel (104-222-114-253.cpe.teksavvy.com [104.222.114.253]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65D441206F0; Fri, 19 Jan 2024 08:19:34 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 19 Jan 2024 12:53:22 +0000") Message-ID: References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Date: Fri, 19 Jan 2024 08:19:33 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.288 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> In the longer term, there might be a fair bit of overlap, yes, tho it >> all depends on how your proposal works out in the end. >> My patch is a short term solution with no new API. > Problem is, as you know, there's nothing more permanent than > a short-term solution. It's not meant to be temporary, tho, so it's not a problem. We may need to undo it if it encounters problems, of course. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 09:02:02 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 14:02:02 +0000 Received: from localhost ([127.0.0.1]:57920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQpRa-0004e5-3T for submit@debbugs.gnu.org; Fri, 19 Jan 2024 09:02:02 -0500 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:58738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQpRY-0004Z1-4R for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 09:02:00 -0500 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd46e7ae8fso10121201fa.1 for <68246@debbugs.gnu.org>; Fri, 19 Jan 2024 06:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705672912; x=1706277712; 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=UT3GcOsFXRwLKulY8kD8VbALcT7lFXN0fxheZvx/P+A=; b=Ym/Q/YCrvtHIx1812YHb5niqU+WdTSDnFGAMEjhZwoS0GdgHxeplA6omoTOArQlIjd 1LTMfMfBZrJTxRQO6wbmYklX8evOeN3PSY3npYhktieXOFoGhFWm9ymMpTphGLv8ZzVq idPefVnMt4bV48oFBnutk9w3Wu28mCQmrieaWnramgrwD7YOPWwKHhSJ+h4teo2xKoUl +bntjlMw0luJHMbVHShAbsgfiXP+J70Q44kv+eeHMNZaBzsCRK+IbtgedhHY4SL/ArjR KWBblQVdX0bRPP39K3qw81OiMSiJOBxzoyRRy5JzP9IWi+5UAGYOjoX6aoS5KrUyaY51 8cQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705672912; x=1706277712; 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=UT3GcOsFXRwLKulY8kD8VbALcT7lFXN0fxheZvx/P+A=; b=XtGMfIgR+pMSwK7wsYWQLWtFZgm9PEhSpU1XNllLdhJyQeLbPcBn2mozDDyhGGTu1b BH/3tx5KQkZ5FoAoChmX73F7TiDOclW64u3NvFl9zdoEp3G39py2YadjT4uvqTujo7k2 z79QbqoGEqWmSdlKGq1juTuBoMnMimwQmytovgFQdOu7+IgiijPWr4EUNfroql/gd0DU eWquSrMOGooCoUhU8SZr9CtKkziAE7TTyq/TQ+m9dQMW+5UztXv3qdGbJhNzp5vCycAy AyURl+uxVrwoKG3eGZu01Fdi1gWkQX3PJlJ7qwgenqGyqkvIwDytHU0ZaY+EIjC0Txvd L+YQ== X-Gm-Message-State: AOJu0YwagdGleHjmkWrBo2wqlBwD0RY1/GOv3Ivw1mbgj7jBvlePephY ll+6NHlqYcyc6doQlkHiQdUmTvdog28lCi3iY1Nr3u9Zfbkc/N4rR7MmXzY267dTr3vQPwxM3UY DVbFf+QUULB90wGG8tzJpXzDTGZw= X-Google-Smtp-Source: AGHT+IFi5Xbtv5RngqOV4M+h+7TSNBdHQkeiHL3VOWwmZ9BHmT8jjsFs9ZIoW/gjrIUfHw7yA6hAU7BiZcO1KxdDoxU= X-Received: by 2002:a2e:a593:0:b0:2cc:faea:c744 with SMTP id m19-20020a2ea593000000b002ccfaeac744mr970631ljp.42.1705672911372; Fri, 19 Jan 2024 06:01:51 -0800 (PST) MIME-Version: 1.0 References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 19 Jan 2024 14:01:39 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 19, 2024 at 1:19=E2=80=AFPM Stefan Monnier wrote: > > >> In the longer term, there might be a fair bit of overlap, yes, tho it > >> all depends on how your proposal works out in the end. > >> My patch is a short term solution with no new API. > > Problem is, as you know, there's nothing more permanent than > > a short-term solution. > > It's not meant to be temporary, tho, so it's not a problem. All the problems it's solving already have solutions, just as short-term and effective as the patch would do. Problem is that patch is, or seems to be, incompatible with all the other things we're discussing. I.e. can you clearly paint a way forward from it that solves the "what is this language in this buffer", "what is the language for this major-mode" and the "what mode should I use for that language" problems? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 13:05:24 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 18:05:24 +0000 Received: from localhost ([127.0.0.1]:60101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQtF2-0004Ih-EU for submit@debbugs.gnu.org; Fri, 19 Jan 2024 13:05:24 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQtF0-0004IO-NV for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 13:05:19 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4AEE91000DA; Fri, 19 Jan 2024 13:05:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705687509; bh=XSyL2M1X1+nnQ91T6LrdyAIt03W79cWZlY/0UwiZ0rE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QE7f7ZT6I+UuFmMkJj47uRZOxH6xNzIxp0HsvY6b4Cx21aH3i64cW9CqIEuuAcSK6 h/UeLeKp5haXEht9rr3jgYQcdnum0i0sSvHF2l+ogCq/uoaJXoU9reiM+Dvi+6xl24 6NWsxydSKNFkzEfZrK3Yh1merc4ov/yJ1AYsUIUNzagTYkbXdb7lZRQEPvM4BgYCSc W3Pbngj+L5uqPEUf04++CZUho2wVdxVXP8yFygkClerxccfCQII8vLktiTX96/YCnH FXhCVzOsYNSLEe2Kn/ufDPoPDoUaqBZiWjlsKHTI6XydhxA0WqLWYbmiF89CqHj5bm JmyYb736iJWhA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 42D3410004C; Fri, 19 Jan 2024 13:05:09 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 11520120A44; Fri, 19 Jan 2024 13:05:09 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 19 Jan 2024 14:01:39 +0000") Message-ID: References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Date: Fri, 19 Jan 2024 13:05:08 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.325 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Problem is that patch is, or seems to be, incompatible with > all the other things we're discussing. Do you have some example of incompatibility it would introduce with the "other things we're discussing"? > I.e. can you clearly paint a way forward from it that solves the "what > is this language in this buffer", "what is the language for this > major-mode" and the "what mode should I use for that > language" problems? As already explained ad-nauseam, my patch has no intention to solve those problems, but I can't see any way in which it gets in the way of solving them, if you care to solve them. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 19 17:47:31 2024 Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 22:47:31 +0000 Received: from localhost ([127.0.0.1]:60372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQxe6-0003cg-J2 for submit@debbugs.gnu.org; Fri, 19 Jan 2024 17:47:30 -0500 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:51616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQxe4-0003cS-32 for 68246@debbugs.gnu.org; Fri, 19 Jan 2024 17:47:28 -0500 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50edf4f478eso1718180e87.3 for <68246@debbugs.gnu.org>; Fri, 19 Jan 2024 14:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705704439; x=1706309239; 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=gI0/4uxBSHGLMDimnM+7yfIddoihvNHvGH7ybCtiKbM=; b=CU8uXBercrQ5v9c+YvHVoeCcfXV0Vs0PTp7fdCdJvtUqQThoZd1bHOpApmuwFld99T sPou8ypL8auIs5GnDRrRqXjoo95bMabtHZ8S7pXOj3fY5O3PlZ6qvngQDKzK3JMDIoBD 8I1ySifUaH23uwT8gVHP+3WpdRAlv5bhcUCX6Xt4DxSnf7yT7uLZZBiHGxCrVVx12Dk8 eNsC3WjN13pRiQN13+BzpAkbT8qivm2yhuJ64Z4eBTLUK5AfJt954yhKIxTFnlsKvpxo Pu/neFfy9lCtKvmfrd0m85iBqKUnfdcpQCEp23i49f725ETHAnWA5KkJZ9J9vVJez3B6 NGnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705704439; x=1706309239; 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=gI0/4uxBSHGLMDimnM+7yfIddoihvNHvGH7ybCtiKbM=; b=hnhEYkXA8tVtK971fOCgLAdAvKU3LfW7Ijz4F/66/tMk3dNt1D7EygBFdEDbhvcCIH NMH0xPUu6+4qsDodAz2zD6X2wN9H7i7Q37WjzbofaY+8VfMCep6yZWLIkVWah5BlGCsz gNcLSsxjdrgxwoL2wKP7oRzyHavPlJefS259LTw68+S0Dozi3b5LjEtkfCnCXRLJ2cWX wGiukWZOyFIJw7qSM0j33sAalGhFUhQz7/+s291dBjfmhqLxtvOLAwA50uuOUeDiobOP VliYkZaAp040DWOuimgk12rYn+3MKDKVMfe/cX0wwKiaCZlSLBcolAW63DUhBhtz0G+l b04g== X-Gm-Message-State: AOJu0YzxbGGnoJJRRmeQeCX6UImhoL3BRZsYUEP4Ai4DTgg8DXF21/Mi 3CWPJUBPjp+JsobOc5knj7UPvDgjtd4hYpVHhN8OzV33iMcgaMWu1MWacjEXQsBMuvtzNMViVy3 DlwVUC3QGAwyDJ6t2vlZUHha2/Ts= X-Google-Smtp-Source: AGHT+IGMLdh+RUf62MtiNnupk0o+7DtxnsWydgcliHrBfdmCGfsQwe94K1CfhIdSiW2mhwz6aKUHNRwVxoc9ONYYUoQ= X-Received: by 2002:a05:6512:108b:b0:50e:76ca:52c6 with SMTP id j11-20020a056512108b00b0050e76ca52c6mr223001lfg.52.1705704439155; Fri, 19 Jan 2024 14:47:19 -0800 (PST) MIME-Version: 1.0 References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 19 Jan 2024 22:47:07 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: Dmitry Gutov , Eli Zaretskii , casouri@gmail.com, Stefan Kangas , 68246@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jan 19, 2024 at 6:05=E2=80=AFPM Stefan Monnier wrote: > > I.e. can you clearly paint a way forward from it that solves the "what > > is this language in this buffer", "what is the language for this > > major-mode" and the "what mode should I use for that > > language" problems? > > As already explained ad-nauseam, my patch has no intention to solve > those problems, but I can't see any way in which it gets in the way of > solving them, if you care to solve them. The patch is intended to solve problems in Eglot, Yasnippet, ffap and so on. This problem always includes with "what is this language in this buffer", i.e. number 1 in the preceding list. That's what the problem is, no less. The fact that these packages have always resorted to using `derived-mode-p` to solve that problem is an unfortunate consequence of the longstanding conflation between modes and languages that you yourself identified. But it's not the right solution, never was. Your patch contributes to the perpetuation of this "wrong" solution, and I think we should face that frontally. After it lands, derived-mode-p will cease to mean "A derived from B via defined-derived-mode, so you can trust hook for B runs in hook for A and a lot of other things". It will mean something else. Once that lands, it can never really safely be rolled back. So my position is: * if it lands, we should document very well what that new meaning of "-mode" is. Also make some "provided-mode-walk-parents" so that at least problem 2 can be solved, by string-matching the symbol name of what will now be an even more enshrined convention. As to problem 3, maybe, it can be written off to "major-mode-remap-alist" (which I doubt will ever see much adoption) * if it doesn't land, we should look at some solution that solves 1 2 and 3 cleanly. I think Dmitry's patch is a decent start. * in the meantime, we should continue using base modes as we already are. In fact, the -base-mode convention is a much better convention to enshrine, it doesn't require any special caveats regarding hooks and dir-locals and changes to the *Help* of a major mode function description. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 00:43:54 2024 Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 05:43:54 +0000 Received: from localhost ([127.0.0.1]:60688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR493-0002pf-Sp for submit@debbugs.gnu.org; Sat, 20 Jan 2024 00:43:54 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR492-0002pP-AD for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 00:43:52 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6CEE25C00E1; Sat, 20 Jan 2024 00:43:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 20 Jan 2024 00:43:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705729424; x=1705815824; bh=NAE5GPWc/sAqc85WUI+qrfo8lDysh7QKOC4q3xUt0Tw=; b= dAngFSCBOwtE81Eogy6S9y/sH9jScSebxR/70M+DqsVRA4V/bBkBhYy2hFqyWDF5 dcubmUXPq0wHmoBStDIlPKA3/0GfocsS4fStpTql9q4tYDA9cVMw7Ok+o24w3soQ sKpMjZodmk1wPEsSNe0R1RewoRXw0esDqWJfKsUOfj4bIw9NOQd5TfAuodoZa5Rv o1Z/Tujbpzt8odYCPZUczvC1QfAvU9BO8S4AKcRCgbXt8siT3IUxjBDMONdtYWjY 8woX1cRGCEfJTjnqD1kymlZNLzcC1dItyJ7ZuzA9TEQ37mqLk77/L2c22M1BpZZT +gLH3Ba+GRjaNzRzJ561UQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705729424; x= 1705815824; bh=NAE5GPWc/sAqc85WUI+qrfo8lDysh7QKOC4q3xUt0Tw=; b=h 9YrbUuYnpDsVwQfvsqyBXC65iau/ZZ7BHEp5rDH9Q+wGhB/QSyCqS4gA5DvsmaYi 1OvWP+ECMubIZ4+V8KF7I4g0HmX9lRazzTwbhb57+cjLszkjp6virpyLmrKfq1BD yF4CmHofoJGc3hoNrljJJ705kNIX9pYGDRZIVPjvpgmCP8pvPzGEr+ph/Zqw8DQX DQiycYMgeILZz7E3e0t3J+q0KdTsPrQYhSrulzUQaBfgRJ9Va0ZM0KyklOI66zbA NKSw5pJzcq5+zwrqOqNfZ8bNsRpoAyL7GLEVaJ6Dj97cq/TjKDBdWwdhye+xnu49 4vWkYQgomCIGhHR3PSdSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 20 Jan 2024 00:43:41 -0500 (EST) Message-ID: <72dfe63b-2af1-43a4-8629-3de47bf5c938@gutov.dev> Date: Sat, 20 Jan 2024 07:43:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Stefan Monnier References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 19/01/2024 14:43, Stefan Monnier wrote: >> That might mean that a content-type corresponds to a number of languages, >> just like a language corresponds to a number (open set) of major modes. But >> I don't see how. Please enlighten. > > All three are taxonomies that are related to the content of the buffer. > They are almost identical in general, but differ in details because > taxonomies are not an exact science and those three have each been > defined separately, so the arbitrary decisions that are involved in > making a taxonomy have not been the same. All right. But we'll probably only add one, if any. Adding two more (in addition to major modes) seems like too much. >> The side-effect of this approach is that we basically declare a mode's >> language twice: once in the attribute above, and once in the >> major-mode-remap-alist which is put into autoloads. But it's probably >> minor enough. > > Again: not necessarily. You're making assumptions about what the source > code will look like, but we get to decide what the source code looks > like by defining functions/macros. Even if the information is stored in > a redundant way, that doesn't mean the surce of that information can't > be the same. > > So if/when such a duplication proves to be a problem, I can't see why it > would be difficult to fix it. Okay. >>> Cue the patch I submitted when I open this bug report 🙂 >>> Now `-mode` is again included in `derived-mode-all-parents` for >>> those new modes. >> >> If the language is called -lang instead (of without suffix), then the >> major mode could also run the language-specific hook, which in your patch it >> cannot do. > > I don't follow: why would the name of the mode (and hence hook) make it > harder/easier/possible to run the hook? So that it can be set up that for every such major mode the language hook does run, and the user could depend on that fact without looking up the mode's definition or its docstring. You said that the choice not to do that (leaving that up to individual modes, IIUC) is because the new parents are existing modes, and so (I imagine) those hooks can existing have configurations that might not work with the new "child". A new name would change that. IIUC your original design decision for `derived-mode-add-parents' is for the MODE not to run any of EXTRA-PARENTS hook, but I think the invariant that when a mode is "derived", it runs the hooks, was pretty sensible. >>>> The major-mode could be fundamental-mode. If the language were to be >>>> specifiable through settings external to major modes, we could still do >>>> useful things while in fundamental-mode (e.g. do some useful editing with >>>> Eglot, provided it supports indentation and completion), or suggest which >>>> major modes to install from ELPA. >>> I don't see the interest of using specifically `fundamental-mode` for >>> that. In any case, this seems too hypothetical at this stage to have >>> a good idea of what we'd need in such circumstances. >> The latter feature (suggest which major modes to install) has come up >> recently. It's not that difficult to implement (with a whitelist of >> packages), > > I'm with you so far (my `gnu-elpa` package intended to provide > a possible solution for that). Hmm, that implementation is more clever than I was thinking of. Without getting into the details of its UI, your point is very well made that the major mode symbol can serve as the point of indirection as well. To sum up, I've been looking for some sort of middle ground between your patch and my more radical proposal. I might look like this: - auto-mode-alist and major-mode-remap-alist stay the same (no "language" entries), although it would make sense to use major-mode-remap-alist more prominently rather than copy the regexps, irrespective of this change. - The added extra parents have new names, not of existing modes, but something with "-lang" or just the name of the language, but without "-mode". - The child mode runs the hooks of the extra parents as well. I think Joao has been thinking in the same direction, except his choice was to extend the -base-mode scheme to all languages. Which mostly satisfies the same constraints, if we agree that the "-base-mode" naming should only extend to modes such as these (with the language in the name), so that (get-mode-language mode) could search for that name. *OR*, alternatively, we don't add new parents. But add the :language keyword (or :content-type, or something similar) to define-derived-mode which would basically set a property. But when such property is set, (get-mode-language mode) would evaluate that property's value. And the mode would run the hook automatically when a language is set. I suppose the second approach is technically compatible with your patch as well, and since it by itself doesn't help with the generalization of major modes in dir-locals.el, it might make sense to do both. But I'd be sorry to lose the invariant mentioned above, and specifying both the extra parent *and* the language, for ts modes, would feel like unfortunate duplication. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 00:47:42 2024 Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 05:47:42 +0000 Received: from localhost ([127.0.0.1]:60693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR4Cj-0005cc-QS for submit@debbugs.gnu.org; Sat, 20 Jan 2024 00:47:42 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:49143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR4Ch-0005bo-0d for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 00:47:39 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2EA575C0129; Sat, 20 Jan 2024 00:47:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 20 Jan 2024 00:47:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705729651; x=1705816051; bh=GQipcpCjIpW0rLOFXIHQLglLvY13Q4FyiRU7EYVKYCU=; b= ozB8TDjg/yCB8oz9dEZoWRd6DETlOzgzlnin+qve8GahOrZCfXFbCl2VUjvaz+33 X/KqErN8ibOzslsib8pwhSQA4zUf1evX9BQuGlrVteHKxP9nTFjThXieUyUvQZoH Hdz0ttwjlevdpMGKbpU+4L0+AL2Q/UkwnaxxhmtsH1kLNuM7rMyqRm9oZ34LZh00 I/wMHHlo5pfOiVS/Y3eg6zZLSqfGcwzD1nXzC49gK24bAw1ziJ8RbfarKKZ4mhSI sbGg+jUBc8R7tSDk22sKgZqKtOVpCLJ9aZOpYNcTU3ZRYF8sspQDuseGm7hu6WZr uuvi60/dAcTDE+ea/f7veg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705729651; x= 1705816051; bh=GQipcpCjIpW0rLOFXIHQLglLvY13Q4FyiRU7EYVKYCU=; b=w iO7FdShIy9inmg+DosN4T+Nw3ir2MIkFmJ4ovtXecdqcZMjPYx/4a7xCTplCK+NB cRsyGOrkNYyaKNLmh5y3FhQk0fMkBa7/A1mIy4NDSMmM7bRK6sUwff23xnWxJAMg JRtWGoyGLDsECrns5iOHUEAGYWd7rU7JZZjWF6Bth4MzjvSUjbuhlCIzXhJuNtuB edi3xZlxMZdEwPyxGFtno757Flv3UbPLPXIrg4YkBefZiIQHp6ZcQGzDWwmIU0YV Zd+jR3R1nrHtGxbP5pieOfGRVJuDXBDzaoxNT//59L7509HZhuPGN7eny0jTzjOj uonk8v0+2B4k6PNetdjLw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 20 Jan 2024 00:47:28 -0500 (EST) Message-ID: <78523720-6dc8-459a-9a9d-2af38efdb7da@gutov.dev> Date: Sat, 20 Jan 2024 07:47:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Yuan Fu , Stefan Monnier References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <3C29CB93-925C-4C65-BCEA-6506F2D9E4BD@gmail.com> From: Dmitry Gutov In-Reply-To: <3C29CB93-925C-4C65-BCEA-6506F2D9E4BD@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Stefan Kangas , joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 19/01/2024 07:12, Yuan Fu wrote: > >> On Jan 15, 2024, at 6:32 PM, Stefan Monnier wrote: >> >>>> Please don't call it "language". That'd be confusing. LSP is about >>>> programming languages, so "language" is natural there. But in Emacs, >>>> a major mode is more general than that. For example, it is not >>>> unthinkable to consider mail-mode to be the extra-parent of >>>> message-mode (or vice versa) -- but what is the "language" in that >>>> case? >>> Isn't the language for such modes in this paradigm just the empty set? >> I'm not too worried about those cases, indeed. >> I'm more worried about the taxonomy of languages. >> We currently have the taxonomy of major modes, with which we're pretty >> familiar, and we've had many years to learn about its downsides, >> complexity, as well as how to deal with them, but for languages we're >> only familiar with the easy cases, which makes us judge the idea in >> a way that may prove naive. > I don’t have anything insightful to contribute, but want to point out that in Emacs, “language” doesn’t always mean programming language. “Language” can also mean Chinese, English, etc, and Emacs are quite often used for editing natural language text. So it warrants some caution when using “language” to mean programming language specifically. That's a good point. But hopefully when the suffix -lang or -language is used in the symbol name, the preceding word(s) will make it unambiguous. But the mentions of "language" in the documentation would have to be more careful indeed (perhaps we'd call them "content type" after all, and :ruby-lang would be one of the content types). From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 02:04:15 2024 Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 07:04:15 +0000 Received: from localhost ([127.0.0.1]:60744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR5Oo-0004LD-QL for submit@debbugs.gnu.org; Sat, 20 Jan 2024 02:04:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR5Om-0004L0-Jy for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 02:04:13 -0500 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 1rR5Od-0000IR-UH; Sat, 20 Jan 2024 02:04:03 -0500 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=tKfIaRZJx5Kot/L1m8LPvkVcQGWdJmywHNZhjNtHZ9U=; b=LybEDq04cgUJIgY5sv2o aBWXTGZFcf9n7lRygxy8sNKRQvwP8Y76PFnjPktFnEDRaheIXzJl7FZgPwiOZijdugh0xGxbmDwYw drxpaFPZyAYfdYKcrzFybdPZfd4edb6P8xalVKJsUjYZb5dCcBiaNkQB1g6WZBZI1c9X/u6WWY5Gr Ok8mnhF0ez+Zy11PnkU59Svp+eSAm48H6OXTYZQyXUcwGhsBxoTiS/lcwsQm8h2PGV/n4HKHViB7W ffUM4K1i0vMEaeZ8CiNBauwH23fUcgFw3pwAfQo4Jej1R69cYcke6WOhD2NaWAlwq6WHtk2RepqJD dPxrVnD9f9qS2w==; Date: Sat, 20 Jan 2024 09:03:43 +0200 Message-Id: <83bk9gv640.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 19 Jan 2024 22:47:07 +0000) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, dmitry@gutov.dev, casouri@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: João Távora > Date: Fri, 19 Jan 2024 22:47:07 +0000 > Cc: Dmitry Gutov , Eli Zaretskii , > Stefan Kangas , 68246@debbugs.gnu.org, casouri@gmail.com > > On Fri, Jan 19, 2024 at 6:05 PM Stefan Monnier wrote: > > > > I.e. can you clearly paint a way forward from it that solves the "what > > > is this language in this buffer", "what is the language for this > > > major-mode" and the "what mode should I use for that > > > language" problems? > > > > As already explained ad-nauseam, my patch has no intention to solve > > those problems, but I can't see any way in which it gets in the way of > > solving them, if you care to solve them. > > The patch is intended to solve problems in Eglot, Yasnippet, > ffap and so on. This problem always includes with "what is this > language in this buffer", i.e. number 1 in the preceding list. > That's what the problem is, no less. The fact that these packages > have always resorted to using `derived-mode-p` to solve that > problem is an unfortunate consequence of the longstanding > conflation between modes and languages that you yourself > identified. > > But it's not the right solution, never was. Your patch contributes > to the perpetuation of this "wrong" solution, and I think > we should face that frontally. Your opinions on this are well-taken and have been noted many messages ago. You made them abundantly clear. There's no need to re-iterate them time and again. > After it lands, derived-mode-p will cease to mean "A derived > from B via defined-derived-mode, so you can trust hook for B > runs in hook for A and a lot of other things". It will mean > something else. Indeed, and it was not meant to mean what you suggest it should mean. > * if it lands, we should document very well what that new meaning > of "-mode" is. Also make some "provided-mode-walk-parents" > so that at least problem 2 can be solved, by string-matching > the symbol name of what will now be an even more enshrined > convention. As to problem 3, maybe, it can be written off to > "major-mode-remap-alist" (which I doubt will ever see much > adoption) Feel free to suggest improvements and clarifications to the documentation in these matters. > * if it doesn't land, we should look at some solution that solves > 1 2 and 3 cleanly. I think Dmitry's patch is a decent start. Since it will land, there's no need yet to look for alternatives. We will consider alternatives or other ways to fix this when we have data (as opposed to just theoretical discussions) to support the need for such changes. (This, too, has been mentioned several times already.) > * in the meantime, we should continue using base modes as we > already are. In fact, the -base-mode convention is a > much better convention to enshrine, it doesn't require any > special caveats regarding hooks and dir-locals and changes > to the *Help* of a major mode function description. We already use base modes where it makes sense. It sounds like your opinion is that we should use it much more radically, with which I disagree and will object to introduction of base modes that server no useful purpose by themselves. I believe I've made that clear as well. I hope this will allow us finally to put this longish discussion to rest, at least until we have actual data to discuss what and how needs to be changed. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 02:46:32 2024 Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 07:46:32 +0000 Received: from localhost ([127.0.0.1]:60777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR63j-0004PN-Ik for submit@debbugs.gnu.org; Sat, 20 Jan 2024 02:46:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR63g-0004ID-FQ for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 02:46:29 -0500 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 1rR63Y-0002le-Ao; Sat, 20 Jan 2024 02:46:20 -0500 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=BgRReep68XZeb2nIHRLzMJi3q4VpUQzexexr0VruyNk=; b=cS2H8efOoiC+T7GlPlCG AEd4B0+NUsD9HJmhddtES6q3SN2l60HC3LcQGyHujLgZbkL7mPqQUE6HzolJLLKWPHViuCjuCXCWO DI9WNwUfrVkDEPH709o2DpXON3RxSUzuQOaFo9Ovfed2dgylfENs8D2hG59aiEoRsNlRQdrPHNM92 YpNiGWABo3/IQZ28ScOjMiDVPs0Y6MWu1GLzOuPVhcq/9A6HD+sc//TQiiZFlvmuKxpjNK9bJvstm t5AVGp/BuhYdBjJshhPsPE/bVOh/s9S9xeIBOizqgWMR4/2SLXqHgxTbC5Og/+HyBXZfZcoSx2Q1D UcrpL9/ld//awg==; Date: Sat, 20 Jan 2024 09:46:00 +0200 Message-Id: <83zfx0tpl3.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <78523720-6dc8-459a-9a9d-2af38efdb7da@gutov.dev> (message from Dmitry Gutov on Sat, 20 Jan 2024 07:47:27 +0200) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <3C29CB93-925C-4C65-BCEA-6506F2D9E4BD@gmail.com> <78523720-6dc8-459a-9a9d-2af38efdb7da@gutov.dev> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: joaotavora@gmail.com, 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sat, 20 Jan 2024 07:47:27 +0200 > Cc: 68246@debbugs.gnu.org, Eli Zaretskii , > Stefan Kangas , joaotavora@gmail.com > From: Dmitry Gutov > > On 19/01/2024 07:12, Yuan Fu wrote: > > > > I don’t have anything insightful to contribute, but want to point out that in Emacs, “language” doesn’t always mean programming language. “Language” can also mean Chinese, English, etc, and Emacs are quite often used for editing natural language text. So it warrants some caution when using “language” to mean programming language specifically. > > That's a good point. > > But hopefully when the suffix -lang or -language is used in the symbol > name, the preceding word(s) will make it unambiguous. Unfortunately, it doesn't. Witness the parallel discussion of translating the manual into other languages. Which is one (but not the only) reason why I asked repeatedly in this thread not to use the notion of "language" in this context: it is confusing for more than one reason. I think Stefan suggested "content type" or something to that effect, which is better terminology, IMO. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 05:17:09 2024 Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 10:17:09 +0000 Received: from localhost ([127.0.0.1]:32916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR8PU-0002Xq-ES for submit@debbugs.gnu.org; Sat, 20 Jan 2024 05:17:08 -0500 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:60755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR8PR-0002Si-Rm for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 05:17:06 -0500 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cddb2c2b54so15986581fa.1 for <68246@debbugs.gnu.org>; Sat, 20 Jan 2024 02:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705745817; x=1706350617; 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=YZWyZAaWn0y6kxphM6J1NakFrgByWeF5NjheP1+kg2k=; b=OGlHEO6FdVQIoSIJQ6PckZa5ia7V96QsR78LWaxIwMDDSaxe2xCZhATksjX1LQbPvk uAzqSE0vH+3zZVo5O5GbIeddwKdVeFOS3aEvK9bG44kKvyHgxIeR/vI1HID2ha9pDNq/ NDvSa/NaRNaF7OAZ/FRS9G+4Zc+2ZguZP+BfVpyM3mLKsJAezUv4EttN08kHde7fZw4w 8Cs5mAqZcnRuIPmj3OcEIR2t29p4FkRgEiLfi8PJePXyunoBjYiO5zQfvz0GMp6utY0G fJPzRVLYNL+thAMX9/yZ447mbSm9t59i02S0Jf68FT7Le8l79M0xs6T8wT2dQRMS4Mcs TfgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705745817; x=1706350617; 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=YZWyZAaWn0y6kxphM6J1NakFrgByWeF5NjheP1+kg2k=; b=eVZZda12Eht6y1vSXuyjehAQ3qn5nfpx2L9j7k788uvXSeb6aOAGgxYb97407bN3fm vMY+pKSk691puALK6x2YWNSq1PCeEuOIUScTx5vH09H1fi1Uql8+KSgHRNS5doUFakRf ooFQwHWWCma4raP53dp7mIF03hH1PQSb5MJ7bS6auuLNa5tTaYUnzBttLne1Q2HMVmRd N8oJOPfdGc8xa6Uo2P01KGQgHuiQjwUB193qMC8lg1epaW3XDHVaugtzzzTN69Uvypj4 zJmVpt61710cyM2mKTdW4ein7qB4WzbLwpPNsJmadr+9sgA9tRU0R4B+zclP+UPqFUgv an2A== X-Gm-Message-State: AOJu0YwrVI5PT6SE+A7CwFaRR+0focL/gdJLHd7IfIxZTX0XS9v2sZNw 9qcZxxTL9mZOuR4W/QcsrRpFuqJVYrSGMYb0d+7Y2GPMC78ODE9sgPVz0jRgsMPUu+egw8aiWac eZq0DcRBM0PODZ7fLGAU7PnES1hY= X-Google-Smtp-Source: AGHT+IHP9sJ3ZNLhkOIsZbcgLmIC/6nKHWuerOcXykgnKGmTSgpw19ST2jfwogu76S/QnPTLA4XKrQNGsxvFMaXn77Y= X-Received: by 2002:ac2:4890:0:b0:50e:30b3:b8ff with SMTP id x16-20020ac24890000000b0050e30b3b8ffmr480188lfc.16.1705745816696; Sat, 20 Jan 2024 02:16:56 -0800 (PST) MIME-Version: 1.0 References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> <83bk9gv640.fsf@gnu.org> In-Reply-To: <83bk9gv640.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 20 Jan 2024 10:16:45 +0000 Message-ID: Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Dmitry Gutov , Yuan Fu , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jan 20, 2024, 07:04 Eli Zaretskii wrote: > > After it lands, derived-mode-p will cease to mean "A derived > > from B via defined-derived-mode, so you can trust hook for B > > runs in hook for A and a lot of other things". It will mean > > something else. > > Indeed, and it was not meant to mean what you suggest it should mean. Then pray tell. What will it mean exactly? This patch has no doc yet (last I saw). > > * if it lands, we should document very well what that new meaning > > of "-mode" is. Also make some "provided-mode-walk-parents" > > so that at least problem 2 can be solved, by string-matching > > the symbol name of what will now be an even more enshrined > > convention. As to problem 3, maybe, it can be written off to > > "major-mode-remap-alist" (which I doubt will ever see much > > adoption) > > Feel free to suggest improvements and clarifications to the > documentation in these matters. I don't understand the vision behind this patch. It has do doc yet. Despite your attempts to wrap this up and shut me up I'm trying to at least converse with the author to expound it. Often it's when trying to explain something in plain English that to see how suitable it is. > > * if it doesn't land, we should look at some solution that solves > > 1 2 and 3 cleanly. I think Dmitry's patch is a decent start. > > Since it will land, there's no need yet to look for alternatives. If you've already decided that, just install it and save us all some time. > We will consider alternatives or other ways to fix this when > we have data I've given you data: at least Eglot and markdown mode have brittle hacks this patch does nothing for. You have chosen to ignore it. Also I've explained how potentially dangerous this patch is to Eglot customizations. > We already use base modes where it makes sense. It sounds like your > opinion is that we should use it much more radically, with which I > disagree and will object to introduction of base modes that server no > useful purpose by themselves. So solving the common language-detection problem, deduplicating hooks and dir-locals is not serving a purpose "by oneself"? Indeed you make up an undefined high bar of "by oneselfness" you get to choose what clears it and doesn't. But it doesn't make your argument an argument. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 19:32:29 2024 Received: (at 68246) by debbugs.gnu.org; 21 Jan 2024 00:32:29 +0000 Received: from localhost ([127.0.0.1]:36175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRLlE-00084x-W3 for submit@debbugs.gnu.org; Sat, 20 Jan 2024 19:32:29 -0500 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:43114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRLlA-00084h-5D for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 19:32:27 -0500 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6dbb003be79so2019486b3a.0 for <68246@debbugs.gnu.org>; Sat, 20 Jan 2024 16:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705797135; x=1706401935; darn=debbugs.gnu.org; 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=qnJk+4FJSME82XTC93bsWF49b7+5dsoGUZ2XV6521q4=; b=YfXZbj6C8lyxGE77WS5Q5SWFHWQcF1kCgspY8oc8atAs5azeTSPBqi3clrkfnJOhNj HISjvOSNLY9Glzv91eHA6xb9tgbqjQRhVMz+eZ2/Ijv5UuyqQh/S1Ys9cICTXwj01FMJ qNR6qL4tbRQsL5GUDqbq1b/kGBbZ3mlEYeboXpvexYUm+O3xngMnFBNl0wS/Apn0mkY+ gmm3YOELfpw17RAdTzK2i3YqRBORGXu56ViAMaczNS+aMPMOwRAkGR/L2WG+r52E8msq K9q5uVJF3Jc7Quhm4pARVdAKPa3xTGnlTk/dOQzRESOibA+PfBI5XKR8n/V2cSpCejVF htoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705797135; x=1706401935; 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=qnJk+4FJSME82XTC93bsWF49b7+5dsoGUZ2XV6521q4=; b=sgWSg/7Ne2Bqs5oud6u3ctB4DcPqMYIyqAu5XnQhawiDWQ59A1GoJE0VsjiHof9mii WK4Pu1fnzZD6Tf3yvyKSLr28JMSOyrLsP+/4LPKkLPMF9+bxIEYo3kwy1/1A6P07LmEO H+VCLLIhuhazOpzYIeVZKm3DhB4OzFaLS9eGR2bzYVTgI5WKtZOPsT1DL4D6C3R9gttf /h49drUpy/ZZFCsDsSceXE8SEGVEDXbjTbfTob1XyuRzhgUFETbo7xkpgvixWzBwTjO4 XW8ySbN0bwPyRdcoaaufJcp1qiM+RBI2A/ntlLypmIx+Nuc71peL1l03JMd9CzAmRoiW ijwQ== X-Gm-Message-State: AOJu0YyDMg2l2NYX1drW04HSUUiIWu7Piyz5qY8VaTVaZDcBD8XE85e+ wq2hk+Zp+///xxd6MQmZNiXa5il0/lZcO4F01lRzseWrHFBGV6gK X-Google-Smtp-Source: AGHT+IFRmopTnJOp3Ny5FcQufim5sJO1zWxHS3uYQlP9MHxGlWeJtEmt3r5vfNwWPBkRb9qjRowNcw== X-Received: by 2002:a05:6a20:d399:b0:19a:797f:eac8 with SMTP id iq25-20020a056a20d39900b0019a797feac8mr221954pzb.46.1705797134979; Sat, 20 Jan 2024 16:32:14 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id m7-20020a62f207000000b006dbbc6ab938sm3453010pfh.199.2024.01.20.16.32.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jan 2024 16:32:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: Date: Sat, 20 Jan 2024 16:32:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02EBD96A-B040-46CF-9ED2-775A6696E1CC@gmail.com> References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> <83bk9gv640.fsf@gnu.org> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii , Stefan Monnier , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 20, 2024, at 2:16 AM, Jo=C3=A3o T=C3=A1vora = wrote: >=20 > On Sat, Jan 20, 2024, 07:04 Eli Zaretskii wrote: >=20 >>> After it lands, derived-mode-p will cease to mean "A derived >>> from B via defined-derived-mode, so you can trust hook for B >>> runs in hook for A and a lot of other things". It will mean >>> something else. >>=20 >> Indeed, and it was not meant to mean what you suggest it should mean. >=20 > Then pray tell. What will it mean exactly? This patch has no doc > yet (last I saw). >=20 >>> * if it lands, we should document very well what that new meaning >>> of "-mode" is. Also make some "provided-mode-walk-parents" >>> so that at least problem 2 can be solved, by string-matching >>> the symbol name of what will now be an even more enshrined >>> convention. As to problem 3, maybe, it can be written off to >>> "major-mode-remap-alist" (which I doubt will ever see much >>> adoption) >>=20 >> Feel free to suggest improvements and clarifications to the >> documentation in these matters. >=20 > I don't understand the vision behind this patch. It has do doc > yet. Despite your attempts to wrap this up and shut me up > I'm trying to at least converse with the author to expound it. > Often it's when trying to explain something in plain English > that to see how suitable it is. >=20 >>> * if it doesn't land, we should look at some solution that solves >>> 1 2 and 3 cleanly. I think Dmitry's patch is a decent start. >>=20 >> Since it will land, there's no need yet to look for alternatives. >=20 > If you've already decided that, just install it and save > us all some time. >=20 >> We will consider alternatives or other ways to fix this when >> we have data >=20 > I've given you data: at least Eglot and markdown mode have brittle > hacks this patch does nothing for. You have chosen to ignore it. > Also I've explained how potentially dangerous this patch is to > Eglot customizations. >=20 >> We already use base modes where it makes sense. It sounds like your >> opinion is that we should use it much more radically, with which I >> disagree and will object to introduction of base modes that server no >> useful purpose by themselves. >=20 > So solving the common language-detection problem, deduplicating > hooks and dir-locals is not serving a purpose "by oneself"? > Indeed you make up an undefined high bar of "by oneselfness" > you get to choose what clears it and doesn't. But it doesn't > make your argument an argument. [I=E2=80=99ve been loosely following the thread so this might have been = brought up and I missed it] IIUC Stefan=E2=80=99s patch is trying to use xxx-mode to represent = =E2=80=9Cmode for xxx in general=E2=80=9D, sort of like the keys in = major-mode-remap-alist. And IIUC Joao and Dmitry are not very = comfortable with it because (mode-A R mode-B) where R is derived-mode-p = implicitly means mode-B runs mode-A=E2=80=99s hooks and major mode body, = and this patch would break that, which would bring a lot of confusion. Instead of using xxx-mode, can we set common-xxx-mode to the parent of = both xxx-mode and xxx-ts-mode? Or maybe abtract-xxx-mode, or just xxx, = the name doesn=E2=80=99t matter. The point is this is just a symbol and = doesn=E2=80=99t have hooks and other implicit things a major mode have. = It=E2=80=99s still a bit confusing, but it should be less confusing. We = can also add a variable common-mode-list or abstract-mode-list so these = symbols don=E2=80=99t seem to come out of nowhere. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 20 19:33:08 2024 Received: (at 68246) by debbugs.gnu.org; 21 Jan 2024 00:33:08 +0000 Received: from localhost ([127.0.0.1]:36180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRLlr-00086L-J7 for submit@debbugs.gnu.org; Sat, 20 Jan 2024 19:33:07 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:60993) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRLlp-00085g-Fy for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 19:33:06 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 03DAF3200A12; Sat, 20 Jan 2024 19:32:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 20 Jan 2024 19:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705797175; x=1705883575; bh=iZjSx5Lqcitzb34hZL+IwGyekovvrltGw9Gfus9vWfY=; b= qAojy3vHd7/Z68WnrNJfnDqJZKY0KyOHDMkCNa1uhXbP69FBTYZHw5dYlF21WdHO NpwDh5A7g7+RYkBZ5OGVya/ZN12i6LbKVNXb9htkpr0UgRsiQ2HFLMcFCjvy7Qph 196jhAx+z3l3X4PkKG9jvJ9zjjXn6Lq1ddLDT29uYOPvxm0GLtCFWVoKuv6hbug6 Zdj0TMTNx2vGybJ6lTCOtdenDxHvwc8A0e1YH/crZHfFdtkL6o+BSmiBgU2IGC8n Ap6mt9v6HG0lUwamwZBhBfgjBTMPooPzAM/TceExwvCGQpMMX9wzkddZu0Uu/Upx EviPF/pJmxPIH2iuqjyGEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705797175; x= 1705883575; bh=iZjSx5Lqcitzb34hZL+IwGyekovvrltGw9Gfus9vWfY=; b=w koeWRoLHFBevoVXjzCfEuooK/45PbkHztFadlRvq5XSzP+QKlrXD4XzTe5yHrQyR z++HKh7iTRv+PkX7F8gSurn6JaZkR/aphwNQpLQ4+qDDk578O32h2njFb298NDIF pn4gZ3cFxLSYMossqcqOMwcpXwA2eLLmPPuiGkOL1Q+SjSVk7GD2OSzUEEfbEGH7 TubcPW6ojHDFJJo4Y7vwibkEvGAd8YNEGt+1p53g0m9l78Kelrv1DmO4kTSNvwaU QFEh2ujOX/mj+zCprGeQu+cAs7PnnsPsb5GOzJV5Vpr1kfwXDhI5t2aAdnJLwj7v ZvWVuD/MZIuA+iJ8SZQoA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekfedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 20 Jan 2024 19:32:53 -0500 (EST) Message-ID: Date: Sun, 21 Jan 2024 02:32:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Content-Language: en-US To: Eli Zaretskii References: <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> <3C29CB93-925C-4C65-BCEA-6506F2D9E4BD@gmail.com> <78523720-6dc8-459a-9a9d-2af38efdb7da@gutov.dev> <83zfx0tpl3.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83zfx0tpl3.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68246 Cc: joaotavora@gmail.com, 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 20/01/2024 09:46, Eli Zaretskii wrote: >> Date: Sat, 20 Jan 2024 07:47:27 +0200 >> Cc: 68246@debbugs.gnu.org, Eli Zaretskii , >> Stefan Kangas , joaotavora@gmail.com >> From: Dmitry Gutov >> >> On 19/01/2024 07:12, Yuan Fu wrote: >>> >>> I don’t have anything insightful to contribute, but want to point out that in Emacs, “language” doesn’t always mean programming language. “Language” can also mean Chinese, English, etc, and Emacs are quite often used for editing natural language text. So it warrants some caution when using “language” to mean programming language specifically. >> >> That's a good point. >> >> But hopefully when the suffix -lang or -language is used in the symbol >> name, the preceding word(s) will make it unambiguous. > > Unfortunately, it doesn't. Witness the parallel discussion of > translating the manual into other languages. > > Which is one (but not the only) reason why I asked repeatedly in this > thread not to use the notion of "language" in this context: it is > confusing for more than one reason. I think Stefan suggested "content > type" or something to that effect, which is better terminology, IMO. People are welcome to rewrite the docs in terms of "content type", I have no problem with that and referred to this alternative multiple times in the emails. But the term "language" is closer to my understanding of the issue, so it's easier for me to use when explaining. And I'm apparently not alone in that: if one looks at VS Code's UI, in the bottom right corner it offers the user the choice of the "language mode" for the current file. Among the choices of language modes, there are programming languages, of course (C, JavaScript, Ruby, ...), but also values like "Plain Text", "Ini", "Properties", "TeX", "Code Snippets", "Git Commit Message" and "Binary". To be clear, my proposal was not inspired by it--today is the first time I've examined that list this closely. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 21 04:54:42 2024 Received: (at 68246) by debbugs.gnu.org; 21 Jan 2024 09:54:42 +0000 Received: from localhost ([127.0.0.1]:36609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRUXK-00041E-5P for submit@debbugs.gnu.org; Sun, 21 Jan 2024 04:54:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rRUXG-000410-Uv for 68246@debbugs.gnu.org; Sun, 21 Jan 2024 04:54:41 -0500 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 1rRUX7-0001AC-3P; Sun, 21 Jan 2024 04:54:29 -0500 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=fE6B2nXOa6q8hsncQr7Dozg6F7L0ZOKiYSNVudWMopU=; b=BLVdS3jsP+j0RRh0hF5q puadNq54xoyC/B72s0V6GWdyuBv1qcxa+8cHTT99zbaIzbSevoJpWT7dUEImjcOW5BXNBHTOgfu/m 1ktDZXtVL91sIx1nEZOjByGzc7Xn7HKTydeJ2eNZDPneLWj4dWDfE9tqVVxI47ogBJ/+tqlpfDwx4 /7tsDLyq9YPxsqxSwyrqdOJELrEDTbQKkxhVXVX1V5IWKo1oM0jhves+IV/XWpVmx1Gh06D+/32/l VBLCDB85xqpeX917P+3bfgq7mfOLpQ08q8pQpMflm3xWp0CoPsZ1JNS68PtK4piSDGVQacV9llqXO M0JFLWKescb9zQ==; Date: Sun, 21 Jan 2024 11:54:10 +0200 Message-Id: <83bk9frozh.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <02EBD96A-B040-46CF-9ED2-775A6696E1CC@gmail.com> (message from Yuan Fu on Sat, 20 Jan 2024 16:32:02 -0800) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> <83bk9gv640.fsf@gnu.org> <02EBD96A-B040-46CF-9ED2-775A6696E1CC@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, dmitry@gutov.dev, stefankangas@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: Yuan Fu > Date: Sat, 20 Jan 2024 16:32:02 -0800 > Cc: Eli Zaretskii , > Stefan Monnier , > Dmitry Gutov , > Stefan Kangas , > 68246@debbugs.gnu.org > > IIUC Stefan’s patch is trying to use xxx-mode to represent “mode for xxx in general”, sort of like the keys in major-mode-remap-alist. And IIUC Joao and Dmitry are not very comfortable with it because (mode-A R mode-B) where R is derived-mode-p implicitly means mode-B runs mode-A’s hooks and major mode body, and this patch would break that, which would bring a lot of confusion. There should be no confusion. derived-mode-add-parents is documented regarding the effects and meaning (and if the current documentation is not clear enough, we can clarify it further). Moreover, I see no reason to assume FOO-mode runs any mode hook except FOO-mode-hook. > Instead of using xxx-mode, can we set common-xxx-mode to the parent of both xxx-mode and xxx-ts-mode? Or maybe abtract-xxx-mode, or just xxx, the name doesn’t matter. The point is this is just a symbol and doesn’t have hooks and other implicit things a major mode have. It’s still a bit confusing, but it should be less confusing. We can also add a variable common-mode-list or abstract-mode-list so these symbols don’t seem to come out of nowhere. I'm firmly against introducing modes that are not real modes. We do use base-modes where it makes sense, but if such a mode makes no sense, introducing it as a means to some end is just going to make things more confusing. Once again: let's have real practical issues on our hands before we look for solutions. Right now, no such issues are known, since the changes barely landed on master. There's no reason for looking for hasty solutions for problems we don't have a good handle on. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 01:21:16 2024 Received: (at 68246) by debbugs.gnu.org; 24 Jan 2024 06:21:16 +0000 Received: from localhost ([127.0.0.1]:44315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSWdP-00018m-Pv for submit@debbugs.gnu.org; Wed, 24 Jan 2024 01:21:16 -0500 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]:50655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSWdM-00018I-LM for 68246@debbugs.gnu.org; Wed, 24 Jan 2024 01:21:14 -0500 Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3bb53e20a43so3671895b6e.1 for <68246@debbugs.gnu.org>; Tue, 23 Jan 2024 22:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706077262; x=1706682062; darn=debbugs.gnu.org; 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=HJVpuxgjE3KnvCqm3hztrFsC9DFpJ3TbBrmWCzL+ojM=; b=dPtALlq1uLoB3HnjXRiFmai8wqo2GSv+uJOo4FKw8v4eav5Wn5j5iy67WNRUdaAXfw h/uuyhFuxhLehii+pn+2+FnbecMx2LJg5Jfmx/0r7cKB8df6PWVu6Prktz97t351DI/g VyUf9M0P21sHJKsI+Vx0dV/KpKme5Lx5gC1lvlknox1GGfimZLU9n06KK3o74TsbahtW lvxWROILKrMQft7etGxHJiLt7WJ39j73wHLKOE9FMqkGkKn1x85JH2CzvS43Tb/Vy3Oq dEtnD3kv144uxcFKTU+KYrqJuAJJPh6Oqo1XgLm4W91frVS7d6Ua9JfHgk9qdrgKPV/+ DW3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706077262; x=1706682062; 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=HJVpuxgjE3KnvCqm3hztrFsC9DFpJ3TbBrmWCzL+ojM=; b=OnPW505fTFYG4Tf7nMSUXVGBbgJDFjuwO74o3zFM0EfOu5ltEiDQSkAziyU0zDZgz+ Iq2F0QpRfINj3Ne7a05+t2PxVweztMnKkultNVKBml4ORn2SsVXRUZneBA39AgfKhojh NSjHYT8XmCuZ91BHKTn2zcNuCm3qVAUzxf3vFcEYhaSay4bwYPfxwFbv2KynMdVcJiHQ Agadhf4kYbJgeVr4k8s9gqmaiuy1KkOVulLAUlcGE2uPxKvobp0KLDYoWGiVcffwAJGc v7OTrh+OaY7+slTxjiiSkr1nVsqKXQfeyDFFUwg1GDDuBYQNTmJRLmK2aX2Cr74h82+3 XRKA== X-Gm-Message-State: AOJu0YwLrcqUUAzL2YzaLS0wKbh/JtFPdbE6NP+pROsmCwmbTvKc2kvA 2pr76Ts+ijCO/d34H5zP3k1EqwmcQOGrp0rEaoemFH1YlhGI7T9N X-Google-Smtp-Source: AGHT+IFIpKybs/yG+WDjwF7YVTbgZO7ox8A+u2g2iMS8HrDNDoQUCJuJ/UyxLsglP3gQ56hZ9c7wIQ== X-Received: by 2002:a05:6808:3c9b:b0:3bd:a9f5:f5d4 with SMTP id gs27-20020a0568083c9b00b003bda9f5f5d4mr1465474oib.70.1706077261746; Tue, 23 Jan 2024 22:21:01 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id jw41-20020a056a0092a900b006dd815b57c3sm2099383pfb.31.2024.01.23.22.21.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2024 22:21:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes From: Yuan Fu In-Reply-To: <83bk9frozh.fsf@gnu.org> Date: Tue, 23 Jan 2024 22:20:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93910A1D-9768-4327-9C3E-C398D932CFA0@gmail.com> References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> <83bk9gv640.fsf@gnu.org> <02EBD96A-B040-46CF-9ED2-775A6696E1CC@gmail.com> <83bk9frozh.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68246 Cc: 68246@debbugs.gnu.org, dmitry@gutov.dev, stefankangas@gmail.com, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) > On Jan 21, 2024, at 1:54 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sat, 20 Jan 2024 16:32:02 -0800 >> Cc: Eli Zaretskii , >> Stefan Monnier , >> Dmitry Gutov , >> Stefan Kangas , >> 68246@debbugs.gnu.org >>=20 >> IIUC Stefan=E2=80=99s patch is trying to use xxx-mode to represent = =E2=80=9Cmode for xxx in general=E2=80=9D, sort of like the keys in = major-mode-remap-alist. And IIUC Joao and Dmitry are not very = comfortable with it because (mode-A R mode-B) where R is derived-mode-p = implicitly means mode-B runs mode-A=E2=80=99s hooks and major mode body, = and this patch would break that, which would bring a lot of confusion. >=20 > There should be no confusion. derived-mode-add-parents is documented > regarding the effects and meaning (and if the current documentation is > not clear enough, we can clarify it further). >=20 > Moreover, I see no reason to assume FOO-mode runs any mode hook except > FOO-mode-hook. >=20 >> Instead of using xxx-mode, can we set common-xxx-mode to the parent = of both xxx-mode and xxx-ts-mode? Or maybe abtract-xxx-mode, or just = xxx, the name doesn=E2=80=99t matter. The point is this is just a symbol = and doesn=E2=80=99t have hooks and other implicit things a major mode = have. It=E2=80=99s still a bit confusing, but it should be less = confusing. We can also add a variable common-mode-list or = abstract-mode-list so these symbols don=E2=80=99t seem to come out of = nowhere. >=20 > I'm firmly against introducing modes that are not real modes. We do > use base-modes where it makes sense, but if such a mode makes no > sense, introducing it as a means to some end is just going to make > things more confusing. >=20 > Once again: let's have real practical issues on our hands before we > look for solutions. Right now, no such issues are known, since the > changes barely landed on master. There's no reason for looking for > hasty solutions for problems we don't have a good handle on. Ok, I can see that. I don=E2=80=99t have anything else to add. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 09 10:40:19 2024 Received: (at 68246-done) by debbugs.gnu.org; 9 Mar 2024 15:40:19 +0000 Received: from localhost ([127.0.0.1]:34647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riyo7-0001lF-Jj for submit@debbugs.gnu.org; Sat, 09 Mar 2024 10:40:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riyo5-0001l1-3I for 68246-done@debbugs.gnu.org; Sat, 09 Mar 2024 10:40:18 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B83DB100170; Sat, 9 Mar 2024 10:39:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1709998772; bh=OPKa5h+2/95pIeNGUEiqFvg+ykTd5XopHUP56vCpsGw=; h=From:To:Subject:In-Reply-To:References:Date:From; b=WvaEdbTPVKnLOSoKo69e/rsCWuocxP3hmDmTU/46iKCfRHkLViRKfvSVy+dZ1070Z jl8YsfiXEQZiI9De47OxKzkmnTGDGlo+d1KJjtbSRKwbSSCWiQc6k5W2CAe1C9yn6w Myqmfp/NM8qlgXcZufTdADTzoaX+GruVgwYqPZ6qNxJHA/bjecbdKjff8kWvDXzESm Ox0KjQS09/cAfuWiw/7P5hjS2kuQqLArW1ndl+pj82V62CUn2fZVLsQ2qvpOi5Mnli 8gs6H7w3WpYreXdMI2g9JQuKDLZn5fJ9lS88qiChPLnFs2wCG26cZIzzJATJB8N6I2 m4YRjwpR+jxbQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 44A1410005D; Sat, 9 Mar 2024 10:39:32 -0500 (EST) Received: from pastel (69-165-153-56.dsl.teksavvy.com [69.165.153.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2A0EC120193; Sat, 9 Mar 2024 10:39:32 -0500 (EST) From: Stefan Monnier To: 68246-done@debbugs.gnu.org Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes In-Reply-To: <86v86ovp6j.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Feb 2024 09:33:24 +0200") Message-ID: References: <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> <83bk9gv640.fsf@gnu.org> <02EBD96A-B040-46CF-9ED2-775A6696E1CC@gmail.com> <83bk9frozh.fsf@gnu.org> <86v86ovp6j.fsf@gnu.org> Date: Sat, 09 Mar 2024 10:39:31 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68246-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Pushed, closing, Stefan From unknown Sun Jul 20 14:10:14 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 07 Apr 2024 11:24:25 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator