GNU bug report logs - #60511
29.0.50; treesit-ready-p should not emit warning by default

Previous Next

To reply to this bug, email your comments to 60511 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; treesit-ready-p should not emit warning by default
Date: Tue, 3 Jan 2023 11:19:14 +0000

Severity: wishlist

This currently emits a warning if the ruby grammar is not installed:

    (treesit-ready-p 'ruby)

I think it should *not* emit a warning, as no other predicates in Emacs
do (e.g. `featurep', `integerp', etc.).

It could have an optional flag to emit a warning, if there's a strong
need for that.  But personally, I'd rather see a new function for that.

I also don't see much need for the `message' symbol as the second
argument, so I'd simplify the API by dropping that part.  It's currently
unused in our tree.

Message #8 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Yuan Fu <casouri <at> gmail.com>, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Tue, 03 Jan 2023 19:44:27 +0200

> This currently emits a warning if the ruby grammar is not installed:
>
>     (treesit-ready-p 'ruby)
>
> I think it should *not* emit a warning, as no other predicates in Emacs
> do (e.g. `featurep', `integerp', etc.).
>
> It could have an optional flag to emit a warning, if there's a strong
> need for that.  But personally, I'd rather see a new function for that.
>
> I also don't see much need for the `message' symbol as the second
> argument, so I'd simplify the API by dropping that part.  It's currently
> unused in our tree.

Like the argument NOERROR of `require', the argument QUIET of `treesit-ready-p'
could do the same.

Message #11 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by 
 default
Date: Wed, 4 Jan 2023 00:02:36 -0700

Juri Linkov <juri <at> linkov.net> writes:

>> This currently emits a warning if the ruby grammar is not installed:
>>
>>     (treesit-ready-p 'ruby)
>>
>> I think it should *not* emit a warning, as no other predicates in Emacs
>> do (e.g. `featurep', `integerp', etc.).
>>
>> It could have an optional flag to emit a warning, if there's a strong
>> need for that.  But personally, I'd rather see a new function for that.
>>
>> I also don't see much need for the `message' symbol as the second
>> argument, so I'd simplify the API by dropping that part.  It's currently
>> unused in our tree.
>
> Like the argument NOERROR of `require', the argument QUIET of `treesit-ready-p'
> could do the same.

Maybe rename it to treesit-check-readiness?

Yuan

Message #14 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Wed, 04 Jan 2023 09:47:10 +0200

>>> This currently emits a warning if the ruby grammar is not installed:
>>>
>>>     (treesit-ready-p 'ruby)
>>>
>>> I think it should *not* emit a warning, as no other predicates in Emacs
>>> do (e.g. `featurep', `integerp', etc.).
>>>
>>> It could have an optional flag to emit a warning, if there's a strong
>>> need for that.  But personally, I'd rather see a new function for that.
>>>
>>> I also don't see much need for the `message' symbol as the second
>>> argument, so I'd simplify the API by dropping that part.  It's currently
>>> unused in our tree.
>>
>> Like the argument NOERROR of `require', the argument QUIET of `treesit-ready-p'
>> could do the same.
>
> Maybe rename it to treesit-check-readiness?

I think treesit-ready-p already is a good name.
We just need to support more values in its argument QUIET,
with a new value that does nothing in case of an error,
and just returns nil.

Message #17 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>,
 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by 
 default
Date: Sat, 7 Jan 2023 17:31:16 -0800

Juri Linkov <juri <at> linkov.net> writes:

>>>> This currently emits a warning if the ruby grammar is not installed:
>>>>
>>>>     (treesit-ready-p 'ruby)
>>>>
>>>> I think it should *not* emit a warning, as no other predicates in Emacs
>>>> do (e.g. `featurep', `integerp', etc.).
>>>>
>>>> It could have an optional flag to emit a warning, if there's a strong
>>>> need for that.  But personally, I'd rather see a new function for that.
>>>>
>>>> I also don't see much need for the `message' symbol as the second
>>>> argument, so I'd simplify the API by dropping that part.  It's currently
>>>> unused in our tree.
>>>
>>> Like the argument NOERROR of `require', the argument QUIET of `treesit-ready-p'
>>> could do the same.
>>
>> Maybe rename it to treesit-check-readiness?
>
> I think treesit-ready-p already is a good name.
> We just need to support more values in its argument QUIET,
> with a new value that does nothing in case of an error,
> and just returns nil.

It already has such option: if QUIET is t, treesit-ready-p returns nil and don’t emit anything.

I can make treesit-ready-p not emit any warning by default, and change
the quiet parameter to WARN, and accept either 'warn or ‘message.

Basically:

(treesit-ready-p lang) => t/nil
(treesit-ready-p lang 'warn) => t/emit warning
(treesit-ready-p lang 'message) => t/message

Eli, WDYT?

Yuan

Message #20 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by 
 default
Date: Sun, 08 Jan 2023 07:53:30 +0200

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sat, 7 Jan 2023 17:31:16 -0800
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,
>  60511 <at> debbugs.gnu.org,
>  Eli Zaretskii <eliz <at> gnu.org>
> 
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> >>>> This currently emits a warning if the ruby grammar is not installed:
> >>>>
> >>>>     (treesit-ready-p 'ruby)
> >>>>
> >>>> I think it should *not* emit a warning, as no other predicates in Emacs
> >>>> do (e.g. `featurep', `integerp', etc.).
> >>>>
> >>>> It could have an optional flag to emit a warning, if there's a strong
> >>>> need for that.  But personally, I'd rather see a new function for that.
> >>>>
> >>>> I also don't see much need for the `message' symbol as the second
> >>>> argument, so I'd simplify the API by dropping that part.  It's currently
> >>>> unused in our tree.
> >>>
> >>> Like the argument NOERROR of `require', the argument QUIET of `treesit-ready-p'
> >>> could do the same.
> >>
> >> Maybe rename it to treesit-check-readiness?
> >
> > I think treesit-ready-p already is a good name.
> > We just need to support more values in its argument QUIET,
> > with a new value that does nothing in case of an error,
> > and just returns nil.
> 
> It already has such option: if QUIET is t, treesit-ready-p returns nil and don’t emit anything.
> 
> I can make treesit-ready-p not emit any warning by default, and change
> the quiet parameter to WARN, and accept either 'warn or ‘message.
> 
> Basically:
> 
> (treesit-ready-p lang) => t/nil
> (treesit-ready-p lang 'warn) => t/emit warning
> (treesit-ready-p lang 'message) => t/message
> 
> Eli, WDYT?

I think the default should be to emit a warning, like we do now.  We
should support the main use case of the user turning on a TS mode when
the required libraries are not installed or incompatible with our
requirements.  Silently doing nothing in that case is not TRT.

No objections from me to extend the QUIET argument other than that.

Message #23 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Yuan Fu <casouri <at> gmail.com>, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 10:39:36 +0200

>> I can make treesit-ready-p not emit any warning by default, and change
>> the quiet parameter to WARN, and accept either 'warn or ‘message.
>> 
>> Basically:
>> 
>> (treesit-ready-p lang) => t/nil
>> (treesit-ready-p lang 'warn) => t/emit warning
>> (treesit-ready-p lang 'message) => t/message
>> 
>> Eli, WDYT?
>
> I think the default should be to emit a warning, like we do now.

Then how users could change this default?

Message #26 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 13:03:09 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Yuan Fu <casouri <at> gmail.com>,  stefankangas <at> gmail.com,
>   60511 <at> debbugs.gnu.org
> Date: Sun, 08 Jan 2023 10:39:36 +0200
> 
> >> I can make treesit-ready-p not emit any warning by default, and change
> >> the quiet parameter to WARN, and accept either 'warn or ‘message.
> >> 
> >> Basically:
> >> 
> >> (treesit-ready-p lang) => t/nil
> >> (treesit-ready-p lang 'warn) => t/emit warning
> >> (treesit-ready-p lang 'message) => t/message
> >> 
> >> Eli, WDYT?
> >
> > I think the default should be to emit a warning, like we do now.
> 
> Then how users could change this default?

In what situation?

If they invoke the mode, they aren't supposed to disable the warning,
and they cannot.

Message #29 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 19:35:27 +0200

>> >> I can make treesit-ready-p not emit any warning by default, and change
>> >> the quiet parameter to WARN, and accept either 'warn or ‘message.
>> >>
>> >> Basically:
>> >>
>> >> (treesit-ready-p lang) => t/nil
>> >> (treesit-ready-p lang 'warn) => t/emit warning
>> >> (treesit-ready-p lang 'message) => t/message
>> >>
>> >> Eli, WDYT?
>> >
>> > I think the default should be to emit a warning, like we do now.
>>
>> Then how users could change this default?
>
> In what situation?
>
> If they invoke the mode, they aren't supposed to disable the warning,
> and they cannot.

In a situation when they want simply to visit a file without using
tree-sitter features, and that visit won't require from them
customization with modifying auto-mode-alist, etc.

Message #32 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 19:57:48 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: casouri <at> gmail.com,  stefankangas <at> gmail.com,  60511 <at> debbugs.gnu.org
> Date: Sun, 08 Jan 2023 19:35:27 +0200
> 
> >> >> I can make treesit-ready-p not emit any warning by default, and change
> >> >> the quiet parameter to WARN, and accept either 'warn or ‘message.
> >> >>
> >> >> Basically:
> >> >>
> >> >> (treesit-ready-p lang) => t/nil
> >> >> (treesit-ready-p lang 'warn) => t/emit warning
> >> >> (treesit-ready-p lang 'message) => t/message
> >> >>
> >> >> Eli, WDYT?
> >> >
> >> > I think the default should be to emit a warning, like we do now.
> >>
> >> Then how users could change this default?
> >
> > In what situation?
> >
> > If they invoke the mode, they aren't supposed to disable the warning,
> > and they cannot.
> 
> In a situation when they want simply to visit a file without using
> tree-sitter features, and that visit won't require from them
> customization with modifying auto-mode-alist, etc.

This will soon become a non-issue, as I plan on removing all the TS
modes from auto-mode-alist.  Only loading the mode will add it back to
the alist.  So there will be no surprises, and no need to conceal the
warning.

Message #35 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>
Cc: 60511 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60511: 29.0.50;
 treesit-ready-p should not emit warning by default
Date: Sun, 8 Jan 2023 10:14:07 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I can make treesit-ready-p not emit any warning by default, and change
>> the quiet parameter to WARN, and accept either 'warn or ‘message.
>>
>> Basically:
>>
>> (treesit-ready-p lang) => t/nil
>> (treesit-ready-p lang 'warn) => t/emit warning
>> (treesit-ready-p lang 'message) => t/message

This makes sense to me.

>> Eli, WDYT?
>
> I think the default should be to emit a warning, like we do now.

In that case, it would be better to rename `treesit-ready-p' to reflect
that it's not a predicate function.  I believe Juri suggested the name
`treesit-check-readiness'.

Then there's the question if we want a predicate function for this too.
I think it would be useful.

> We should support the main use case of the user turning on a TS mode
> when the required libraries are not installed or incompatible with our
> requirements.  Silently doing nothing in that case is not TRT.

To be clear, I did not suggest changing that behavior.

Message #38 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 20:11:42 +0200

>> >> > I think the default should be to emit a warning, like we do now.
>> >>
>> >> Then how users could change this default?
>> >
>> > In what situation?
>> >
>> > If they invoke the mode, they aren't supposed to disable the warning,
>> > and they cannot.
>>
>> In a situation when they want simply to visit a file without using
>> tree-sitter features, and that visit won't require from them
>> customization with modifying auto-mode-alist, etc.
>
> This will soon become a non-issue, as I plan on removing all the TS
> modes from auto-mode-alist.  Only loading the mode will add it back to
> the alist.  So there will be no surprises, and no need to conceal the
> warning.

Why users need to always load modes that they are using only occasionally?

Message #41 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>,
 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 20:28:45 +0200

>> I think the default should be to emit a warning, like we do now.
>
> In that case, it would be better to rename `treesit-ready-p' to reflect
> that it's not a predicate function.  I believe Juri suggested the name
> `treesit-check-readiness'.

Actually, I think `treesit-check-readiness' is a worse name.

Message #44 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 20:48:20 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: casouri <at> gmail.com,  stefankangas <at> gmail.com,  60511 <at> debbugs.gnu.org
> Date: Sun, 08 Jan 2023 20:11:42 +0200
> 
> >> In a situation when they want simply to visit a file without using
> >> tree-sitter features, and that visit won't require from them
> >> customization with modifying auto-mode-alist, etc.
> >
> > This will soon become a non-issue, as I plan on removing all the TS
> > modes from auto-mode-alist.  Only loading the mode will add it back to
> > the alist.  So there will be no surprises, and no need to conceal the
> > warning.
> 
> Why users need to always load modes that they are using only occasionally?

If they want to use it permanently, they can load them in their init
files.

The idea is not to surprise users who were editing these kinds of
files before and don't have tree-sitter installed/configured.  If
these new modes are completely opt-in, they cannot surprise anyone by
an unexpected warning.

Message #47 received at 60511 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: casouri <at> gmail.com, stefankangas <at> gmail.com, 60511 <at> debbugs.gnu.org
Subject: Re: bug#60511: 29.0.50; treesit-ready-p should not emit warning by
 default
Date: Sun, 08 Jan 2023 20:49:02 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Yuan Fu <casouri <at> gmail.com>,
>   60511 <at> debbugs.gnu.org
> Date: Sun, 08 Jan 2023 20:28:45 +0200
> 
> >> I think the default should be to emit a warning, like we do now.
> >
> > In that case, it would be better to rename `treesit-ready-p' to reflect
> > that it's not a predicate function.  I believe Juri suggested the name
> > `treesit-check-readiness'.
> 
> Actually, I think `treesit-check-readiness' is a worse name.

I see no reason to rename the function, so let's not argue about its
name, okay?

Previous Next

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