Re: emacs-29 56cd810b9d1: Don’t signal warning when loading go-ts-mode.el without grammar

[Yuan Fu]

> On Mar 2, 2023, at 11:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 2 Mar 2023 19:05:27 -0800
>> Cc: Emacs developers <emacs-devel@gnu.org>
>> 
>>> 
>>> Yuan, why was this change made?  The fact that loading go-ts-mode.el
>>> without a grammar library causes a warning is the intended behavior:
>>> users who don't have tree-sitter setup for Go shouldn't load this
>>> mode, and if they do, they should know it failed, and why.  The above
>>> change makes it fail silently, which is not a Good Thing.
>> 
>> I thought that we’d want the warning to appear when user calls 
>> go-mod-ts-mode or open a file that uses that mode, rather than at load time. 
>> What I had in mind is when someone only install tree-sitter-go and want to 
>> edit some Go file, and they get this warning of go-mod being not available. 
>> This is what I encountered which prompted this change. I didn’t know that 
>> was intentional; since it’s intentional, please revert it (maybe you already 
>> have), and sorry for the hiccup :-)
> 
> This will happen with any *-ts-mode.el file that defines more than one
> mode for more than one grammar.  The only way of avoiding this is to
> separate the modes, and we decided not to do that, presumably for good
> reasons.  So the result is that users who want to edit Go files must
> also install the grammar for go.mod files (and similarly with C and
> C++).  The root cause is that when the file is loaded, we have no way
> of knowing for which of the two modes it was loaded.  This is a
> disadvantage of this arrangement, but as long as we keep these modes
> together on a single file, I don't see how we can avoid that.
> 
> So please revert those changes, as they go against what is planned for
> Emacs 29.
> 
>>> made this even worse: now we have a byte-compilation warning in a
>>> build without tree-sitter, and this code will signal a generic error
>>> (whose text is not very helpful to users) if the file is loaded in a
>>> build without tree-sitter.  This is all against the intended behavior
>>> of these modes.
>>> 
>>> Again, what problem were you trying to fix with that change?
>> 
>> Treesit-ready-p is intended to be used for major modes, so it includes 
>> checks for current buffer’s size, which doesn’t make much sense when called 
>> when loading the file. But if you intentionally used that function for the 
>> warning, I guess there is no harm using it this way, as the default size 
>> threshold is rather large.
> 
> If we want to avoid the buffer size text in some cases, we can add an
> optional argument to treesit-ready-p, and use it in those places.
> (And I agree that the test is probably harmless anyway.)

I’ve reverted the change.

Yuan