* 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-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
* Call for volunteers: add tree-sitter support to major modes
@ 2022-10-09 9:03 Eli Zaretskii
2022-10-09 12:26 ` Philip Kaludercic
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-10-09 9:03 UTC (permalink / raw)
To: emacs-devel
The Emacs 29 release branch is planned to be cut in about 1.5 months,
and we want tree-sitter support to be in Emacs 29. The Emacs Git
repository has a feature branch that integrates tree-sitter with
Emacs. That branch is being prepared for landing on master. However,
currently there's only one major-mode which can use tree-sitter
support on the branch: Python mode. We need to add tree-sitter
integration to more major modes, so that Emacs 29 could have
reasonably useful tree-sitter support options in at least the popular
major modes.
This is a call for volunteers to work on adding tree-sitter support to
major modes beyond Python, and on improving the existing support in
Python mode.
Some of the popular major modes for which we would like to see
tree-sitter support in Emacs 29 are:
c-mode
c++-mode
emacs-lisp-mode
js-mode
js-json-mode
ruby-mode
shell-script-mode
We probably won't have all of them by Emacs 29, but we hope to have at
least some.
So if you are interested in enhancing your favorite major-mode with
tree-sitter support, and by doing that making Emacs 29 much better,
please checkout the feature/tree-sitter branch, and start working on
some mode(s). Tree-sitter support for a major-mode should include
enhancement of one or more of the following Emacs features:
- font-lock
- indentation
- navigation (beginning-of-defun-function etc.)
- imenu
- which-func
- thing-at-point
We think that font-lock is the absolute minimum, followed by
indentation.
To help with this effort, Yuan Fu, who did most of the development on
this feature branch, wrote a document with guidance notes which aim to
help you implement tree-sitter support for the above features. You
will find that document and some other helpful documentation in the
admin/notes/tree-sitter directory and its subdirectories on the
branch. That directory also includes scripts for easy compilation of
tree-sitter language modules (which you will need to download from the
tree-sitter site).
We hope that the existing support for Python can serve as working
example of how to add tree-sitter support for other major modes, and
together with the guidance document it will allow you to add support
for more modes with minimum effort. Don't hesitate to ask questions
if something is unclear or you need more advice.
We hope volunteers will step forward in time to make tree-sitter
integration in Emacs 29 functional and useful. To avoid waste of
effort, please announce here on which major mode(s) you decided to
work.
Thanks in advance.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Call for volunteers: add tree-sitter support to major modes
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
0 siblings, 1 reply; 14+ messages in thread
From: Philip Kaludercic @ 2022-10-09 12:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Yuan Fu
Eli Zaretskii <eliz@gnu.org> writes:
> Some of the popular major modes for which we would like to see
> tree-sitter support in Emacs 29 are:
>
[...]
> emacs-lisp-mode
How much of a priority is using tree sitter for Emacs Lisp? It appears
that this[0] is the grammar implementation, and it currently doesn't
support the following:
Autoload cookies
Definitions (e.g. defun, defvar, defmacro)
As far as I understand, this means that from your list of enhanced
features, the following will either be restricted or not work at all:
- font-lock
- indentation
- imenu
- which-func
Also, when taking a look at the current implementation for Python[1][2],
I cannot but wonder if a few high-level functions/macros should be added
first to make it easier.
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...
[0] https://github.com/Wilfred/tree-sitter-elisp
[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/python.el?h=feature/tree-sitter#n953
[2] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/python.el?h=feature/tree-sitter#n5324
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Call for volunteers: add tree-sitter support to major modes
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
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-10-09 13:25 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel, casouri
> 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
>
> > emacs-lisp-mode
>
> How much of a priority is using tree sitter for Emacs Lisp? It appears
> that this[0] is the grammar implementation, and it currently doesn't
> support the following:
>
> Autoload cookies
> Definitions (e.g. defun, defvar, defmacro)
>
> As far as I understand, this means that from your list of enhanced
> features, the following will either be restricted or not work at all:
>
> - font-lock
> - indentation
> - imenu
> - which-func
If emacs-lisp-mode cannot be reasonably supported, we can omit it for
now.
> Also, when taking a look at the current implementation for Python[1][2],
> I cannot but wonder if a few high-level functions/macros should be added
> first to make it easier.
>
> 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...
>
> [0] https://github.com/Wilfred/tree-sitter-elisp
> [1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/python.el?h=feature/tree-sitter#n953
> [2] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/python.el?h=feature/tree-sitter#n5324
That's a separate discussion, so please start a new thread.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter (was: Call for volunteers: add tree-sitter support to major modes)
2022-10-09 13:25 ` Eli Zaretskii
@ 2022-10-10 6:39 ` Eli Zaretskii
2022-10-10 6:46 ` Theodor Thornhill
2022-10-10 6:59 ` Lars Ingebrigtsen
0 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2022-10-10 6:39 UTC (permalink / raw)
To: philipk; +Cc: emacs-devel, casouri
> 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.
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter (was: Call for volunteers: add tree-sitter support to major modes)
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 6:59 ` Lars Ingebrigtsen
1 sibling, 1 reply; 14+ messages in thread
From: Theodor Thornhill @ 2022-10-10 6:46 UTC (permalink / raw)
To: Eli Zaretskii, philipk; +Cc: emacs-devel, casouri
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.
>
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Turing on tree-sitter (was: Call for volunteers: add tree-sitter support to major modes)
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
0 siblings, 1 reply; 14+ messages in thread
From: Yuan Fu @ 2022-10-10 6:54 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Eli Zaretskii, philipk, emacs-devel
> 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.
>>
>> 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?
Yuan
^ 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 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
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-11 7:50 Turing on tree-sitter Zhang Haijun
2022-10-11 19:56 ` Daniel Martín
-- strict thread matches above, loose matches on Subject: below --
2022-10-10 23:01 Drew Adams
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).