bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Mohammed Sadiq]

It would be nice if the fallback mode is used when treesitter is not
usable.  Say for example, for the following file variable in a C file:


/* -*- mode: c; mode: c-ts; -*- */


If c-ts-mode is not usable (regardless of whether the mode is
available), activate c-mode instead.

This bug is regarding the automatically loaded mode when a file with 
some
mode is set, and not regarding the user explicitly setting the mode.

Supporting this can help me use multiple mode file variables regardless
of the GNU Emacs version used by co-developers.


In GNU Emacs 29.0.60 (build 7, x86_64-pc-linux-gnu, GTK+ Version
  3.24.35, cairo version 1.16.0) of 2022-12-18 built on purism
Repository revision: 5b2e6d04ce271cca2de944f8f5c07c005da33e37
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101004
System Description: Debian GNU/Linux bookworm/sid

Configured using:
  'configure --prefix=/usr'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LANG: en_IN.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: C

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
warnings icons c-ts-mode treesit cl-seq cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 59479 7190)
  (symbols 48 7146 0)
  (strings 32 20640 2145)
  (string-bytes 1 740726)
  (vectors 16 12858)
  (vector-slots 8 184206 12553)
  (floats 8 29 94)
  (intervals 56 239 0)
  (buffers 984 13))

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

> It would be nice if the fallback mode is used when treesitter is not
> usable.  Say for example, for the following file variable in a C file:
>
> /* -*- mode: c; mode: c-ts; -*- */
>
> If c-ts-mode is not usable (regardless of whether the mode is
> available), activate c-mode instead.
>
> This bug is regarding the automatically loaded mode when a file with some
> mode is set, and not regarding the user explicitly setting the mode.
>
> Supporting this can help me use multiple mode file variables regardless
> of the GNU Emacs version used by co-developers.

'major-mode-remap-alist' should be able to handle this requirement
since its design is similar to MIME.TYPES and MAILCAP.  But actually
MAILCAP supports an additional predicate TEST that is a command
executed to determine whether or not the mailcap line applies.

So to completely cover all needs, 'major-mode-remap-alist' should
support a predicate as well.  For example,

(setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))

or a more complex predicate:

(setq major-mode-remap-alist '((c-mode (lambda ()
                                         (and (treesit-available-p)
                                              (treesit-ready-p 'c t)))
                                c-ts-mode)))

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 60176@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 19 Dec 2022 09:39:14 +0200
> 
> > It would be nice if the fallback mode is used when treesitter is not
> > usable.  Say for example, for the following file variable in a C file:
> >
> > /* -*- mode: c; mode: c-ts; -*- */
> >
> > If c-ts-mode is not usable (regardless of whether the mode is
> > available), activate c-mode instead.
> >
> > This bug is regarding the automatically loaded mode when a file with some
> > mode is set, and not regarding the user explicitly setting the mode.
> >
> > Supporting this can help me use multiple mode file variables regardless
> > of the GNU Emacs version used by co-developers.
> 
> 'major-mode-remap-alist' should be able to handle this requirement
> since its design is similar to MIME.TYPES and MAILCAP.  But actually
> MAILCAP supports an additional predicate TEST that is a command
> executed to determine whether or not the mailcap line applies.
> 
> So to completely cover all needs, 'major-mode-remap-alist' should
> support a predicate as well.  For example,
> 
> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))
> 
> or a more complex predicate:
> 
> (setq major-mode-remap-alist '((c-mode (lambda ()
>                                          (and (treesit-available-p)
>                                               (treesit-ready-p 'c t)))
>                                 c-ts-mode)))

I think the idea is that this should happen by default, not as a
(not-so-trivial) customization by the users.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Mohammed Sadiq]

On 2022-12-19 18:05, Eli Zaretskii wrote:
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 60176@debbugs.gnu.org
>> From: Juri Linkov <juri@linkov.net>
>> Date: Mon, 19 Dec 2022 09:39:14 +0200
>> 
>> > It would be nice if the fallback mode is used when treesitter is not
>> > usable.  Say for example, for the following file variable in a C file:
>> >
>> > /* -*- mode: c; mode: c-ts; -*- */
>> >
>> > If c-ts-mode is not usable (regardless of whether the mode is
>> > available), activate c-mode instead.
>> >
>> > This bug is regarding the automatically loaded mode when a file with some
>> > mode is set, and not regarding the user explicitly setting the mode.
>> >
>> > Supporting this can help me use multiple mode file variables regardless
>> > of the GNU Emacs version used by co-developers.
>> 
>> 'major-mode-remap-alist' should be able to handle this requirement
>> since its design is similar to MIME.TYPES and MAILCAP.  But actually
>> MAILCAP supports an additional predicate TEST that is a command
>> executed to determine whether or not the mailcap line applies.
>> 
>> So to completely cover all needs, 'major-mode-remap-alist' should
>> support a predicate as well.  For example,
>> 
>> (setq major-mode-remap-alist '((c-mode #'treesit-available-p 
>> c-ts-mode)))
>> 
>> or a more complex predicate:
>> 
>> (setq major-mode-remap-alist '((c-mode (lambda ()
>>                                          (and (treesit-available-p)
>>                                               (treesit-ready-p 'c t)))
>>                                 c-ts-mode)))
> 
> I think the idea is that this should happen by default, not as a
> (not-so-trivial) customization by the users.

Right, that's what I was suggesting.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))

The current syntax is rather

    (setq major-mode-remap-alist '((c-mode . treesit-available-p c-ts-mode)))

> I think the idea is that this should happen by default, not as a
> (not-so-trivial) customization by the users.

Agreed.  `major-mode-remap-alist` is a custom var and I think we should
try and keep its default value as close to nil as possible.


        Stefan

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>> So to completely cover all needs, 'major-mode-remap-alist' should
>> support a predicate as well.  For example,
>>
>> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))
>
> I think the idea is that this should happen by default, not as a
> (not-so-trivial) customization by the users.

Then 'c-ts-mode' should fall back to 'c-mode' when treesit is not available?
Like this:

```
diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index cf941236f82..5004b9a5e1d 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -616,7 +616,7 @@ c-ts-mode
 (define-derived-mode c-ts-mode c-ts-base-mode "C"
 
   (unless (treesit-ready-p 'c)
-    (error "Tree-sitter for C isn't available"))
+    (c-mode))
 
   (treesit-parser-create 'c)
 
```

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: sadiq@sadiqpk.org,  monnier@iro.umontreal.ca,  60176@debbugs.gnu.org
> Date: Mon, 19 Dec 2022 19:29:13 +0200
> 
> >> So to completely cover all needs, 'major-mode-remap-alist' should
> >> support a predicate as well.  For example,
> >>
> >> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))
> >
> > I think the idea is that this should happen by default, not as a
> > (not-so-trivial) customization by the users.
> 
> Then 'c-ts-mode' should fall back to 'c-mode' when treesit is not available?
> Like this:
> 
> ```
> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
> index cf941236f82..5004b9a5e1d 100644
> --- a/lisp/progmodes/c-ts-mode.el
> +++ b/lisp/progmodes/c-ts-mode.el
> @@ -616,7 +616,7 @@ c-ts-mode
>  (define-derived-mode c-ts-mode c-ts-base-mode "C"
>  
>    (unless (treesit-ready-p 'c)
> -    (error "Tree-sitter for C isn't available"))
> +    (c-mode))

Yes.  But not literally like that, because, for example, we don't want
that to happen when c-ts-mode is invoked interactively by the user --
in that case we do want to signal an error.

The automatic fallback should IMO happen only in situations like mode
specifications in 'mode' cookies or file-local variables, where it is
better to visit in a similar mode than completely fail visiting a
file.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Yuan Fu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: sadiq@sadiqpk.org,  monnier@iro.umontreal.ca,  60176@debbugs.gnu.org
>> Date: Mon, 19 Dec 2022 19:29:13 +0200
>> 
>> >> So to completely cover all needs, 'major-mode-remap-alist' should
>> >> support a predicate as well.  For example,
>> >>
>> >> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))
>> >
>> > I think the idea is that this should happen by default, not as a
>> > (not-so-trivial) customization by the users.
>> 
>> Then 'c-ts-mode' should fall back to 'c-mode' when treesit is not available?
>> Like this:
>> 
>> ```
>> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
>> index cf941236f82..5004b9a5e1d 100644
>> --- a/lisp/progmodes/c-ts-mode.el
>> +++ b/lisp/progmodes/c-ts-mode.el
>> @@ -616,7 +616,7 @@ c-ts-mode
>>  (define-derived-mode c-ts-mode c-ts-base-mode "C"
>>  
>>    (unless (treesit-ready-p 'c)
>> -    (error "Tree-sitter for C isn't available"))
>> +    (c-mode))
>
> Yes.  But not literally like that, because, for example, we don't want
> that to happen when c-ts-mode is invoked interactively by the user --
> in that case we do want to signal an error.
>
> The automatic fallback should IMO happen only in situations like mode
> specifications in 'mode' cookies or file-local variables, where it is
> better to visit in a similar mode than completely fail visiting a
> file.

Also (mentioned by Stefan in another thread), we probably don’t want
c-mode-hook to run if we decide to fall back to c-ts-mode.

I don’t have a good way to cleanly implement such fallback without
changing auto mode, local variable, define-derived-mode, etc. I used
Stefan’s advice hack on bash-ts-mode, only because bash-ts-mode only
supports bash and it has to fallback to sh-mode for other shell scripts,
otherwise it would be a pain to use.

Yuan

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>> 'major-mode-remap-alist' should be able to handle this requirement
>> since its design is similar to MIME.TYPES and MAILCAP.  But actually
>> MAILCAP supports an additional predicate TEST that is a command
>> executed to determine whether or not the mailcap line applies.
>>
>> So to completely cover all needs, 'major-mode-remap-alist' should
>> support a predicate as well.  For example,
>>
>> (setq major-mode-remap-alist '((c-mode #'treesit-available-p c-ts-mode)))
>
> The current syntax is rather
>
>     (setq major-mode-remap-alist '((c-mode . treesit-available-p c-ts-mode)))

Is it possible at least to make this forward-compatible to support
such a predicate in future?  To enable ts-modes only in some buffers
currently requires first to enable non-ts-mode, then conditionally ts-mode:

(add-hook 'find-file-hook
          (lambda ()
            (when (and (eq major-mode 'c-mode)
                       ;; Unless in internal buffers:
                       (not (string-prefix-p " " (buffer-name))))
              (c-ts-mode))))

With a predicate in major-mode-remap-alist it would immediately
enable the required mode:

(setq major-mode-remap-alist
      '((c-mode . (lambda () (not (string-prefix-p " " (buffer-name))))
                c-ts-mode)))

Such a predicate would be useful in many other cases.  For example,
by default ".pl" is assigned to perl-mode, but this would help to
reassign it to prolog-mode using some heuristics:

(setq major-mode-remap-alist
      '((perl-mode . (lambda () (string-match-p "src/prolog" buffer-file-name))
                prolog-mode)))

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  sadiq@sadiqpk.org,  60176@debbugs.gnu.org
> Date: Mon, 09 Jan 2023 19:30:20 +0200
> 
> Is it possible at least to make this forward-compatible to support
> such a predicate in future?  To enable ts-modes only in some buffers
> currently requires first to enable non-ts-mode, then conditionally ts-mode:
> 
> (add-hook 'find-file-hook
>           (lambda ()
>             (when (and (eq major-mode 'c-mode)
>                        ;; Unless in internal buffers:
>                        (not (string-prefix-p " " (buffer-name))))
>               (c-ts-mode))))
> 
> With a predicate in major-mode-remap-alist it would immediately
> enable the required mode:
> 
> (setq major-mode-remap-alist
>       '((c-mode . (lambda () (not (string-prefix-p " " (buffer-name))))
>                 c-ts-mode)))

Why do we need such hoops to jump through?  I think we should simply
add

 (add-to-list 'auto-mode-alist
              '("\\.[ch]\\'" . c-ts-mode))

to c-ts-mode.el (and similarly for C++), and that's it.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> The current syntax is rather
>>
>>     (setq major-mode-remap-alist '((c-mode . treesit-available-p c-ts-mode)))
>
> Is it possible at least to make this forward-compatible to support
> such a predicate in future?  To enable ts-modes only in some buffers
> currently requires first to enable non-ts-mode, then conditionally ts-mode:

We can use:

    (setq (alist-get 'c-mode major-mode-remap-alist)
          (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))


-- Stefan

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  sadiq@sadiqpk.org,  60176@debbugs.gnu.org
> Date: Mon, 09 Jan 2023 18:06:17 -0500
> 
> >> The current syntax is rather
> >>
> >>     (setq major-mode-remap-alist '((c-mode . treesit-available-p c-ts-mode)))
> >
> > Is it possible at least to make this forward-compatible to support
> > such a predicate in future?  To enable ts-modes only in some buffers
> > currently requires first to enable non-ts-mode, then conditionally ts-mode:
> 
> We can use:
> 
>     (setq (alist-get 'c-mode major-mode-remap-alist)
>           (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))

Who is "we" here?

I don't want to do this by default, because we want users of Emacs 29
to turn on TS modes manually, if and when they want that and think
they are ready.

Of course, I don't mind if the above is done in local customizations
by users who are willing to use TS modes whenever they become
available.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> We can use:
>> 
>>     (setq (alist-get 'c-mode major-mode-remap-alist)
>>           (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))
>
> Who is "we" here?

"we" as in "we can recommend this to those users who want to do that".

> I don't want to do this by default, because we want users of Emacs 29

I don't either.  I was just answering to the request to make room in the
format of `major-mode-remap-alist` for a potential future "predicate",
by pointing out that the current format already allows that.


        Stefan

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>>     (setq (alist-get 'c-mode major-mode-remap-alist)
>>           (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))
>
> I don't want to do this by default, because we want users of Emacs 29
> to turn on TS modes manually, if and when they want that and think
> they are ready.
>
> Of course, I don't mind if the above is done in local customizations
> by users who are willing to use TS modes whenever they become
> available.

Shouldn't we help users by simplifying such complex customization
and provide a customizable list of modes where tree-sitter is enabled,
e.g.

(defcustom treesit-enable-modes nil
  :type '(repeat
          (choice (function-item c-ts-mode)
                  (function-item c++-ts-mode)
                  (function-item c-or-c++-ts-mode)
                  ...
  :initialize #'custom-initialize-default
  :set (lambda (sym val)
         (set-default sym val)
         (dolist (mode treesit-enable-modes)
           (pcase mode
             ('c-ts-mode
              (when (treesit-ready-p 'c t)
                (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
             ...

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  sadiq@sadiqpk.org,
>   60176@debbugs.gnu.org
> Date: Tue, 10 Jan 2023 20:08:15 +0200
> 
> >>     (setq (alist-get 'c-mode major-mode-remap-alist)
> >>           (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))
> >
> > I don't want to do this by default, because we want users of Emacs 29
> > to turn on TS modes manually, if and when they want that and think
> > they are ready.
> >
> > Of course, I don't mind if the above is done in local customizations
> > by users who are willing to use TS modes whenever they become
> > available.
> 
> Shouldn't we help users by simplifying such complex customization

What is so complex in activating a mode with a single command or a
function call?  Users do that all the time in their init files and
manually.

> and provide a customizable list of modes where tree-sitter is enabled,
> e.g.
> 
> (defcustom treesit-enable-modes nil
>   :type '(repeat
>           (choice (function-item c-ts-mode)
>                   (function-item c++-ts-mode)
>                   (function-item c-or-c++-ts-mode)
>                   ...

I disagree that asking users to customize lists of modes is helping
them.  I think just activating the modes they want, either manually or
in the init files, is a much simpler way of customization.  I don't
understand why you think the above is helping the users in any way.

>              ('c-ts-mode
>               (when (treesit-ready-p 'c t)
>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))

And this bit is completely unacceptable, from where I stand: it
basically means that the user activated a certain major mode he/she
wanted to use, but the result could be that an entirely different mode
was silently activated instead.  What kind of UX is that, and for a
shining new feature at that??

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>> (defcustom treesit-enable-modes nil
>>   :type '(repeat
>>           (choice (function-item c-ts-mode)
>>                   (function-item c++-ts-mode)
>>                   (function-item c-or-c++-ts-mode)
>>                   ...
>>              ('c-ts-mode
>>               (when (treesit-ready-p 'c t)
>>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
>
> And this bit is completely unacceptable, from where I stand: it
> basically means that the user activated a certain major mode he/she
> wanted to use, but the result could be that an entirely different mode
> was silently activated instead.  What kind of UX is that, and for a
> shining new feature at that??

It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
From the user's point of view this would be more manageable than
what you proposed on emacs-devel with some obscure logic of activating
ts modes when the package is loaded or when the mode is enabled first time.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  sadiq@sadiqpk.org,  60176@debbugs.gnu.org
> Date: Mon, 16 Jan 2023 19:32:06 +0200
> 
> >> (defcustom treesit-enable-modes nil
> >>   :type '(repeat
> >>           (choice (function-item c-ts-mode)
> >>                   (function-item c++-ts-mode)
> >>                   (function-item c-or-c++-ts-mode)
> >>                   ...
> >>              ('c-ts-mode
> >>               (when (treesit-ready-p 'c t)
> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
> >
> > And this bit is completely unacceptable, from where I stand: it
> > basically means that the user activated a certain major mode he/she
> > wanted to use, but the result could be that an entirely different mode
> > was silently activated instead.  What kind of UX is that, and for a
> > shining new feature at that??
> 
> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
> >From the user's point of view this would be more manageable than
> what you proposed on emacs-devel with some obscure logic of activating
> ts modes when the package is loaded or when the mode is enabled first time.

I don't understand the "obscure" part: the logic was exactly as above:
test that treesit-ready-p returns non-nil for the mode's language.

Other than that, my proposal does exactly what you say here: it
updates auto-mode-alist.  So it sounds like we are in violent agreement.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>> >> (defcustom treesit-enable-modes nil
>> >>   :type '(repeat
>> >>           (choice (function-item c-ts-mode)
>> >>                   (function-item c++-ts-mode)
>> >>                   (function-item c-or-c++-ts-mode)
>> >>                   ...
>> >>              ('c-ts-mode
>> >>               (when (treesit-ready-p 'c t)
>> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
>> >
>> > And this bit is completely unacceptable, from where I stand: it
>> > basically means that the user activated a certain major mode he/she
>> > wanted to use, but the result could be that an entirely different mode
>> > was silently activated instead.  What kind of UX is that, and for a
>> > shining new feature at that??
>>
>> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
>> >From the user's point of view this would be more manageable than
>> what you proposed on emacs-devel with some obscure logic of activating
>> ts modes when the package is loaded or when the mode is enabled first time.
>
> I don't understand the "obscure" part: the logic was exactly as above:
> test that treesit-ready-p returns non-nil for the mode's language.
>
> Other than that, my proposal does exactly what you say here: it
> updates auto-mode-alist.  So it sounds like we are in violent agreement.

The difference is that an explicit option is more controllable by the user.
When the user needs to use some ts-mode then it's easier just to customize
the option instead of tweaking 'auto-mode-alist' when the user want to
start using that mode without first loading its package or calling it
the first time that modifies 'auto-mode-alist' as the side effect.
Or when the user wants to remove the mode from 'auto-mode-alist' after
accidentally loading the corresponding ts package.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  sadiq@sadiqpk.org,  60176@debbugs.gnu.org
> Date: Mon, 16 Jan 2023 20:36:45 +0200
> 
> >> >> (defcustom treesit-enable-modes nil
> >> >>   :type '(repeat
> >> >>           (choice (function-item c-ts-mode)
> >> >>                   (function-item c++-ts-mode)
> >> >>                   (function-item c-or-c++-ts-mode)
> >> >>                   ...
> >> >>              ('c-ts-mode
> >> >>               (when (treesit-ready-p 'c t)
> >> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
> >> >
> >> > And this bit is completely unacceptable, from where I stand: it
> >> > basically means that the user activated a certain major mode he/she
> >> > wanted to use, but the result could be that an entirely different mode
> >> > was silently activated instead.  What kind of UX is that, and for a
> >> > shining new feature at that??
> >>
> >> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
> >> >From the user's point of view this would be more manageable than
> >> what you proposed on emacs-devel with some obscure logic of activating
> >> ts modes when the package is loaded or when the mode is enabled first time.
> >
> > I don't understand the "obscure" part: the logic was exactly as above:
> > test that treesit-ready-p returns non-nil for the mode's language.
> >
> > Other than that, my proposal does exactly what you say here: it
> > updates auto-mode-alist.  So it sounds like we are in violent agreement.
> 
> The difference is that an explicit option is more controllable by the user.
> When the user needs to use some ts-mode then it's easier just to customize
> the option instead of tweaking 'auto-mode-alist' when the user want to
> start using that mode without first loading its package or calling it
> the first time that modifies 'auto-mode-alist' as the side effect.

With the changes I proposed, there's no need to tweak
auto-mode-alist.  A simple load or require of the mode will install
the mode in auto-mode-alist.  What can be easier and simpler?

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Juri Linkov]

>> >> >> (defcustom treesit-enable-modes nil
>> >> >>   :type '(repeat
>> >> >>           (choice (function-item c-ts-mode)
>> >> >>                   (function-item c++-ts-mode)
>> >> >>                   (function-item c-or-c++-ts-mode)
>> >> >>                   ...
>> >> >>              ('c-ts-mode
>> >> >>               (when (treesit-ready-p 'c t)
>> >> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
>> >> >
>> >> > And this bit is completely unacceptable, from where I stand: it
>> >> > basically means that the user activated a certain major mode he/she
>> >> > wanted to use, but the result could be that an entirely different mode
>> >> > was silently activated instead.  What kind of UX is that, and for a
>> >> > shining new feature at that??
>> >>
>> >> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
>> >> >From the user's point of view this would be more manageable than
>> >> what you proposed on emacs-devel with some obscure logic of activating
>> >> ts modes when the package is loaded or when the mode is enabled first time.
>> >
>> > I don't understand the "obscure" part: the logic was exactly as above:
>> > test that treesit-ready-p returns non-nil for the mode's language.
>> >
>> > Other than that, my proposal does exactly what you say here: it
>> > updates auto-mode-alist.  So it sounds like we are in violent agreement.
>>
>> The difference is that an explicit option is more controllable by the user.
>> When the user needs to use some ts-mode then it's easier just to customize
>> the option instead of tweaking 'auto-mode-alist' when the user want to
>> start using that mode without first loading its package or calling it
>> the first time that modifies 'auto-mode-alist' as the side effect.
>
> With the changes I proposed, there's no need to tweak
> auto-mode-alist.  A simple load or require of the mode will install
> the mode in auto-mode-alist.  What can be easier and simpler?

This doesn't address the problems mentioned above and below.

>> Or when the user wants to remove the mode from 'auto-mode-alist' after
>> accidentally loading the corresponding ts package.

bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  sadiq@sadiqpk.org,  60176@debbugs.gnu.org
> Date: Tue, 17 Jan 2023 09:33:02 +0200
> 
> >> >> >> (defcustom treesit-enable-modes nil
> >> >> >>   :type '(repeat
> >> >> >>           (choice (function-item c-ts-mode)
> >> >> >>                   (function-item c++-ts-mode)
> >> >> >>                   (function-item c-or-c++-ts-mode)
> >> >> >>                   ...
> >> >> >>              ('c-ts-mode
> >> >> >>               (when (treesit-ready-p 'c t)
> >> >> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
> >> >> >
> >> >> > And this bit is completely unacceptable, from where I stand: it
> >> >> > basically means that the user activated a certain major mode he/she
> >> >> > wanted to use, but the result could be that an entirely different mode
> >> >> > was silently activated instead.  What kind of UX is that, and for a
> >> >> > shining new feature at that??
> >> >>
> >> >> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
> >> >> >From the user's point of view this would be more manageable than
> >> >> what you proposed on emacs-devel with some obscure logic of activating
> >> >> ts modes when the package is loaded or when the mode is enabled first time.
> >> >
> >> > I don't understand the "obscure" part: the logic was exactly as above:
> >> > test that treesit-ready-p returns non-nil for the mode's language.
> >> >
> >> > Other than that, my proposal does exactly what you say here: it
> >> > updates auto-mode-alist.  So it sounds like we are in violent agreement.
> >>
> >> The difference is that an explicit option is more controllable by the user.
> >> When the user needs to use some ts-mode then it's easier just to customize
> >> the option instead of tweaking 'auto-mode-alist' when the user want to
> >> start using that mode without first loading its package or calling it
> >> the first time that modifies 'auto-mode-alist' as the side effect.
> >
> > With the changes I proposed, there's no need to tweak
> > auto-mode-alist.  A simple load or require of the mode will install
> > the mode in auto-mode-alist.  What can be easier and simpler?
> 
> This doesn't address the problems mentioned above and below.

Which parts "above" were not addressed?

As for below:

> >> Or when the user wants to remove the mode from 'auto-mode-alist' after
> >> accidentally loading the corresponding ts package.

I addressed that in the discussion on emacs-devel, see

  https://lists.gnu.org/archive/html/emacs-devel/2023-01/msg00278.html

(I suggest to discuss this there, not here.)