From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
emacs-devel@gnu.org
Subject: Re: Make all tree-sitter modes optional
Date: Tue, 14 Feb 2023 21:02:25 +0000 [thread overview]
Message-ID: <Y+v24asr25nc9F4n@ACM> (raw)
In-Reply-To: <83cz6ccagy.fsf@gnu.org>
Hello, Eli.
On Tue, Feb 14, 2023 at 21:29:01 +0200, Eli Zaretskii wrote:
> > Date: Tue, 14 Feb 2023 19:08:42 +0000
> > Cc: Juri Linkov <juri@linkov.net>, casouri@gmail.com,
> > monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no,
> > jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
[ .... ]
> > No, it is not adequate. It is horrible.
> Not a very kind remark, to say the least.
Sorry, I should have written "It is horrible for me." - which is true.
> > How about commands c-make-ts-default-mode and c-make-ts-undefault-mode
> I'm okay with adding the latter, if it turns out easy enough and safe
> enough (of which I'm not sure at all), and if such a command will be
> implemented for all the *-ts-modes which have non-ts siblings, but I
> see no reason for the former, since there are several simple ways to
> cause the same effect, and they are all documented in NEWS.
OK, Try this (so far only on c-ts-mode.):
diff --git a/etc/NEWS b/etc/NEWS
index 2d15e39036a..0a745d7cde9 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3239,10 +3239,13 @@ for which a "built-in" mode would be turned on. For example:
(add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
-If you try these modes and don't like them, you can go back to the
-"built-in" modes by restarting Emacs. But please tell us why you
-didn't like the tree-sitter based modes, so that we could try
-improving them.
+Normally, the loading of one of the new modes amends 'auto-mode-alist'
+such that future visiting of the same type of file will continue to
+use that new mode. If this is not what you want, do M-x
+<mode>-make-ts-undefault-mode. For a more permanent effect, put, for
+example, the following into your initialization file:
+
+ (eval-after-load 'c-ts-mode '(c-make-ts-undefault-mode))
Each major mode based on tree-sitter needs a language grammar library,
usually named "libtree-sitter-LANG.so" ("libtree-sitter-LANG.dll" on
diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 5093c3980b6..d6ea95a2980 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -904,6 +904,20 @@ c-or-c++-ts-mode
(treesit-ready-p 'c))
(add-to-list 'auto-mode-alist '("\\.h\\'" . c-or-c++-ts-mode)))
+(defun c-make-ts-undefault-mode ()
+ "Make the older C and C++ Modes the default major modes for C(++) files."
+ (interactive)
+ (setq auto-mode-alist (delete '("\\.h\\'" . c-or-c++-ts-mode)
+ auto-mode-alist))
+ (setq auto-mode-alist
+ (delete '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\|\\.x[bp]m\\)\\'" . c-ts-mode)
+ auto-mode-alist))
+ (setq auto-mode-alist
+ (delete
+ '("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'"
+ . c++-ts-mode)
+ auto-mode-alist)))
+
(provide 'c-ts-mode)
;;; c-ts-mode.el ends here
[ .... ]
> I think you have a very simplistic idea of what loading a *-ts-mode
> does, but if you can come up with a simple and safe implementation, I
> won't object adding such a command -- it cannot do any harm by just
> being there, and if it turns to be not what users want, we can always
> advise them not to use it.
[ .... ]
> > Either of these would allow the user to try out the new modes freely
> > without being coerced against their will to use the new -ts- modes.
> "Try out" is not what I had in mind for users who'd like to use these
> modes.
Some will want to try them out first, before definitively committing to
them. I am such a user.
[ .... ]
> Then they [proposed amendments] aren't "reasonable" at this time.
> Maybe later, maybe on master.
That will be too late, the damage will have been done. It is the first
experience people have of the new modes which will create their long term
impressions of them. I remember something similar happening in Emacs
21.1, when the new fringes were not made optional. Lots of users
complained loudly and bitterly.
> As I said several times, we have no good idea yet how users will react
> to what we have. Maybe, after we hear from them, we decide to
> implement such switches, who knows.
We are ourselves all users, too. We know how we have reacted, and it is
reasonable to try to prevent bad experiences for users similar to
ourselves.
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2023-02-14 21:02 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <84973.1672843723@hassadar.pretzelnet.org>
[not found] ` <83wn62xi3k.fsf@gnu.org>
[not found] ` <m1cz7u5brr.fsf@yahoo.es>
[not found] ` <83o7rexe2n.fsf@gnu.org>
[not found] ` <83h6x5xym7.fsf@gnu.org>
2023-01-15 14:01 ` Make all tree-sitter modes optional Eli Zaretskii
2023-01-15 23:39 ` Dmitry Gutov
2023-01-16 7:43 ` Theodor Thornhill
2023-01-16 16:30 ` Dmitry Gutov
2023-01-16 12:34 ` Eli Zaretskii
2023-01-16 13:06 ` Dmitry Gutov
2023-01-16 14:20 ` Eli Zaretskii
2023-01-16 14:50 ` Dmitry Gutov
2023-01-16 14:59 ` Eli Zaretskii
2023-01-17 12:59 ` Dmitry Gutov
2023-01-17 13:47 ` Eli Zaretskii
2023-01-17 14:32 ` Dmitry Gutov
2023-01-17 14:52 ` Eli Zaretskii
2023-01-17 15:22 ` Dmitry Gutov
2023-01-17 17:02 ` Eli Zaretskii
2023-01-17 17:10 ` Dmitry Gutov
2023-01-17 17:38 ` Eli Zaretskii
2023-01-17 17:59 ` Dmitry Gutov
2023-01-17 18:04 ` Eli Zaretskii
2023-01-17 18:21 ` Dmitry Gutov
2023-01-17 18:40 ` Eli Zaretskii
2023-01-17 18:49 ` Dmitry Gutov
2023-01-17 19:03 ` Eli Zaretskii
2023-01-17 19:21 ` Dmitry Gutov
2023-01-18 1:11 ` Yuan Fu
2023-01-18 1:23 ` Dmitry Gutov
2023-01-18 3:34 ` Eli Zaretskii
2023-01-18 3:52 ` Dmitry Gutov
2023-01-18 12:06 ` Eli Zaretskii
2023-01-18 14:00 ` Dmitry Gutov
2023-01-18 14:51 ` Eli Zaretskii
2023-01-18 12:36 ` Stefan Monnier
2023-01-17 17:34 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Juri Linkov
2023-01-17 17:40 ` Theodor Thornhill
2023-01-17 18:17 ` treesit-forward-sexp Juri Linkov
2023-01-17 17:50 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Dmitry Gutov
2023-01-17 17:59 ` Eli Zaretskii
2023-01-16 1:12 ` Make all tree-sitter modes optional Po Lu
2023-01-17 17:30 ` Juri Linkov
2023-01-17 17:58 ` Eli Zaretskii
2023-01-17 18:19 ` Juri Linkov
2023-01-17 18:41 ` Eli Zaretskii
2023-02-14 19:08 ` Alan Mackenzie
2023-02-14 19:29 ` Eli Zaretskii
2023-02-14 21:02 ` Alan Mackenzie [this message]
2023-02-15 15:35 ` Eli Zaretskii
2023-02-15 17:57 ` Alan Mackenzie
2023-02-15 18:33 ` Eli Zaretskii
2023-02-15 20:31 ` Alan Mackenzie
2023-02-16 5:41 ` tomas
2023-02-16 7:27 ` Eli Zaretskii
2023-02-16 22:05 ` Yuan Fu
[not found] ` <87v8k2g04m.fsf@dick>
2023-02-15 20:34 ` Eli Zaretskii
[not found] ` <87mt5eegkw.fsf@dick>
2023-02-16 7:53 ` Eli Zaretskii
2023-02-16 8:52 ` Po Lu
2023-02-15 21:40 ` Alan Mackenzie
2023-02-17 13:30 ` Alan Mackenzie
2023-02-17 13:37 ` Po Lu
2023-02-17 13:46 ` Stefan Monnier
2023-02-17 14:16 ` Po Lu
2023-02-17 14:40 ` Eli Zaretskii
2023-02-17 14:56 ` Dmitry Gutov
2023-02-17 15:04 ` Eli Zaretskii
[not found] ` <8735741fic.fsf@dick>
2023-02-17 15:41 ` Alan Mackenzie
2023-02-17 16:04 ` Make all tree-sitter modes optional Stefan Kangas
2023-02-17 17:42 ` Morgan Willcock
2023-02-17 15:15 ` Gregory Heytings
2023-02-17 13:54 ` Alan Mackenzie
[not found] ` <d4c1a7f6-b5bf-f4f3-8d79-1c6b1d07cf70@yandex.ru>
2023-02-17 14:22 ` Po Lu
2023-02-17 14:58 ` Eli Zaretskii
2023-02-17 15:18 ` Alan Mackenzie
2023-02-15 18:34 ` Stefan Monnier
2023-02-15 19:01 ` Dmitry Gutov
2023-02-15 19:26 ` Stefan Monnier
2023-02-15 19:47 ` Eli Zaretskii
2023-02-15 19:53 ` Stefan Monnier
2023-02-15 20:06 ` Eli Zaretskii
2023-02-15 21:04 ` Stefan Monnier
2023-02-16 7:42 ` Eli Zaretskii
2023-02-16 9:49 ` Basil L. Contovounesios
2023-02-16 11:48 ` Eli Zaretskii
2023-02-16 14:41 ` Stefan Monnier
2023-02-16 15:42 ` Eli Zaretskii
2023-02-16 16:45 ` Stefan Monnier
2023-02-16 17:05 ` Eli Zaretskii
2023-02-16 19:14 ` Dmitry Gutov
2023-02-16 20:07 ` Stefan Monnier
2023-02-16 5:45 ` tomas
2023-02-16 8:26 ` Eli Zaretskii
2023-02-16 10:30 ` Alan Mackenzie
2023-02-16 12:38 ` Po Lu
2023-02-16 12:53 ` Dmitry Gutov
2023-02-15 20:24 ` Dmitry Gutov
2023-02-16 7:05 ` Eli Zaretskii
2023-02-16 7:53 ` Theodor Thornhill
2023-02-16 8:34 ` Eli Zaretskii
2023-02-16 8:46 ` Theodor Thornhill
2023-02-16 11:58 ` Dmitry Gutov
2023-02-16 11:56 ` Dmitry Gutov
2023-02-16 14:48 ` Theodor Thornhill via Emacs development discussions.
2023-02-16 14:56 ` Dmitry Gutov
2023-02-16 15:15 ` Theodor Thornhill
2023-02-15 23:48 ` Lynn Winebarger
2023-02-16 2:56 ` Stefan Monnier
2023-02-15 19:07 ` Eli Zaretskii
2023-02-15 19:27 ` Stefan Monnier
2023-02-15 21:06 ` Basil L. Contovounesios
2023-02-16 7:44 ` Eli Zaretskii
2023-02-15 18:25 ` Juri Linkov
2023-01-19 16:53 Pedro Andres Aranda Gutierrez
2023-01-20 8:30 ` Eli Zaretskii
2023-01-20 16:31 ` Pedro Andres Aranda Gutierrez
2023-01-20 19:13 ` Eli Zaretskii
2023-01-21 11:30 ` Pedro Andres Aranda Gutierrez
2023-01-21 11:48 ` Eli Zaretskii
2023-01-22 6:23 ` Pedro Andres Aranda Gutierrez
2023-01-22 6:38 ` Eli Zaretskii
2023-01-22 10:46 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2023-02-18 7:55 Pedro Andres Aranda Gutierrez
2023-03-11 12:45 ` Ongaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+v24asr25nc9F4n@ACM \
--to=acm@muc.de \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jostein@secure.kjonigsen.net \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).