Re: master 09b5f00613: ; Fix calls to treesit functions

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: casouri@gmail.com,  theo@thornhill.no,  emacs-devel@gnu.org
> Date: Tue, 20 Dec 2022 10:35:16 -0500
> 
> >> I think this can be done simply by listing which functions are always
> >> defined.
> >
> > No, this is not enough, IMO.  What is needed in addition is to
> > document how to know, with each of these always-defined functions,
> > whether tree-sitter can be used (most probably, by examining the
> > returned value).
> 
> That should be an obvious consequence of the behavior of the function
> without needing to document it specifically.
> 
> Like with `treesit-parser-list`: if the list is empty, then it means we
> don't have any parser at hand and that's it.

With functions returning a list, this is almost obvious, yes.  But
what about functions that return a buffer position, or a symbol, or
some other data type?  In those cases it is much less trivially
evident what to expect when tree-sitter support is unavailable.  Thus
the need to document this stuff.

> >> Then we just have to make sure that those functions can be
> >> implemented correctly even without Tree-sitter.
> > The implementation without tree-sitter will probably be trivial, like
> > return nil or something like that.
> 
> Yes, but for some functions this is not an option because we can't
> provide a correct behavior without using Tree-sitter.  So we have to
> choose the set of always-defined functions based on whether they *can*
> be correctly implemented without Tree-sitter.

Agreed.  My point was different, see abovge.

> `treesit-available-p`, `treesit-parser-list`, and `treesit-node-at` are
> functions we can implement without Tree-sitter, because nil is already
> the correct answer for those, without having to add any special
> case in their docstring for that.

If those are all that is needed, yes.