[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code quality of some -ts-mode major modes
From: |
Eli Zaretskii |
Subject: |
Re: Code quality of some -ts-mode major modes |
Date: |
Fri, 17 Mar 2023 17:31:05 +0200 |
> 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.
- Code quality of some -ts-mode major modes, Philip Kaludercic, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Ruijie Yu, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Eli Zaretskii, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Philip Kaludercic, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Eli Zaretskii, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Philip Kaludercic, 2023/03/17
- Re: Code quality of some -ts-mode major modes,
Eli Zaretskii <=
- Re: Code quality of some -ts-mode major modes, Philip Kaludercic, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Eli Zaretskii, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Philip Kaludercic, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Dmitry Gutov, 2023/03/17
- Re: Code quality of some -ts-mode major modes, Eli Zaretskii, 2023/03/18
Re: Code quality of some -ts-mode major modes, Eli Zaretskii, 2023/03/17