GNU bug report logs - #64487
29.0.92; Another tree-sitter warning inside Custom

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 64487 <at> debbugs.gnu.org
Subject: bug#64487: 29.0.92; Another tree-sitter warning inside Custom
Date: Mon, 26 Feb 2024 18:55:09 +0200

On 26/02/2024 18:49, Eli Zaretskii wrote:
>> Date: Mon, 26 Feb 2024 18:25:33 +0200
>> Cc: 64487 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> 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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.