bug#64487: 29.0.92; Another tree-sitter warning inside Custom

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

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

Type M-x customize RET.  Click Programming and then Languages.  A
*Warnings* buffer will be displayed containing the following message:

  Warning (treesit): Cannot activate tree-sitter, because language
  grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
  libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
  libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
  directory

Can't these messages only be displayed when a tree-sitter major mode is
enabled, as opposed to whenever the file implementing the major mode is
loaded?

Thanks.

In GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu) of 2023-06-25 built
 on trinity
Windowing system distributor 'Sun Microsystems, Inc', version 11.0.6620
System Description: Fedora Linux 38 (Workstation Edition)

Configured using:
 'configure --with-x-toolkit=no --without-cairo
 --with-native-compilation=aot'

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

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Special

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Eli Zaretskii]

> Date: Thu, 06 Jul 2023 14:56:44 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Type M-x customize RET.  Click Programming and then Languages.  A
> *Warnings* buffer will be displayed containing the following message:
> 
>   Warning (treesit): Cannot activate tree-sitter, because language
>   grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
>   libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
>   libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
>   directory

When you customize a group, Custom loads all the packages that belong
to the group.  So in this case it loads ruby-ts-mode, and you get the
warning.

> Can't these messages only be displayed when a tree-sitter major mode is
> enabled, as opposed to whenever the file implementing the major mode is
> loaded?

Emacs 29 deliberately checks for the grammar's availability when the
package is loaded, to give users a prominent indication that the
loaded package will not work.  This won't change in Emacs 29, but
maybe as part of rethinking this after releasing Emacs 29 we could
improve the situation with customizing a group as well.

Anyway, the warning is just a warning, and is otherwise harmless.  It
also only appears when Emacs has been built with tree-sitter, but the
grammar libraries required by some *-ts-mode's are not installed.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Morgan Willcock]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 06 Jul 2023 14:56:44 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Type M-x customize RET.  Click Programming and then Languages.  A
>> *Warnings* buffer will be displayed containing the following message:
>> 
>>   Warning (treesit): Cannot activate tree-sitter, because language
>>   grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
>>   libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
>>   libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
>>   directory
>
> When you customize a group, Custom loads all the packages that belong
> to the group.  So in this case it loads ruby-ts-mode, and you get the
> warning.
>
>> Can't these messages only be displayed when a tree-sitter major mode is
>> enabled, as opposed to whenever the file implementing the major mode is
>> loaded?
>
> Emacs 29 deliberately checks for the grammar's availability when the
> package is loaded, to give users a prominent indication that the
> loaded package will not work.  This won't change in Emacs 29, but
> maybe as part of rethinking this after releasing Emacs 29 we could
> improve the situation with customizing a group as well.
>
> Anyway, the warning is just a warning, and is otherwise harmless.  It
> also only appears when Emacs has been built with tree-sitter, but the
> grammar libraries required by some *-ts-mode's are not installed.

I don't think this situation will be particularly rare for people who
choose to download the pre-built Windows binaries.

And I imagine that people choosing to acquire and run the program this
way (possibly because they do not know how to build the program
themselves) would probably be confused as to why the "out-of-the-box"
experience is generating warnings for features they are not actively
trying to use.

-- 
Morgan Willcock

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Dmitry Gutov]

On 06/07/2023 12:12, Eli Zaretskii wrote:
>> Date: Thu, 06 Jul 2023 14:56:44 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>   the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Type M-x customize RET.  Click Programming and then Languages.  A
>> *Warnings* buffer will be displayed containing the following message:
>>
>>    Warning (treesit): Cannot activate tree-sitter, because language
>>    grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
>>    libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
>>    libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
>>    directory
> 
> When you customize a group, Custom loads all the packages that belong
> to the group.  So in this case it loads ruby-ts-mode, and you get the
> warning.

Which was never a problem before when simply loading a package didn't 
alter auto-mode-alist.

>> Can't these messages only be displayed when a tree-sitter major mode is
>> enabled, as opposed to whenever the file implementing the major mode is
>> loaded?
> 
> Emacs 29 deliberately checks for the grammar's availability when the
> package is loaded, to give users a prominent indication that the
> loaded package will not work.  This won't change in Emacs 29, but
> maybe as part of rethinking this after releasing Emacs 29 we could
> improve the situation with customizing a group as well.
> 
> Anyway, the warning is just a warning, and is otherwise harmless.  It
> also only appears when Emacs has been built with tree-sitter, but the
> grammar libraries required by some *-ts-mode's are not installed.

Suppose the grammar is actually available. Perhaps the user had compiled 
it at some point, or perhaps it's installed system-wide due to another 
dependency.

Do I understand it right that performing the simple steps that Po Lu 
outlined would silently assign ruby-ts-mode to *.rb files? And a bunch 
of other such modes that get loaded as well. But only until the end of 
the session.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Eli Zaretskii]

> Date: Mon, 26 Feb 2024 18:25:33 +0200
> Cc: 64487@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 06/07/2023 12:12, Eli Zaretskii wrote:
> >> Date: Thu, 06 Jul 2023 14:56:44 +0800
> >> From:  Po Lu via "Bug reports for GNU Emacs,
> >>   the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >>
> >> Type M-x customize RET.  Click Programming and then Languages.  A
> >> *Warnings* buffer will be displayed containing the following message:
> >>
> >>    Warning (treesit): Cannot activate tree-sitter, because language
> >>    grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
> >>    libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
> >>    libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
> >>    directory
> > 
> > When you customize a group, Custom loads all the packages that belong
> > to the group.  So in this case it loads ruby-ts-mode, and you get the
> > warning.
> 
> Which was never a problem before when simply loading a package didn't 
> alter auto-mode-alist.

You want to start that old dispute again?  I didn't expect you to
change your opinions, and you shouldn't expect me to change mine.  So
why restart that?

> Do I understand it right that performing the simple steps that Po Lu 
> outlined would silently assign ruby-ts-mode to *.rb files? And a bunch 
> of other such modes that get loaded as well. But only until the end of 
> the session.

Could be, I didn't try.  If that's what happens, patches to avoid such
a long-lasting effect, without changing what happens when the package
is loaded outside of the Customize context, will be welcome.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Dmitry Gutov]

On 26/02/2024 18:49, Eli Zaretskii wrote:
>> Date: Mon, 26 Feb 2024 18:25:33 +0200
>> Cc: 64487@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 06/07/2023 12:12, Eli Zaretskii wrote:
>>>> Date: Thu, 06 Jul 2023 14:56:44 +0800
>>>> From:  Po Lu via "Bug reports for GNU Emacs,
>>>>    the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>>
>>>> Type M-x customize RET.  Click Programming and then Languages.  A
>>>> *Warnings* buffer will be displayed containing the following message:
>>>>
>>>>     Warning (treesit): Cannot activate tree-sitter, because language
>>>>     grammar for ruby is unavailable (not-found): (libtree-sitter-ruby
>>>>     libtree-sitter-ruby.0 libtree-sitter-ruby.0.0 libtree-sitter-ruby.so
>>>>     libtree-sitter-ruby.so.0 libtree-sitter-ruby.so.0.0) No such file or
>>>>     directory
>>>
>>> When you customize a group, Custom loads all the packages that belong
>>> to the group.  So in this case it loads ruby-ts-mode, and you get the
>>> warning.
>>
>> Which was never a problem before when simply loading a package didn't
>> alter auto-mode-alist.
> 
> You want to start that old dispute again?  I didn't expect you to
> change your opinions, and you shouldn't expect me to change mine.  So
> why restart that?

I remember you saying that it was a question which is settled until any 
other problems come up. Isn't this an example of such problem?

>> Do I understand it right that performing the simple steps that Po Lu
>> outlined would silently assign ruby-ts-mode to *.rb files? And a bunch
>> of other such modes that get loaded as well. But only until the end of
>> the session.
> 
> Could be, I didn't try.  If that's what happens, patches to avoid such
> a long-lasting effect, without changing what happens when the package
> is loaded outside of the Customize context, will be welcome.

I don't have any solutions to suggest except holding to the principle 
that simply loading a package has as few side-effects as possible. Which 
would mean reverting your earlier decision.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Eli Zaretskii]

> Date: Mon, 26 Feb 2024 18:55:09 +0200
> Cc: luangruo@yahoo.com, 64487@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> I remember you saying that it was a question which is settled until any 
> other problems come up. Isn't this an example of such problem?

No, I don't think so.  It is a very special case, which is rarely a
problem (only if the user decides eventually not to activate the
mode).

> >> Do I understand it right that performing the simple steps that Po Lu
> >> outlined would silently assign ruby-ts-mode to *.rb files? And a bunch
> >> of other such modes that get loaded as well. But only until the end of
> >> the session.
> > 
> > Could be, I didn't try.  If that's what happens, patches to avoid such
> > a long-lasting effect, without changing what happens when the package
> > is loaded outside of the Customize context, will be welcome.
> 
> I don't have any solutions to suggest except holding to the principle 
> that simply loading a package has as few side-effects as possible. Which 
> would mean reverting your earlier decision.

I don't see a reason for such radical solutions because of this use
case.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Dmitry Gutov]

On 26/02/2024 19:02, Eli Zaretskii wrote:
>> Date: Mon, 26 Feb 2024 18:55:09 +0200
>> Cc:luangruo@yahoo.com,64487@debbugs.gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> I remember you saying that it was a question which is settled until any
>> other problems come up. Isn't this an example of such problem?
> No, I don't think so.  It is a very special case, which is rarely a
> problem (only if the user decides eventually not to activate the
> mode).

Which mode, though?

The sequence of actions does not pertain to any particular mode: it's 
just Customize -> Programming -> Languages.

Going through these steps with 'emacs -Q' here, I got both a warning 
about the missing lua grammar (14 lines tall), and both ruby-ts-mode and 
  elixir-ts-mode added to auto-mode-alist, which weren't there before.

And then visiting the "C" node (which is not specific to the tree-sitter 
modes, to be clear -- it's mostly CC Mode variables), I get also 
c-ts-mode, c++-ts-mode and c-or-c++-ts-mode added there.

There would be more modes added, but apparently some use groups with no 
parent defined (such as 'java' or 'json'), so they're not reachable from 
the general Customize interface.

bug#64487: 29.0.92; Another tree-sitter warning inside Custom

[Eli Zaretskii]

> Date: Tue, 27 Feb 2024 06:23:36 +0200
> Cc: luangruo@yahoo.com, 64487@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 26/02/2024 19:02, Eli Zaretskii wrote:
> >> Date: Mon, 26 Feb 2024 18:55:09 +0200
> >> Cc:luangruo@yahoo.com,64487@debbugs.gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> I remember you saying that it was a question which is settled until any
> >> other problems come up. Isn't this an example of such problem?
> > No, I don't think so.  It is a very special case, which is rarely a
> > problem (only if the user decides eventually not to activate the
> > mode).
> 
> Which mode, though?

The one(s) that are of interest for the user.