unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Philip Kaludercic <philipk@posteo.net>
Cc: ruijie@netyu.xyz, casouri@gmail.com, emacs-devel@gnu.org
Subject: Re: Code quality of some -ts-mode major modes
Date: Fri, 17 Mar 2023 17:31:05 +0200	[thread overview]
Message-ID: <835yaze6o6.fsf@gnu.org> (raw)
In-Reply-To: <87v8izjtf2.fsf@posteo.net> (message from Philip Kaludercic on Fri, 17 Mar 2023 15:20:49 +0000)

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: ruijie@netyu.xyz,  casouri@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 17 Mar 2023 15:20:49 +0000
> 
> >> The rule-of-thumb that I go by is that `if' is used if you have two
> >> cases you are interested in, especially if you are interested in the
> >> return value, while `when' is more "imperative" in style and indicates
> >> to the reader that the code is being executed for a side-effect.
> >
> > That is your personal preference.  Objectively, there's nothing wrong
> > with using 'if' that has no 'else' part.  So changing someone's code
> > to use 'when' where 'if' can do, or vice versa -- replacing 'when'
> > with a single sexp in the body with 'if' -- has no real justification.
> 
> Technically no, but I do hope not to be mistaken that there is a
> convention (along the lines I gave above) here that goes beyond just my
> personal preference.  CLTL even says[p. 166]:

It is fine for you to prefer this convention, but we don't mandate it
in Emacs.

> > Because if we add that to the code, we will need to maintain that for
> > the observable future to be correct.  Comments, even if they are
> > outdated, don't need such level of maintenance.  
> 
> That could be resolved by either pinning a revision or instead of
> cloning the repository to download a tarball of a tag.  In fact that
> should make the system even more stable than the way I see it being
> promoted around the web currently, that just maps languages to Git
> repository URLs.

It can be resolved in more than one way, but all of them mean
additional maintenance burden, so I don't think we should undertake
that.

> >                                                  Moreover, the fact
> > that a given grammar was used for testing doesn't mean another grammar
> > will not work as well.
> 
> I don't know of any language with multiple independent implementations

I do.  Indeed, most have just one.  But not all.

> > Again, I explained the rationale many times here.  I can explain
> > again, but is that really necessary?
> 
> You had previously said that you are opposed to raising an error (or am
> I mistaken?), while the above comment says "we want this to signal and
> error".

No you are mistaken.  We do want this to signal an error if
tree-sitter is not compiled in or the grammar is not available.

> > Help in reviewing patches when they are posted is also very welcome.
> > It takes more than one pair of eyes to spot every bit that needs
> > attention.
> 
> I'll try and do so when I notice one.  I have also been sketching out
> support for a markdown-ts-mode to better understand the how tree-sitter
> works, which could help.

TIA.



  reply	other threads:[~2023-03-17 15:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 10:08 Code quality of some -ts-mode major modes Philip Kaludercic
2023-03-17 10:29 ` Ruijie Yu via Emacs development discussions.
2023-03-17 11:52   ` Eli Zaretskii
2023-03-17 12:37   ` Philip Kaludercic
2023-03-17 13:54     ` Eli Zaretskii
2023-03-17 15:20       ` Philip Kaludercic
2023-03-17 15:31         ` Eli Zaretskii [this message]
2023-03-17 15:49           ` Philip Kaludercic
2023-03-17 16:35             ` Eli Zaretskii
2023-03-17 16:53               ` Philip Kaludercic
2023-03-17 21:45       ` Dmitry Gutov
2023-03-18  5:59         ` Eli Zaretskii
2023-03-17 11:46 ` Eli Zaretskii

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=835yaze6o6.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=casouri@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    --cc=ruijie@netyu.xyz \
    /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 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).