all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: tree-sitter and emacs-devel
Date: Sat, 04 Apr 2020 11:15:00 +0300	[thread overview]
Message-ID: <83pncnvf97.fsf@gnu.org> (raw)
In-Reply-To: <jwv4ku0li6y.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 03 Apr 2020 11:13:31 -0400)

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



  reply	other threads:[~2020-04-04  8:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 16:01 tree-sitter and emacs-devel Stefan Monnier
2020-04-02 16:12 ` Jorge Javier Araya Navarro
2020-04-02 16:24 ` Eli Zaretskii
2020-04-02 17:07   ` andres.ramirez
2020-04-03  5:07     ` Jorge Javier Araya Navarro
2020-04-03 13:43   ` Stefan Monnier
2020-04-03 14:12     ` Eli Zaretskii
2020-04-03 15:13       ` Stefan Monnier
2020-04-04  8:15         ` Eli Zaretskii [this message]
2020-04-04 18:00           ` Stefan Monnier
2020-04-03 14:57 ` Tuấn-Anh Nguyễn
2020-04-04  1:27   ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pncnvf97.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.