tree-sitter and emacs-devel

tree-sitter and emacs-devel

[Stefan Monnier]

FWIW, re-reading over the discussions around emacs-tree-sitter of the
last few days, I must say I'm not proud: if I were a contributor to
tree-sitter and/or emacs-tree-sitter, all this squabbling over how
tree-sitter "should" work (from people who have not been involved in
either of those and don't have any practical experience of how it
performs or why it's designed that way) would make me run away screaming
and promising myself never to come back to that mad house.

The worst part for me is to realize that I was mostly on the side of the
backseat drivers :-(


        Stefan

Re: tree-sitter and emacs-devel

[Jorge Javier Araya Navarro]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

I'll stick with emacs-devel anyway and keep contributing to
emacs-tree-sitter too jaja.

it is demoralizing indeed, but it is more not bringing Emacs to the XXI
century. We can do incremental changes after testing how this thing works
—not need to discuss what is and what is not a premature optimization—,
Emacs maintainers can help by making sure major GNU/Linux distributions
ship Emacs with dynamic module feature turned on so the work done on this
side can be rapidly adopted by the community; what's done wrong can be
revisited later.

El jue., 2 de abril de 2020 10:02, Stefan Monnier <monnier@iro.umontreal.ca>
escribió:

> FWIW, re-reading over the discussions around emacs-tree-sitter of the
> last few days, I must say I'm not proud: if I were a contributor to
> tree-sitter and/or emacs-tree-sitter, all this squabbling over how
> tree-sitter "should" work (from people who have not been involved in
> either of those and don't have any practical experience of how it
> performs or why it's designed that way) would make me run away screaming
> and promising myself never to come back to that mad house.
>
> The worst part for me is to realize that I was mostly on the side of the
> backseat drivers :-(
>
>
>         Stefan
>
>
>

[-- Attachment #2: Type: text/html, Size: 1642 bytes --]

Re: tree-sitter and emacs-devel

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 02 Apr 2020 12:01:38 -0400
> 
> FWIW, re-reading over the discussions around emacs-tree-sitter of the
> last few days, I must say I'm not proud: if I were a contributor to
> tree-sitter and/or emacs-tree-sitter, all this squabbling over how
> tree-sitter "should" work (from people who have not been involved in
> either of those and don't have any practical experience of how it
> performs or why it's designed that way) would make me run away screaming
> and promising myself never to come back to that mad house.

I actually think that this discussion brought up several important
issues and topics (and I don't mean my own messages) that should be
considered if such technology is to become part of Emacs (and I very
much hope it will).  Yes, there's quite a bit of noise, as in any
discussion, but that's inevitable.  The alternative is to invent your
own wheel each time, and make all the same mistakes.

I remember a similar situation on the emacs-bidi mailing list 15 years
ago when the bidirectional editing support for Emacs was just a pipe
dream.  Many of the ideas expressed there I tossed, but some are now
part of our implementation, and I'm glad I had the opportunity to hear
them.  I'm also glad that Gerd Moellmann was there to provide his
perspective on what would and what wouldn't be viable, I would have
never arrived at the current design without his guidance, not without
making several grave mistakes anyway.

Re: tree-sitter and emacs-devel

[andres.ramirez]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca> Date: Thu, 02 Apr
>> 2020 12:01:38 -0400
>> 
>> FWIW, re-reading over the discussions around emacs-tree-sitter of
>> the last few days, I must say I'm not proud: if I were a
>> contributor to tree-sitter and/or emacs-tree-sitter, all this
>> squabbling over how tree-sitter "should" work (from people who have
>> not been involved in either of those and don't have any practical
>> experience of how it performs or why it's designed that way) would
>> make me run away screaming and promising myself never to come back
>> to that mad house.

Eli> I actually think that this discussion brought up several
Eli> important issues and topics (and I don't mean my own messages)
Eli> that should be considered if such technology is to become part of
Eli> Emacs (and I very much hope it will).  Yes, there's quite a bit
Eli> of noise, as in any discussion, but that's inevitable.  The
Eli> alternative is to invent your own wheel each time, and make all
Eli> the same mistakes.

Eli> I remember a similar situation on the emacs-bidi mailing list 15
Eli> years ago when the bidirectional editing support for Emacs was
Eli> just a pipe dream.  Many of the ideas expressed there I tossed,
Eli> but some are now part of our implementation, and I'm glad I had
Eli> the opportunity to hear them.  I'm also glad that Gerd Moellmann
Eli> was there to provide his perspective on what would and what
Eli> wouldn't be viable, I would have never arrived at the current
Eli> design without his guidance, not without making several grave
Eli> mistakes anyway.

+1

This discussion have bring me food for thought.

Re: tree-sitter and emacs-devel

[Jorge Javier Araya Navarro]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

It can and has for some, but at some point if the people discussing focus
too much around what is and is not an early optimization a wrong message
can be communicated, as it was pointed out in another thread that
maintainers won't help unless volunteers from third-party projects follow
to a T their demands.

P.S.: didn't notice this thread was titled paraphrasing the one I started
(tree-sitter and Emacs), I find funny I didn't notice until now.

El jue., 2 de abr. de 2020 a la(s) 11:08, andres.ramirez (
rrandresf@gmail.com) escribió:

> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Stefan Monnier <monnier@iro.umontreal.ca> Date: Thu, 02 Apr
> >> 2020 12:01:38 -0400
> >>
> >> FWIW, re-reading over the discussions around emacs-tree-sitter of
> >> the last few days, I must say I'm not proud: if I were a
> >> contributor to tree-sitter and/or emacs-tree-sitter, all this
> >> squabbling over how tree-sitter "should" work (from people who have
> >> not been involved in either of those and don't have any practical
> >> experience of how it performs or why it's designed that way) would
> >> make me run away screaming and promising myself never to come back
> >> to that mad house.
>
> Eli> I actually think that this discussion brought up several
> Eli> important issues and topics (and I don't mean my own messages)
> Eli> that should be considered if such technology is to become part of
> Eli> Emacs (and I very much hope it will).  Yes, there's quite a bit
> Eli> of noise, as in any discussion, but that's inevitable.  The
> Eli> alternative is to invent your own wheel each time, and make all
> Eli> the same mistakes.
>
> Eli> I remember a similar situation on the emacs-bidi mailing list 15
> Eli> years ago when the bidirectional editing support for Emacs was
> Eli> just a pipe dream.  Many of the ideas expressed there I tossed,
> Eli> but some are now part of our implementation, and I'm glad I had
> Eli> the opportunity to hear them.  I'm also glad that Gerd Moellmann
> Eli> was there to provide his perspective on what would and what
> Eli> wouldn't be viable, I would have never arrived at the current
> Eli> design without his guidance, not without making several grave
> Eli> mistakes anyway.
>
> +1
>
> This discussion have bring me food for thought.
>
>

[-- Attachment #2: Type: text/html, Size: 3214 bytes --]

Re: tree-sitter and emacs-devel

[Stefan Monnier]

> I remember a similar situation on the emacs-bidi mailing list 15 years
> ago when the bidirectional editing support for Emacs was just a pipe
> dream.

That was a completely different situation.  tree-sitter is very far from
a pipe dream (the initial Git commit dates back to 2013).


        Stefan

Re: tree-sitter and emacs-devel

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 03 Apr 2020 09:43:05 -0400
> Cc: emacs-devel@gnu.org
> 
> > I remember a similar situation on the emacs-bidi mailing list 15 years
> > ago when the bidirectional editing support for Emacs was just a pipe
> > dream.
> 
> That was a completely different situation.  tree-sitter is very far from
> a pipe dream (the initial Git commit dates back to 2013).

You may not remember it, but at the time I mentioned we had a working
prototype of bidi Emacs.  It was even demonstrated at a conference in
Japan in the year 2000.  So the situation is not really that
different.

Re: tree-sitter and emacs-devel

[Stefan Monnier]

>> > I remember a similar situation on the emacs-bidi mailing list 15 years
>> > ago when the bidirectional editing support for Emacs was just a pipe dream.
>> That was a completely different situation.  tree-sitter is very far from
>> a pipe dream (the initial Git commit dates back to 2013).
> You may not remember it, but at the time I mentioned we had a working
> prototype of bidi Emacs.  It was even demonstrated at a conference in
> Japan in the year 2000.  So the situation is not really that
> different.

But AFAIK noone here is planning to implement a new parser to *replace*
tree-sitter, so again, this is not a comparable situation at all.

In the LSP world, `tree-sitter` would be like an LSP server, and
`emacs-tree-sitter` would be like eglot.el.


        Stefan

Re: tree-sitter and emacs-devel

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Apr 2020 11:13:31 -0400
> 
> >> > I remember a similar situation on the emacs-bidi mailing list 15 years
> >> > ago when the bidirectional editing support for Emacs was just a pipe dream.
> >> That was a completely different situation.  tree-sitter is very far from
> >> a pipe dream (the initial Git commit dates back to 2013).
> > You may not remember it, but at the time I mentioned we had a working
> > prototype of bidi Emacs.  It was even demonstrated at a conference in
> > Japan in the year 2000.  So the situation is not really that
> > different.
> 
> But AFAIK noone here is planning to implement a new parser to *replace*
> tree-sitter

No one was planning to replace the bidi prototype back then, either.
(And I don't really see how this aspect could be relevant to this part
of the discussion.)

In general, I find it puzzling that you apparently say we shouldn't
try providing guidance to developers who are working on important
features.  Without us passing our knowledge and experience, how would
they learn from past mistakes? how will they avoid making some of
those mistakes time and again?  Our experience includes things we
tried and failed, it includes techniques we found to be expensive or
dangerous or non-scalable.  None of that is written anywhere except in
our memory, so the only way to pass that knowledge is to speak up
regarding which methods and algorithms should be preferred to others.
How can we help except by guidance based on that experience?  Are we
supposed to do the work ourselves, so that no one could say we are
acting as "backseat drivers"?

Re: tree-sitter and emacs-devel

[Stefan Monnier]

> In general, I find it puzzling that you apparently say we shouldn't
> try providing guidance to developers who are working on important
> features.

The discussion was supposedly about `emacs-tree-sitter` with people
working on `emacs-tree-sitter`, yet a lot of it ended up being about the
design of `tree-sitter` instead.


        Stefan

Re: tree-sitter and emacs-devel

[Tuấn-Anh Nguyễn]

On Thu, Apr 2, 2020 at 11:02 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> FWIW, re-reading over the discussions around emacs-tree-sitter of the
> last few days, I must say I'm not proud: if I were a contributor to
> tree-sitter and/or emacs-tree-sitter, all this squabbling over how
> tree-sitter "should" work (from people who have not been involved in
> either of those and don't have any practical experience of how it
> performs or why it's designed that way) would make me run away screaming
> and promising myself never to come back to that mad house.
>

For me personally, the discussions were ok, if a bit noisy. But yes, the
overall atmosphere/style can feel discouraging to newcomers.

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

Re: tree-sitter and emacs-devel

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For me personally, the discussions were ok, if a bit noisy. But yes, the
  > overall atmosphere/style can feel discouraging to newcomers.

Can you point to specific instances where it would have been useful
for people to speak differently?

Have you ead https://gnu.org/philosophy/kind-communication.html?
Do you see any instances where their advice might have helped make
the discussion easier and more appealing to join?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)