GNU bug report logs - #66183
elixir-ts-mode test failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66183 in the body.
You can then email your comments to 66183 AT debbugs.gnu.org in the normal way.

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

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

From: john muhl <jm <at> pub.pink>
To: bug-gnu-emacs <at> gnu.org
Cc: Yuan Fu <casouri <at> gmail.com>
Subject: elixir-ts-mode test failure
Date: Sun, 24 Sep 2023 11:53:19 -0500

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.

--- a/lisp/treesit.el
+++ b/lisp/treesit.el
@@ -722,7 +722,7 @@ treesit-update-ranges
                           ;; language, set it's range to a dummy (1
                           ;; . 1), otherwise it would be set to the
                           ;; whole buffer, which is not what we want.
-                          `((,(point-min) . ,(point-min))))))))))))
+                          `((,(point-max) . ,(point-max))))))))))))

Running 1 tests (2023-09-24 11:52:17-0500, selector ‘t’)
Test elixir-ts-mode-test-indentation backtrace:
  signal(ert-test-failed (("Mismatch in test \"Basic modules\", file /
  ert-fail(("Mismatch in test \"Basic modules\", file /home/jm/src/ema
  ert-test--erts-test(((dummy . t) (code)) "/home/jm/src/emacs/test/li
  ert-test-erts-file("/home/jm/src/emacs/test/lisp/progmodes/elixir-ts
  (closure (t) nil (let ((value-4 (gensym "ert-form-evaluation-aborted
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name elixir-ts-mode-test-indentation :docu
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests [#s(ert-test 
  ert-run-tests(t #f(compiled-function (event-type &rest event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-l" "ert" "-l" "/home/jm/src/emacs/lisp/progmodes/e
  command-line()
  normal-top-level()
Test elixir-ts-mode-test-indentation condition:
    (ert-test-failed
     ("Mismatch in test \"Basic modules\", file /home/jm/src/emacs/test/lisp/progmodes/elixir-ts-mode-resources/indent.erts"
      #(
	"  defmodule Foobar do\n    def bar() do\n      \"one\"\n    end\n  end\n"
	0 65 (fontified nil))
      "defmodule Foobar do\n  def bar() do\n    \"one\"\n  end\nend\n"))
   FAILED  1/1  elixir-ts-mode-test-indentation (0.053512 sec) at ../../src/emacs/test/lisp/progmodes/elixir-ts-mode-tests.el:26

Ran 1 tests, 0 results as expected, 1 unexpected (2023-09-24 11:52:17-0500, 0.118489 sec)

1 unexpected results:
   FAILED  elixir-ts-mode-test-indentation

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

From: Yuan Fu <casouri <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66183 <at> debbugs.gnu.org
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Sun, 24 Sep 2023 20:12:48 -0700

[Message part 1 (text/plain, inline)]

> 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 <at> 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 need to adjust it but the idea is there.

With the new language-at-point definition, treesit-language-at can return the correct language, and the test passes again.

Yuan

[example.diff (application/octet-stream, attachment)]

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

From: john muhl <jm <at> pub.pink>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Wilhelm H Kirschbaum <wkirschbaum <at> gmail.com>, 66183 <at> debbugs.gnu.org
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Mon, 25 Sep 2023 11:01:57 -0500

Yuan Fu <casouri <at> 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 <at> 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
> need to adjust it but the idea is there.

Thanks for checking. Actually I was just looking at why the tests were
failing but now see that I forgot to include the elixir mode maintainer.

> With the new language-at-point definition, treesit-language-at can
> return the correct language, and the test passes again.

Wilhelm could you have a look?

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66183 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Tue, 26 Sep 2023 08:18:10 +0200

[Message part 1 (text/plain, inline)]

On Mon, Sep 25, 2023 at 9:04 PM john muhl <jm <at> pub.pink> wrote:

> Yuan Fu <casouri <at> gmail.com> writes:
>
> > With the new language-at-point definition, treesit-language-at can
> > return the correct language, and the test passes again.
>
> Wilhelm could you have a look?
>

 I will have a look later today.

[Message part 2 (text/html, inline)]

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 66183 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org, john muhl <jm <at> pub.pink>
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Tue, 26 Sep 2023 18:30:37 +0200

Yuan Fu <casouri <at> 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 <at> 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.

> need to adjust it but the idea is there.
>
> With the new language-at-point definition, treesit-language-at 
> can
> return the correct language, and the test passes again.
>
> Yuan
>
> [2. text/x-patch; example.diff]...

This seems to work if you set named on: treesit-node-prev-sibling,
otherwise it just tries to match the \"\"\" against H or F.

  (let* ((node (treesit-node-at point 'elixir)))
    (if (and (equal (treesit-node-type node) "quoted_content")
             (string-match-p
              (rx bos (or "H" "F") eos)
-              (treesit-node-text (treesit-node-prev-sibling 
              node))))
+              (treesit-node-text (treesit-node-prev-sibling node 
t))))
        'heex
      'elixir)))

I will spend some time in the next couple of hours to catch up to 
all
the changes.

Wilhelm

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

From: Yuan Fu <casouri <at> gmail.com>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: 66183 <at> debbugs.gnu.org, Bug Report Emacs <bug-gnu-emacs <at> gnu.org>,
 john muhl <jm <at> pub.pink>
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Tue, 26 Sep 2023 11:00:23 -0700

> On Sep 26, 2023, at 9:30 AM, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> wrote:
> 
> 
> Yuan Fu <casouri <at> 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 <at> 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.

> 
>> need to adjust it but the idea is there.
>> 
>> With the new language-at-point definition, treesit-language-at can
>> return the correct language, and the test passes again.
>> 
>> Yuan
>> 
>> [2. text/x-patch; example.diff]...
> 
> This seems to work if you set named on: treesit-node-prev-sibling,
> otherwise it just tries to match the \"\"\" against H or F.
> 
>  (let* ((node (treesit-node-at point 'elixir)))
>    (if (and (equal (treesit-node-type node) "quoted_content")
>             (string-match-p
>              (rx bos (or "H" "F") eos)
> -              (treesit-node-text (treesit-node-prev-sibling               node))))
> +              (treesit-node-text (treesit-node-prev-sibling node t))))
>        'heex
>      'elixir)))
> 
> I will spend some time in the next couple of hours to catch up to all
> the changes.

Ah, right. I’ll leave the specifics to you. As long as the language is derived from the node at point rather than parser range, it will be fine. Also, there’s no rush.

Yuan

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 66183 <at> debbugs.gnu.org, Bug Report Emacs <bug-gnu-emacs <at> gnu.org>,
 john muhl <jm <at> pub.pink>
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Tue, 26 Sep 2023 22:26:11 +0200

[Message part 1 (text/plain, inline)]

>>> need to adjust it but the idea is there.
>>> 
>>> With the new language-at-point definition, treesit-language-at 
>>> can
>>> return the correct language, and the test passes again.
>>> 
>>> Yuan
>>> 
>>> [2. text/x-patch; example.diff]...
>> 
>> This seems to work if you set named on: 
>> treesit-node-prev-sibling,
>> otherwise it just tries to match the \"\"\" against H or F.
>> 
>>  (let* ((node (treesit-node-at point 'elixir)))
>>    (if (and (equal (treesit-node-type node) "quoted_content")
>>             (string-match-p
>>              (rx bos (or "H" "F") eos)
>> -              (treesit-node-text (treesit-node-prev-sibling 
>> node))))
>> +              (treesit-node-text (treesit-node-prev-sibling 
>> node t))))
>>        'heex
>>      'elixir)))
>> 
>> I will spend some time in the next couple of hours to catch up 
>> to all
>> the changes.
>
> Ah, right. I’ll leave the specifics to you. As long as the 
> language is derived from the node at point rather than parser 
> range, it will be fine. Also, there’s no rush.
>

Hi Yuan,

With the new changes I had to update some indentation rules as 
well.
The following patch was tested against a couple of elixir files.

There is another indentation issue with HEEx embeds, but think its
unrelated to this issue and will have a look this weekend.

[0001-Fix-treesit-langauge-at-point-for-elixir-ts-mode.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Wilhelm

Message #37 received at 66183-done <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Bug Report Emacs <bug-gnu-emacs <at> gnu.org>, john muhl <jm <at> pub.pink>,
 66183-done <at> debbugs.gnu.org
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Tue, 26 Sep 2023 23:46:13 -0700

[Message part 1 (text/plain, inline)]

> On Sep 26, 2023, at 1:26 PM, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> wrote:
> 
>>>> need to adjust it but the idea is there.
>>>> With the new language-at-point definition, treesit-language-at can
>>>> return the correct language, and the test passes again.
>>>> Yuan
>>>> [2. text/x-patch; example.diff]...
>>> This seems to work if you set named on: treesit-node-prev-sibling,
>>> otherwise it just tries to match the \"\"\" against H or F.
>>> (let* ((node (treesit-node-at point 'elixir)))
>>>   (if (and (equal (treesit-node-type node) "quoted_content")
>>>            (string-match-p
>>>             (rx bos (or "H" "F") eos)
>>> -              (treesit-node-text (treesit-node-prev-sibling node))))
>>> +              (treesit-node-text (treesit-node-prev-sibling node t))))
>>>       'heex
>>>     'elixir)))
>>> I will spend some time in the next couple of hours to catch up to all
>>> the changes.
>> 
>> Ah, right. I’ll leave the specifics to you. As long as the language is derived from the node at point rather than parser range, it will be fine. Also, there’s no rush.
>> 
> 
> Hi Yuan,
> 
> With the new changes I had to update some indentation rules as well.
> The following patch was tested against a couple of elixir files.
> 
> There is another indentation issue with HEEx embeds, but think its
> unrelated to this issue and will have a look this weekend.
> 

[0001-Fix-treesit-langauge-at-point-for-elixir-ts-mode.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

> 
> Wilhelm

Thanks. I made some minor change and pushed to master.

Yuan

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Bug Report Emacs <bug-gnu-emacs <at> gnu.org>, john muhl <jm <at> pub.pink>,
 66183-done <at> debbugs.gnu.org
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Wed, 27 Sep 2023 09:17:51 +0200

Yuan Fu <casouri <at> gmail.com> writes:

>> On Sep 26, 2023, at 1:26 PM, Wilhelm Kirschbaum 
>> <wkirschbaum <at> gmail.com> wrote:
>> 
>>>>> need to adjust it but the idea is there.
>>>>> With the new language-at-point definition, 
>>>>> treesit-language-at can
>>>>> return the correct language, and the test passes again.
>>>>> Yuan
>>>>> [2. text/x-patch; example.diff]...
>>>> This seems to work if you set named on: 
>>>> treesit-node-prev-sibling,
>>>> otherwise it just tries to match the \"\"\" against H or F.
>>>> (let* ((node (treesit-node-at point 'elixir)))
>>>>   (if (and (equal (treesit-node-type node) "quoted_content")
>>>>            (string-match-p
>>>>             (rx bos (or "H" "F") eos)
>>>> -              (treesit-node-text (treesit-node-prev-sibling 
>>>> node))))
>>>> +              (treesit-node-text (treesit-node-prev-sibling 
>>>> node t))))
>>>>       'heex
>>>>     'elixir)))
>>>> I will spend some time in the next couple of hours to catch 
>>>> up to all
>>>> the changes.
>>> 
>>> Ah, right. I’ll leave the specifics to you. As long as the 
>>> language
>>> is derived from the node at point rather than parser range, it 
>>> will
>>> be fine. Also, there’s no rush.
>>> 
>> 
>> Hi Yuan,
>> 
>> With the new changes I had to update some indentation rules as 
>> well.
>> The following patch was tested against a couple of elixir 
>> files.
>> 
>> There is another indentation issue with HEEx embeds, but think 
>> its
>> unrelated to this issue and will have a look this weekend.
>> 
>
> [2. text/x-patch; 
> 0001-Fix-treesit-langauge-at-point-for-elixir-ts-mode.patch]...
>
>> 
>> Wilhelm
>
> Thanks. I made some minor change and pushed to master.
>
> Yuan

Fantastic, thanks!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: wkirschbaum <at> gmail.com, 66183 <at> debbugs.gnu.org, jm <at> pub.pink
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Fri, 29 Sep 2023 14:14:44 +0300

> Cc: 66183 <at> debbugs.gnu.org, jm <at> pub.pink
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Tue, 26 Sep 2023 11:00:23 -0700
> 
> > On Sep 26, 2023, at 9:30 AM, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> wrote:
> > 
> > 
> > Yuan Fu <casouri <at> 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 <at> 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?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: casouri <at> gmail.com
Cc: wkirschbaum <at> gmail.com, 66183 <at> debbugs.gnu.org, jm <at> pub.pink
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Thu, 05 Oct 2023 10:18:01 +0300

Ping!

> Cc: wkirschbaum <at> gmail.com, 66183 <at> debbugs.gnu.org, jm <at> pub.pink
> Date: Fri, 29 Sep 2023 14:14:44 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Cc: 66183 <at> debbugs.gnu.org, jm <at> pub.pink
> > From: Yuan Fu <casouri <at> gmail.com>
> > Date: Tue, 26 Sep 2023 11:00:23 -0700
> > 
> > > On Sep 26, 2023, at 9:30 AM, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> wrote:
> > > 
> > > 
> > > Yuan Fu <casouri <at> 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 <at> 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?
> 
> 
> 
> 

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66183 <at> debbugs.gnu.org, casouri <at> gmail.com, jm <at> pub.pink
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Sat, 07 Oct 2023 10:44:12 +0200

>> > 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?
>> 

I don't see why not, because the elixir-ts-mode patch works on 
29.1 as well. 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: 66183 <at> debbugs.gnu.org, casouri <at> gmail.com, jm <at> pub.pink
Subject: Re: bug#66183: elixir-ts-mode test failure
Date: Sat, 07 Oct 2023 12:05:01 +0300

> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
> Cc: casouri <at> gmail.com, 66183 <at> debbugs.gnu.org, jm <at> pub.pink
> Date: Sat, 07 Oct 2023 10:44:12 +0200
> 
> 
> 
> >> > 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?
> >> 
> 
> I don't see why not, because the elixir-ts-mode patch works on 
> 29.1 as well. 

Done.

Previous Next

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