bug#66183: elixir-ts-mode test failure

[Eli Zaretskii <eliz@gnu.org>]

Ping!

> Cc: wkirschbaum@gmail.com, 66183@debbugs.gnu.org, jm@pub.pink
> Date: Fri, 29 Sep 2023 14:14:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Cc: 66183@debbugs.gnu.org, jm@pub.pink
> > From: Yuan Fu <casouri@gmail.com>
> > Date: Tue, 26 Sep 2023 11:00:23 -0700
> > 
> > > On Sep 26, 2023, at 9:30 AM, Wilhelm Kirschbaum <wkirschbaum@gmail.com> wrote:
> > > 
> > > 
> > > Yuan Fu <casouri@gmail.com> writes:
> > > 
> > >>> On Sep 24, 2023, at 9:53 AM, john muhl via Bug reports for GNU
> > >>> Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org>
> > >>> wrote:
> > >>> The change in 5cba5ee8905 caused an elixir test to start failing. The
> > >>> white space at the start of the test is now in a heex range so pressing
> > >>> tab there matches a heex rule instead of the elixir one. Moving the
> > >>> dummy range to the end fixes the test.
> > >> 
> > >> Thank you. I’ll make sure to remember also running elixir tests when I make a change.
> > >> 
> > >> I looked around and found elixir-mode’s language-at-point function
> > >> works in a way that isn’t what tree-sitter functions
> > >> expect. Tree-sitter functions expect the major mode to derive language
> > >> at point by querying the host language and do some pattern matching,
> > >> rather than using language parser’s range. I took a quick look at
> > >> elixir’s grammar and came up with this version for a POC. You probably
> > > 
> > > Sorry about that.  I had absolutely no idea how it was expected to work.
> > 
> > It’s absolutely my fault :-) Several people have had confusion about it, because the docstring wasn’t clear enough. I’ve updated the docstring so hopefully this confusion won’t occur in the future.
> 
> Should this doc-string fix be cherry-picked to the release branch?
> 
> 
> 
>