emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make all tree-sitter modes optional


From: Dmitry Gutov
Subject: Re: Make all tree-sitter modes optional
Date: Tue, 17 Jan 2023 19:59:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 17/01/2023 19:38, Eli Zaretskii wrote:
Date: Tue, 17 Jan 2023 19:10:45 +0200
Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
  theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>

I can start a new session for an investigation, but I'm not going to
restart Emacs every time I evaluate a form.

Why not?  It's easy and quick and solves all the problems you
mentioned (and then some).

That would increase the time and effort required for such an
investigation ~5x. (*)

But testing in a session that is not clean is not recommended.  For
reasons more important than the issue at hand...

With some experience, one can usually sort issues into those that require clean environment, those than might use it, and those that most likely don't. In the end, that saves time.

However, I'm the last person to tell others how to organize their
workflows, so I'll leave it at that.

Sure.

You can start from "emacs -Q" and load whatever is needed.  You can
make an ad-hoc init file that loads everything you need automatically,
to save manual typing.  I'm doing this all the time when the setup is
complicated.

And now more people will have to, in less complicated situations, which
previously required no such preparation.

Maybe.  Like I said, the solution I proposed is not ideal, I just
don't see a clearly better one.

Every approach we can take will annoy somebody, like like in SPC xkcd.

But dropping the auto-mode-alist modifications looks perfectly in line with the conservative approach we have used in the past, where features are rolled out gradually.

I also don't fully understand the benefits of your proposal. Suppose we apply it. You talked about how easier it will be to document the new behaviors if all ts modes are consistent. Okay. What are we going to say in that documentation?

Let's say there are two users, Bob and Alice. Bob has tried out yaml-ts-mode and wants to use it regularly. Alice has tried out js-ts-mode and also wants to use it from now on. What will be our recommendations for them to make that happen?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]