Re: Tree-sitter api

[Tuấn-Anh Nguyễn]

> > It can be both, with one being the underlying mechanism for the other. 
> > (That's
> > what I do in my packages.) The alist is a central place that's more 
> > convenient
> > for users (not mode writers) to customize, e.g. in case a major mode hasn't
> > added itself yet:
> >
> >     (add-hook 'foo-mode-hook (lambda () (setq tree-sitter-language-name 
> > 'foo)))
> >
> > is less convenient than
> >
> >     (add-to-list 'tree-sitter-major-mode-language-alist '(foo-mode . foo))
>
> Since in most cases TS support will require a fair bit more than just
> the language's name, I'm not sure it will be useful for very many users.

It has been useful (not "will be"). Of course it's more than just the language's
name.

> So I'd start with just `tree-sitter-language-name` (which should anyway
> be the main/canonical way to provide the language's name).

Yes, that's a good start.

> An alist indexed by a major mode is a "design smell" in my book.
>
> >> [ Among other things because it won't signal an error when
> >>   `tree-sitter.el` is not loaded.  ]
> > We can make `tree-sitter-major-mode-language-list` autoloaded.
>
> Autoloaded variables are also a design smell ;-)

These are non-arguments, but let's move on. This is among the most trivial ones
in the list of design decisions to make for tree-sitter integration. We don't
need to spend more time on it.

-- 
Tuấn-Anh Nguyễn
Software Engineer