* Re: Turing on tree-sitter
2022-10-10 6:39 ` Turing on tree-sitter (was: Call for volunteers: add tree-sitter support to major modes) Eli Zaretskii
2022-10-10 6:46 ` Theodor Thornhill
@ 2022-10-10 6:59 ` Lars Ingebrigtsen
1 sibling, 0 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-10 6:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: philipk, emacs-devel, casouri
Eli Zaretskii <eliz@gnu.org> writes:
> But we could also have a global "turn on tree-sitter support in every
> mode that has it" option, which will turn this on for those modes
> which can be supported by tree-sitter, if the appropriate
> language-support library is installed.
Yes, a user option that's a (derived-)mode predicate would be nice for
this.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 6:54 ` Yuan Fu
@ 2022-10-10 7:26 ` Philip Kaludercic
2022-10-10 8:22 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Philip Kaludercic @ 2022-10-10 7:26 UTC (permalink / raw)
To: Yuan Fu; +Cc: Theodor Thornhill, Eli Zaretskii, emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Oct 9, 2022, at 11:46 PM, Theodor Thornhill <theo@thornhill.no> wrote:
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Date: Sun, 09 Oct 2022 16:25:17 +0300
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: emacs-devel@gnu.org, casouri@gmail.com
>>>>
>>>>> From: Philip Kaludercic <philipk@posteo.net>
>>>>> Cc: emacs-devel@gnu.org, Yuan Fu <casouri@gmail.com>
>>>>> Date: Sun, 09 Oct 2022 12:26:09 +0000
>>>>>
>>>>> One more thing, it looks like the usage of tree-sitter is enabled for
>>>>> python by toggling `python-use-tree-sitter'. Will every mode now have
>>>>> this kind of an option? I would hope not...
>>>>
>>>> That's a separate discussion, so please start a new thread.
>>>
>>> So here I am, starting that separate discussion.
Sorry, I missed the message.
>>> Since tree-sitter support is per-language, I do think it makes sense
>>> for each mode to have its tree-sitter support turned on separately.
>>> But we could also have a global "turn on tree-sitter support in every
>>> mode that has it" option, which will turn this on for those modes
>>> which can be supported by tree-sitter, if the appropriate
>>> language-support library is installed.
>>>
>>> Comments?
>>
>> +1 for this, but also keep the per-modes customs. Then we can eat the
>> cake and have it too.
>>
>> Such a mechanism can be made later, I think?
>>
>> Theo
>
> +1 for this, but also add a third possible value to per-mode customs
> that keeps tree-sitter always off for the mode. That way someone can
> enable tree-sitter for all but that mode. Are there precedents for
> such ternary variables? nil, t, and 'never?
Is there a reason we can't use a minor mode? Something like
(add-hook 'python-mode-hook #'treesit-mode)
or a list
(add-to-list 'treesit-modes 'python-mode)
?
> Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 7:26 ` Turing on tree-sitter Philip Kaludercic
@ 2022-10-10 8:22 ` Eli Zaretskii
2022-10-10 14:52 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-10-10 8:22 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: casouri, theo, emacs-devel
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Theodor Thornhill <theo@thornhill.no>, Eli Zaretskii <eliz@gnu.org>,
> emacs-devel@gnu.org
> Date: Mon, 10 Oct 2022 07:26:55 +0000
>
> > +1 for this, but also add a third possible value to per-mode customs
> > that keeps tree-sitter always off for the mode. That way someone can
> > enable tree-sitter for all but that mode. Are there precedents for
> > such ternary variables? nil, t, and 'never?
>
> Is there a reason we can't use a minor mode? Something like
>
> (add-hook 'python-mode-hook #'treesit-mode)
>
> or a list
>
> (add-to-list 'treesit-modes 'python-mode)
>
> ?
We could, if a minor mode is justified. When this was previously
brought up, someone said the justification for a minor mode was too
weak in most cases. But maybe we should revisit that idea.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 8:22 ` Eli Zaretskii
@ 2022-10-10 14:52 ` Stefan Monnier
2022-10-10 15:29 ` Daniel Martín
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Stefan Monnier @ 2022-10-10 14:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Philip Kaludercic, casouri, theo, emacs-devel
>> Is there a reason we can't use a minor mode? Something like
>>
>> (add-hook 'python-mode-hook #'treesit-mode)
>>
>> or a list
>>
>> (add-to-list 'treesit-modes 'python-mode)
>>
>> ?
>
> We could, if a minor mode is justified. When this was previously
> brought up, someone said the justification for a minor mode was too
> weak in most cases. But maybe we should revisit that idea.
I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
make a lot of sense, from a user's perspective. This way they don't
have to hunt for the name of the boolean variable that their mode
decided to use to control the use of treesitter: all modes use the same
boolean variable called `treesit-mode`.
Then again, to me a minor mode is something so cheap that the idea that
"justification for a minor mode was too weak" is rather hard to grasp.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 14:52 ` Stefan Monnier
@ 2022-10-10 15:29 ` Daniel Martín
2022-10-10 16:04 ` Eli Zaretskii
2022-10-10 16:06 ` Yuan Fu
2 siblings, 0 replies; 14+ messages in thread
From: Daniel Martín @ 2022-10-10 15:29 UTC (permalink / raw)
To: Stefan Monnier
Cc: Eli Zaretskii, Philip Kaludercic, casouri, theo, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
> make a lot of sense, from a user's perspective. This way they don't
> have to hunt for the name of the boolean variable that their mode
> decided to use to control the use of treesitter: all modes use the same
> boolean variable called `treesit-mode`.
I agree. A buffer-local and a global minor modes for Tree-sitter would
feel more natural to users.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 14:52 ` Stefan Monnier
2022-10-10 15:29 ` Daniel Martín
@ 2022-10-10 16:04 ` Eli Zaretskii
2022-10-10 16:06 ` Yuan Fu
2 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2022-10-10 16:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: philipk, casouri, theo, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Philip Kaludercic <philipk@posteo.net>, casouri@gmail.com,
> theo@thornhill.no, emacs-devel@gnu.org
> Date: Mon, 10 Oct 2022 10:52:21 -0400
>
> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
> make a lot of sense, from a user's perspective. This way they don't
> have to hunt for the name of the boolean variable that their mode
> decided to use to control the use of treesitter: all modes use the same
> boolean variable called `treesit-mode`.
>
> Then again, to me a minor mode is something so cheap that the idea that
> "justification for a minor mode was too weak" is rather hard to grasp.
That's okay, I was the one who proposed a minor mode to begin with...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 14:52 ` Stefan Monnier
2022-10-10 15:29 ` Daniel Martín
2022-10-10 16:04 ` Eli Zaretskii
@ 2022-10-10 16:06 ` Yuan Fu
2022-10-10 16:24 ` Philip Kaludercic
2 siblings, 1 reply; 14+ messages in thread
From: Yuan Fu @ 2022-10-10 16:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Philip Kaludercic, theo, emacs-devel
> On Oct 10, 2022, at 7:52 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> Is there a reason we can't use a minor mode? Something like
>>>
>>> (add-hook 'python-mode-hook #'treesit-mode)
>>>
>>> or a list
>>>
>>> (add-to-list 'treesit-modes 'python-mode)
>>>
>>> ?
>>
>> We could, if a minor mode is justified. When this was previously
>> brought up, someone said the justification for a minor mode was too
>> weak in most cases. But maybe we should revisit that idea.
>
> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
> make a lot of sense, from a user's perspective. This way they don't
> have to hunt for the name of the boolean variable that their mode
> decided to use to control the use of treesitter: all modes use the same
> boolean variable called `treesit-mode`.
Usually users set buffer-local variables in a major mode hook, which runs after the major mode is loaded, no? But major modes need to know whether to use tree-sitter up-front.
I don’t think xxx-mode-use-tree-sitter would be hard to find if every mode uses this pattern. Though now we are discussing adding separate major modes which wouldn’t use this variable. I think that indeed could be confusing. (How do I know if xxx language uses xxx-mode-use-tree-sitter or a separate major mode xxx-tree-sitter-mode?)
>
> Then again, to me a minor mode is something so cheap that the idea that
> "justification for a minor mode was too weak" is rather hard to grasp.
I don’t think there is too much problem using minor modes, but minor modes wouldn’t fit very well with separate major modes. IMO it would be weird if turning on tree-sitter-mode changes the major mode.
Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 16:06 ` Yuan Fu
@ 2022-10-10 16:24 ` Philip Kaludercic
2022-10-10 16:54 ` Yuan Fu
0 siblings, 1 reply; 14+ messages in thread
From: Philip Kaludercic @ 2022-10-10 16:24 UTC (permalink / raw)
To: Yuan Fu; +Cc: Stefan Monnier, Eli Zaretskii, theo, emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>> On Oct 10, 2022, at 7:52 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>>>> Is there a reason we can't use a minor mode? Something like
>>>>
>>>> (add-hook 'python-mode-hook #'treesit-mode)
>>>>
>>>> or a list
>>>>
>>>> (add-to-list 'treesit-modes 'python-mode)
>>>>
>>>> ?
>>>
>>> We could, if a minor mode is justified. When this was previously
>>> brought up, someone said the justification for a minor mode was too
>>> weak in most cases. But maybe we should revisit that idea.
>>
>> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
>> make a lot of sense, from a user's perspective. This way they don't
>> have to hunt for the name of the boolean variable that their mode
>> decided to use to control the use of treesitter: all modes use the same
>> boolean variable called `treesit-mode`.
>
> Usually users set buffer-local variables in a major mode hook, which
> runs after the major mode is loaded, no? But major modes need to know
> whether to use tree-sitter up-front.
What if the hook is a noop and the mode definition just checks if the
function is a member? Or is there no way to re-fontify a buffer?
> I don’t think xxx-mode-use-tree-sitter would be hard to find if every
> mode uses this pattern. Though now we are discussing adding separate
> major modes which wouldn’t use this variable. I think that indeed
> could be confusing. (How do I know if xxx language uses
> xxx-mode-use-tree-sitter or a separate major mode
> xxx-tree-sitter-mode?)
I think the issue here is not so much discoverability, but consistency.
Having to a different option for every mode can get annoying and is
difficult to automate. It is also unnecessarily decentralised. That is
why I think that having a single list like `treesit-modes' (by whatever
name) would be nice to have. Using the easy customisation interface
you'd represent it as a set/radio menu where you get a list of supported
languages you can tick.
>> Then again, to me a minor mode is something so cheap that the idea that
>> "justification for a minor mode was too weak" is rather hard to grasp.
>
> I don’t think there is too much problem using minor modes, but minor
> modes wouldn’t fit very well with separate major modes. IMO it would
> be weird if turning on tree-sitter-mode changes the major mode.
I don't get why a `tree-sitter-mode' should change the major mode?
> Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 16:24 ` Philip Kaludercic
@ 2022-10-10 16:54 ` Yuan Fu
2022-10-10 17:05 ` Theodor Thornhill
2022-10-10 22:54 ` Daniel Martín
0 siblings, 2 replies; 14+ messages in thread
From: Yuan Fu @ 2022-10-10 16:54 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Stefan Monnier, Eli Zaretskii, Theodor Thornhill, emacs-devel
> On Oct 10, 2022, at 9:24 AM, Philip Kaludercic <philipk@posteo.net> wrote:
>
> Yuan Fu <casouri@gmail.com> writes:
>
>>> On Oct 10, 2022, at 7:52 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>
>>>>> Is there a reason we can't use a minor mode? Something like
>>>>>
>>>>> (add-hook 'python-mode-hook #'treesit-mode)
>>>>>
>>>>> or a list
>>>>>
>>>>> (add-to-list 'treesit-modes 'python-mode)
>>>>>
>>>>> ?
>>>>
>>>> We could, if a minor mode is justified. When this was previously
>>>> brought up, someone said the justification for a minor mode was too
>>>> weak in most cases. But maybe we should revisit that idea.
>>>
>>> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
>>> make a lot of sense, from a user's perspective. This way they don't
>>> have to hunt for the name of the boolean variable that their mode
>>> decided to use to control the use of treesitter: all modes use the same
>>> boolean variable called `treesit-mode`.
>>
>> Usually users set buffer-local variables in a major mode hook, which
>> runs after the major mode is loaded, no? But major modes need to know
>> whether to use tree-sitter up-front.
>
> What if the hook is a noop and the mode definition just checks if the
> function is a member? Or is there no way to re-fontify a buffer?
IMO that’s a bit hacky, we have plenty better options.
>
>> I don’t think xxx-mode-use-tree-sitter would be hard to find if every
>> mode uses this pattern. Though now we are discussing adding separate
>> major modes which wouldn’t use this variable. I think that indeed
>> could be confusing. (How do I know if xxx language uses
>> xxx-mode-use-tree-sitter or a separate major mode
>> xxx-tree-sitter-mode?)
>
> I think the issue here is not so much discoverability, but consistency.
> Having to a different option for every mode can get annoying and is
> difficult to automate. It is also unnecessarily decentralised. That is
> why I think that having a single list like `treesit-modes' (by whatever
> name) would be nice to have. Using the easy customisation interface
> you'd represent it as a set/radio menu where you get a list of supported
> languages you can tick.
That’s nice, but it wouldn’t make much sense to add A to the list when A-mode doesn’t actually support tree-sitter. I think of tree-sitter as something at major mode level.
>
>>> Then again, to me a minor mode is something so cheap that the idea that
>>> "justification for a minor mode was too weak" is rather hard to grasp.
>>
>> I don’t think there is too much problem using minor modes, but minor
>> modes wouldn’t fit very well with separate major modes. IMO it would
>> be weird if turning on tree-sitter-mode changes the major mode.
>
> I don't get why a `tree-sitter-mode' should change the major mode?
My bad, I thought Theodor was saying he would add separate major modes alongside non-tree-sitter major modes for the same language. Reading his message I think he is only adding the tree-sitter powered mode into core and leaving the non-tree-sitter version out.
So IIUC we will have (a) major modes that supports both tree-sitter and non-tree-sitter, and (b) major modes that require tree-sitter to work.
Again, a M-x treesit-enable in a mode that requires tree-sitter to work doesn’t make much sense. I think having individual major-mode level toggle variables and a global toggle variable is conceptually more fit?
Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 16:54 ` Yuan Fu
@ 2022-10-10 17:05 ` Theodor Thornhill
2022-10-10 22:54 ` Daniel Martín
1 sibling, 0 replies; 14+ messages in thread
From: Theodor Thornhill @ 2022-10-10 17:05 UTC (permalink / raw)
To: Yuan Fu, Philip Kaludercic; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel
>
>My bad, I thought Theodor was saying he would add separate major modes alongside non-tree-sitter major modes for the same language. Reading his message I think he is only adding the tree-sitter powered mode into core and leaving the non-tree-sitter version out.
>
>So IIUC we will have (a) major modes that supports both tree-sitter and non-tree-sitter, and (b) major modes that require tree-sitter to work.
>
>Again, a M-x treesit-enable in a mode that requires tree-sitter to work doesn’t make much sense. I think having individual major-mode level toggle variables and a global toggle variable is conceptually more fit?
>
Agreed!
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-10 16:54 ` Yuan Fu
2022-10-10 17:05 ` Theodor Thornhill
@ 2022-10-10 22:54 ` Daniel Martín
1 sibling, 0 replies; 14+ messages in thread
From: Daniel Martín @ 2022-10-10 22:54 UTC (permalink / raw)
To: Yuan Fu
Cc: Philip Kaludercic, Stefan Monnier, Eli Zaretskii,
Theodor Thornhill, emacs-devel
Yuan Fu <casouri@gmail.com> writes:
>
> Again, a M-x treesit-enable in a mode that requires tree-sitter to
> work doesn’t make much sense. I think having individual major-mode
> level toggle variables and a global toggle variable is conceptually
> more fit?
>
Right now, changing the major mode variables to enable/disable
Tree-sitter requires a restart of the major mode to have Tree-sitter
manage the buffer. I think making the variables a command/minor mode so
that all this preparatory work is done for users would be useful.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
@ 2022-10-10 23:01 Drew Adams
0 siblings, 0 replies; 14+ messages in thread
From: Drew Adams @ 2022-10-10 23:01 UTC (permalink / raw)
To: Daniel Martín, Yuan Fu
Cc: Philip Kaludercic, Stefan Monnier, Eli Zaretskii,
Theodor Thornhill, emacs-devel@gnu.org
(Looking to see what Turing has to say
about tree-sitter...)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
@ 2022-10-11 7:50 Zhang Haijun
2022-10-11 19:56 ` Daniel Martín
0 siblings, 1 reply; 14+ messages in thread
From: Zhang Haijun @ 2022-10-11 7:50 UTC (permalink / raw)
To: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 130 bytes --]
Maybe there will be another one like the tree-sitter in the future? Then there will be 3 or more choices for every major-mode?
[-- Attachment #2: Type: text/html, Size: 1775 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter
2022-10-11 7:50 Zhang Haijun
@ 2022-10-11 19:56 ` Daniel Martín
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Martín @ 2022-10-11 19:56 UTC (permalink / raw)
To: Zhang Haijun; +Cc: emacs-devel@gnu.org
Zhang Haijun <ccsmile2008@outlook.com> writes:
> Maybe there will be another one like the tree-sitter in the future? Then there will be 3 or more choices for every major-mode?
Yes, I think a centralized way to enable it would reduce the
proliferation of variables (not only per major mode, I expect other
specialized modes to want to use Tree-sitter as well).
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-10-11 19:56 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-10 23:01 Turing on tree-sitter Drew Adams
-- strict thread matches above, loose matches on Subject: below --
2022-10-11 7:50 Zhang Haijun
2022-10-11 19:56 ` Daniel Martín
2022-10-09 9:03 Call for volunteers: add tree-sitter support to major modes Eli Zaretskii
2022-10-09 12:26 ` Philip Kaludercic
2022-10-09 13:25 ` Eli Zaretskii
2022-10-10 6:39 ` Turing on tree-sitter (was: Call for volunteers: add tree-sitter support to major modes) Eli Zaretskii
2022-10-10 6:46 ` Theodor Thornhill
2022-10-10 6:54 ` Yuan Fu
2022-10-10 7:26 ` Turing on tree-sitter Philip Kaludercic
2022-10-10 8:22 ` Eli Zaretskii
2022-10-10 14:52 ` Stefan Monnier
2022-10-10 15:29 ` Daniel Martín
2022-10-10 16:04 ` Eli Zaretskii
2022-10-10 16:06 ` Yuan Fu
2022-10-10 16:24 ` Philip Kaludercic
2022-10-10 16:54 ` Yuan Fu
2022-10-10 17:05 ` Theodor Thornhill
2022-10-10 22:54 ` Daniel Martín
2022-10-10 6:59 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).