Re: An anonymous IRC user's opinion

Re: An anonymous IRC user's opinion

[Abraham S.A.H. via Emacs development discussions.]

Some thoughts about what have been discussed in this topic:

** The plague of pre-configuration:

Isn't Emacs usable without any pre-configuration, out of the box?
I think it is.  One can install Emacs and use it right away as an
editor without any initial configurations.  Emacs — without any prior
customisation and configuration — already provides much more features
compared to many code/text editors that I know and have worked with.

However, current Emacs' vanilla setup is not all of what make most
Emacs newcomers interested in Emacs and/or discover Emacs.  So they
tend to start customising and tweaking Emacs right away, rather than
using it first.  I'm not sure, but I think this tendency is not
something that Emacs devs or community can prevent.  But at least,
Emacs has to say to it to the user that you can use me without any
prior configuration for most of the simple use cases of a text
editor.

Another problem is that most of those newcomers start doing that
without reading Emacs' manual.  Now, that one has to be clearly
discouraged.  Doesn't matter how intuitive an interface is designed,
it's always good to come with a manual, and Emacs comes with a very
good one.  And it's always advised to use a tool after or alongside
reading its documentation.

\f

** The audience of Doom:

I think, Doom and Spacemacs were and are (at least, partially)
successful in attracting:

1. Previous vi, vim, or neovim users;
2. Anyone who likes VI and VIM key bindings.

Amongst whom are beginners or those who don't like to do the required
configuration to achieve a similar look and feel to Doom
and Spacemacs.

However, it is not as much attractive for other people than those.  But still
there are people using Doom/Spacemacs not being from those two groups.

\f

** A wizard to do the magic work:

What about an initial interactive wizard buffer?  Many complicated
software actually come with that.  Prompting user to choose some 
important options and to declare his/her use case and to notify him
about some important tips.

An initial interactive wizard will force a beginner to pay attention
to notes, tips, suggestions, and warning along helping him/her to
interactively configure and prepare his/her Emacs for its first use.

The interface would use a mechanism much like Emacs' Custom buffers.

That would just open for the first time Emacs is opened or such thing.

--
Best Regards,
Abraham
Sent with Tutanota; https://tuta.com

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Abraham S.A.H." via "Emacs development discussions. wrote:

> Another problem is that most of those newcomers start doing
> that without reading Emacs' manual.  Now, that one has to be
> clearly discouraged.

We can assume the opposite, that people will not read it.
I don't know if "everyone" did that in the 70s, in the 90/00s
only the most dedicated guys read books and manuals and now,
we can assume that this is an almost foreign concept to young
people. Why on Earth should you read a book if you want to use
software, what does that have to do with it and why not just
use the software right now?

And while it is good there is documentation, these people
thinking like that are not entirely wrong. I start to agree
with them more and more.

> Doesn't matter how intuitive an interface is designed, it's
> always good to come with a manual, and Emacs comes with
> a very good one.

Those are different things, let's do both as good as we can
and as much energy people feel it is meaningful to put
into it. Improve documentation, improve interface, improve
computation, improve some alternative backend that no one
ever heard of - we take it.

Everything that makes it better and make people active, with
us. Enough with the long period of everyone piling up their
own .emacs - can't have that anymore, there are too few of us
to afford it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

"Abraham S.A.H." <arash.sah@tuta.io> writes:

> Isn't Emacs usable without any pre-configuration, out of the box?

It is a good editor without any pre-configuration (it even ships
org-mode). But to be a good Web-IDE, C++ or Scheme programming
environment, Server automation plattform, and so forth, it requires
configuration.

Which might be a reason why it is discovered by writers, and why
Spacemacs and Doom capture new people.

> Another problem is that most of those newcomers start doing that
> without reading Emacs' manual.  Now, that one has to be clearly
> discouraged.  Doesn't matter how intuitive an interface is designed,
> it's always good to come with a manual, and Emacs comes with a very
> good one.  And it's always advised to use a tool after or alongside
> reading its documentation.

No. Any software that says that you have to read the manual first is
doomed to fail for most people.

One of the best features of nano is that the important keybindings are
shown directly on the screen. No documentation needed.

We obviously can’t have *no* explanation, but if people have to read
more than an 80x30 screen of explanations, it’s too much.

> \f
>
> ** The audience of Doom:
>
> I think, Doom and Spacemacs were and are (at least, partially)
> successful in attracting:
>
> 1. Previous vi, vim, or neovim users;
> 2. Anyone who likes VI and VIM key bindings.

You miss people who want their editor to look cool. There are a lot of
visiual attractions built right into doom and Spacemacs from the start.

> \f
>
> ** A wizard to do the magic work:
>
> What about an initial interactive wizard buffer?  Many complicated
> software actually come with that.  Prompting user to choose some
> important options and to declare his/her use case and to notify him
> about some important tips.

Once we have a wizard, it becomes even more likely that people will stop
before even starting.

> An initial interactive wizard will force a beginner to pay attention
> to notes, tips, suggestions, and warning along helping him/her to
> interactively configure and prepare his/her Emacs for its first use.

I don’t like the "force" here.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

> No. Any software that says that you have to read the manual
> first is doomed to fail for most people.
>
> One of the best features of nano is that the important
> keybindings are shown directly on the screen.
> No documentation needed.
>
> We obviously can't have *no* explanation, but if people have
> to read more than an 80x30 screen of explanations, it's
> too much.

+1 Very much so.

> You miss people who want their editor to look cool.

How it looks is a huge part of it.

And it is not just superficial. We have trained eyes. If it
looks good, it is good. This is like ...
decoded automatically.

So it should be good, and this should be reflected in that it
also looks good.

But you can also put some extra effort to make it look even
better :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

> One of the best features of nano is that the important
> keybindings are shown directly on the screen.
> No documentation needed.

It is interesting you should say that, because I thought about
that recently when I did this interface:

  https://dataswamp.org/~incal/bad-www/img/studio.png

Note the [h] button that will hide all the buttons if you
don't wat to see them :)

What do you think?

I am full cycle, GUI -> CLI -> TUI.

Tired of typing those long commands, but it was fun while
it lasted. Better just pushing a button. We have a full
keyboard of keys plus shortcuts, that must be enough?

What interface people expect today I don't know and there
seems to be quite some variety in the smartphone app world.
HTML/CSS maybe is prevailing as technology, but I mean how it
looks to the user?

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Abraham S.A.H. via Emacs development discussions.]

> No. Any software that says that you have to read the manual first is
> doomed to fail for most people.

I think you missed the phrase “or alongside”.  We already know that
one can still use Emacs without reading its manual, though not Emacs’
full potential.

Being well documented is always a great advantage.  And having the
personality to read and consider before action so as well.

Best is to make tools that can be used without reading manuals or
education, as much as possible; while still keeping them
well-documented and well-recorded.

However, most physical equipments (not pieces of software), even very
small or simple ones come with dedicated manuals, which are sometimes
a hundred in pages.  It includes most of the tools that I have in my
home.  Most of them are usable without reading their manual, of
course.  But, if you don’t read the manual, you will never notice some
of their more specialised features.  For slightly more complex
hardware, like microwaves, or AC splits you will definitely can’t
properly use your tool without reading its manual and you will most
probably will break it, sooner or later.

And about software, advanced programs even with much less
functionality than Emacs come with manuals and a user usually needs to
read those to make a proper use of them.  I think more than half of
the programs that I have on my Linux system are useless without their
docs and manuals.  And the matter is even worse on Windows, most
professional applications can’t be even utilized without a proper
Education!  People take courses to understand how to use them.

All these examples of software and hardware don’t seem to be doomed or
going to be doomed.  Any tool needs prior knowledge at some degree.
When it’s more powerful, has and needs more documentation.
Like programming languages which are very powerful and not possible
to be used without reading stuff first.

> You miss people who want their editor to look cool. There are a lot of
> visiual attractions built right into doom and Spacemacs from the start.

True.  They are in “But still there are people using Doom/Spacemacs
not being from those two groups.”

--
Best Regards,
Abraham
Sent with Tutanota; https://tuta.com

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

"Abraham S.A.H." via "Emacs development discussions." <emacs-devel@gnu.org> writes:

>> No. Any software that says that you have to read the manual first is
>> doomed to fail for most people.
> Best is to make tools that can be used without reading manuals or
> education, as much as possible; while still keeping them
> well-documented and well-recorded.

I wholeheartedly agree.

> I think more than half of
> the programs that I have on my Linux system are useless without their
> docs and manuals.  

That’s different for me, but I enjoy the Guile info manual a lot;
especially read from Emacs. That’s often nicer that Googling for
solutions with Python.

> All these examples of software and hardware don’t seem to be doomed or
> going to be doomed.  Any tool needs prior knowledge at some degree.

For most tools you already have that prior knowledge from other
software; and often you can discover by trial and error (just clicking
buttons).

Which key is an awesome improvement for this discovery. Clicking ESC
even shows all M- bindings.

And I just learned about C-h b. That’s a command we should show more
prominently.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1121 bytes --]

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Abraham S.A.H." via "Emacs development discussions. wrote:

>> No. Any software that says that you have to read the manual
>> first is doomed to fail for most people.
>
> I think you missed the phrase "or alongside".  We already
> know that one can still use Emacs without reading its
> manual, though not Emacs' full potential.

You read the manuals for your TI-83 scientific calculator and
Makita impact driver as well?

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

> And I just learned about C-h b. That's a command we should
> show more prominently.

Here, read this interview, if you'd like - 

  https://sachachua.com/blog/2024/04/emacs-interview-daniel-semyonov/

this guy [hello if you are reading this] learned to program
just using the on-line help (that means Emacs' help, on-line
means not printed on paper).

And many people did that, this is the first time I heard it in
the Emacs world but using the help system and that's all.
The F1 keys on Windows if you remember. (Not sure if I do.
What did the F10 key do?)

So, one wonders, why is it better to read the manual ONCE
cover to cover in a book than bringing the help up whenever
one needs it, one short paragraph at a time, on the screen?
To me, if I had to pick only one, the computer version,
I would take that and not the book. (No, the help isn't _the_
manual, but it is _a_ manual, why not.)

People are different and we have different resources, it is
all good and we shouldn't assume anyone has done anything IMO.

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[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. ]]]

  > You read the manuals for your TI-83 scientific calculator and
  > Makita impact driver as well?

I have a feeling that question is sarcastic.

Sarcasm make the point unclear, so it leads to misunderstandings and
confusion.  I don't use either of those products, so I can't guess
what the point was.

Also, it tends to suggest hostility (even if none is actually meant).
That often hurts feelings and makes the discussion acrimonious.

Therefore we ask people to avoid sarcasm in our discussions.
See https://gnu.org/philosophy/kind-communication.html.

Can you please restate your point without sarcasm, so it will be clear?

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

Re: An anonymous IRC user's opinion

[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. ]]]

  > > Isn't Emacs usable without any pre-configuration, out of the box?

  > It is a good editor without any pre-configuration (it even ships
  > org-mode). But to be a good Web-IDE, C++ or Scheme programming
  > environment, Server automation plattform, and so forth, it requires
  > configuration.

Between there to what follows

  > Which might be a reason why it is discovered by writers, and why
  > Spacemacs and Doom capture new people.

there is an yawning gulf.  My imagination can't get me from one to the
other.  Can you please explain how to cross?

You listed Web-IDE, C++ or Scheme programming environment, and Server
automation plattform as kinds of work a user might want Emacs set up
for.  Choosing Spacemacs first, does it do some of those three things?
Does Doom do some of those three things?

Aldo, when you say that each of them requires "configuration", could
you make that more concrete?  What sort of configuration does "Web
IDE" require?  What sort for Scheme programming environment?  And so
on.  I'm not asking for all the details, just an overall idea.

Could we easily add those missing kinds of configuration to Emacs?
If we did, would that make Emacs competitive with Spacemacs and Doom?

We generally try to make all sorts of packages for various uses of
Emacs coexist in a single Emacs job.  I get the impression people are
assuming that these different configurations are mutually incompatible,
so that it is necessary to choose which one to install.

Is that what people assume?  If people do, why so?  Why can't
users select one at run time?

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

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Richard Stallman <rms@gnu.org> writes:

>   > It is a good editor without any pre-configuration (it even ships
>   > org-mode). But to be a good Web-IDE, C++ or Scheme programming
>   > environment, Server automation plattform, and so forth, it requires
>   > configuration.
>
> Between there to what follows
>
>   > Which might be a reason why it is discovered by writers, and why
>   > Spacemacs and Doom capture new people.
>
> there is an yawning gulf.  My imagination can't get me from one to the
> other.  Can you please explain how to cross?
>
> You listed Web-IDE, C++ or Scheme programming environment, and Server
> automation plattform as kinds of work a user might want Emacs set up
> for.  Choosing Spacemacs first, does it do some of those three things?
> Does Doom do some of those three things?

Yes: both Spacemacs and Doom provide ready-made configurations that can
be activated to get an environment optimized for that task.

> Aldo, when you say that each of them requires "configuration", could
> you make that more concrete?  What sort of configuration does "Web
> IDE" require?  What sort for Scheme programming environment?  And so
> on.  I'm not asking for all the details, just an overall idea.

Activating the correct set of modes, installing some packages, tweaking
some customizations.

> Could we easily add those missing kinds of configuration to Emacs?
> If we did, would that make Emacs competitive with Spacemacs and Doom?

That’s the point, yes: improving the newcomer experience of regular
Emacs. But note that Spacemacs and Doom are simply configurations of
Emacs, though pretty far from Vanilla Emacs.

> so that it is necessary to choose which one to install.
>
> Is that what people assume?  If people do, why so?  Why can't
> users select one at run time?

I do not assume that. It’s rather that a C++ IDE and a writing system
and Scheme Programming and a Web-IDE have a lot of overlap, so some of
the modes they use are the same, sometimes with a bit different setup.

For long-time users that’s great: all the different things interact
nicely. That’s something not found elsewhere.

But for new users it means that they can’t just activate the C++-mode,
but instead they have to track down the right configuration options.

There are already some optimized setups for C++ (and for others, too),
but which one of these are good for the specific task is hard to figure
out and they are not really discoverable from Emacs. And that’s also a
step that most users today won’t do. They see that Emacs doesn’t solve
their current problem out of the box and switch to a program that does.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Johan Myréen]

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

I see this more as a documentation problem. Emacs lacks "official"
documentation on how to configure an environment to do certain things,
which includes installing certain Elisp packages, and configuring them. I'm
going to use software development as an example.

In the good old days software development meant editing a few C files in
Emacs and then running make. This no longer meets the expectations people
have of a software development environment. For example, creating a
contemporary environment to write and build software using the Rust
programming language and Emacs, you need Rust mode, rust-ts-mode for
Treesitter integration, Eglot to communicate with rust-analyzer (a Language
Server implementation for Rust) for completion and goto definition, Company
mode for code completion, Magit for version control, DAP mode for
debugging, and so on. Many of these packages have alternative
implementations, for example rustic-mode instead of rust-mode.

I'm not saying you can't edit Rust code without all these packages, but
these packages combined provide the minimum that the competition (e.g.
Visual Studio Code) offers.

The packages are all available for Emacs, which is fine. The problem is
that there is no single source for how to put together the Rust environment
for Emacs using the packages. I would prefer official Gnu Emacs
documentation telling me what packages are needed (including a description
of pros and cons of competing modes), how to install them, and what
configuration is needed.

In the absence of official documentation, you will have to search the net
for tutorials on the subject. These third party tutorials are often of
quite low quality. Many of them are out of date, and, what's worse, often
contain irrelevant and extremely opinionated information, like disabling
the Emacs menu and toolbars, enabling evil mode, etc. A beginner can have
trouble filtering out what's essential and what's not. As another example,
at some point the web page describing how to use Emacs for Clojure
programming said to start with completely removing the .emacs file and the
.emacs.d directory. No explanation was given what these files are, what
they might be needed for, or what the consequences of this removal would
be. Not even a suggestion to make a backup of the files was given.


On Wed, 9 Oct 2024 at 06:30, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > > Isn't Emacs usable without any pre-configuration, out of the box?
>
>   > It is a good editor without any pre-configuration (it even ships
>   > org-mode). But to be a good Web-IDE, C++ or Scheme programming
>   > environment, Server automation plattform, and so forth, it requires
>   > configuration.
>
> Between there to what follows
>
>   > Which might be a reason why it is discovered by writers, and why
>   > Spacemacs and Doom capture new people.
>
> there is an yawning gulf.  My imagination can't get me from one to the
> other.  Can you please explain how to cross?
>
> You listed Web-IDE, C++ or Scheme programming environment, and Server
> automation plattform as kinds of work a user might want Emacs set up
> for.  Choosing Spacemacs first, does it do some of those three things?
> Does Doom do some of those three things?
>
> Aldo, when you say that each of them requires "configuration", could
> you make that more concrete?  What sort of configuration does "Web
> IDE" require?  What sort for Scheme programming environment?  And so
> on.  I'm not asking for all the details, just an overall idea.
>
> Could we easily add those missing kinds of configuration to Emacs?
> If we did, would that make Emacs competitive with Spacemacs and Doom?
>
> We generally try to make all sorts of packages for various uses of
> Emacs coexist in a single Emacs job.  I get the impression people are
> assuming that these different configurations are mutually incompatible,
> so that it is necessary to choose which one to install.
>
> Is that what people assume?  If people do, why so?  Why can't
> users select one at run time?
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

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

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: Johan Myréen <johan.myreen@gmail.com>
> Date: Wed, 9 Oct 2024 14:09:13 +0300
> 
> I see this more as a documentation problem. Emacs lacks "official" documentation on how to configure an
> environment to do certain things, which includes installing certain Elisp packages, and configuring them.

My analysis is different.  Emacs lacks volunteers who'd sit down and
write documentation on how to configure Emacs for this or that job.
Once that is written, and written well, admitting it into Emacs is
usually a no-brainer.

Mind you: the above is an extremely non-trivial job, because the sheer
number of possible "jobs" which Emacs can support is mind-boggling.
Even if someone describes in excruciating detail how to configure
Emacs for Rust development, that only helps people who need to develop
programs in Rust, but doesn't help at all to, say, someone who needs to
write a thesis about some academic subject, or read email from Gmail
or even develop C++ programs, or...

> In the good old days software development meant editing a few C files in Emacs and then running make.
> This no longer meets the expectations people have of a software development environment. For example,
> creating a contemporary environment to write and build software using the Rust programming language and
> Emacs, you need Rust mode, rust-ts-mode for Treesitter integration, Eglot to communicate with
> rust-analyzer (a Language Server implementation for Rust) for completion and goto definition, Company
> mode for code completion, Magit for version control, DAP mode for debugging, and so on. Many of these
> packages have alternative implementations, for example rustic-mode instead of rust-mode.

This is an exaggeration to some degree.  rust-ts-mode is part of
Emacs, and could be turned on automatically when a Rust file is
visited; we didn't do that because we are unsure whether users of an
unbundled Rust mode will protest.  Eglot is part of Emacs, but it
cannot be started automatically because the LSP server, which is a
separate piece of software, needs to be installed and configured
first; are we supposed to be held responsible for that as well?  We do
have TAGS support for Rust (goto definition etc., so alternative to
LSP), and the new etags-regen-mode might just make the job of using
TAGS much easier and seamless.  Magit is nice, but not really
necessary, since we have VC built in, which doesn't need to be
configured.  DAP is not necessary, since Emacs has a GDB front-end
(which doesn't need to be configured, just invoked with a single
command), and GDB supports debugging Rust programs.

So things are not that bad, are they?

I do agree that good tutorials which would mention all this stuff
would make things better, at least for those who read documentation
(how many do?), but that needs volunteers to sit down and write that
up.  Would you please consider doing something like that for some jobs
with which you are familiar?

> I'm not saying you can't edit Rust code without all these packages, but these packages combined provide
> the minimum that the competition (e.g. Visual Studio Code) offers.

I'm guessing VSCode comes with pre-configured LSP servers, a single
Rust mode, and a single Git interface.  Am I mistaken?  If so, is that
how we want to treat our users? will they agree to be treated like
that?

Re: An anonymous IRC user's opinion

[tomas]

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

On Wed, Oct 09, 2024 at 04:13:58PM +0300, Eli Zaretskii wrote:

[...]

> I'm guessing VSCode comes with pre-configured LSP servers, a single
> Rust mode, and a single Git interface.  Am I mistaken?  If so, is that
> how we want to treat our users? will they agree to be treated like
> that?

This is what vscode installs on some remote devel container:

  # du -sh ~/.vscode-server
  1.8G    /home/user/.vscode-server

Needless to say, you will meet people around here who would characterise
this as "bloat" and would prefer tramp.

So you'll have to multiply the "number of task types" by the number of
devel styles to get at a more realistic assessment of the matrix :-)

I for one will avoid LSPs wherever I possibly can.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johan Myréen <johan.myreen@gmail.com>
>> Date: Wed, 9 Oct 2024 14:09:13 +0300
>> 
>> I see this more as a documentation problem. Emacs lacks "official" documentation on how to configure an
>> environment to do certain things, which includes installing certain Elisp packages, and configuring them.
>
> My analysis is different.  Emacs lacks volunteers who'd sit down and
> write documentation on how to configure Emacs for this or that job.

I think the problem is different: there are already people who write
documentation on how to configure Emacs for tasks. There are also many
.emacs.d reppositories.

There are awesome Emacs setups out there, much better than what I have.

What’s missing is a way to integrate these efforts into Emacs so new
users can benefit from them.

I don’t know the best way to do that integration, but I think
integrating these in some way for new users could help a lot.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Johan Myréen]

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

I understand Emacs is a volunteer project and finding good documentation
writers is difficult. I was just suggesting what direction I would like to
see Emacs documentation going. Emacs has a good and extensive manual that
provides mostly a great reference to how to use Emacs as an editor. What I
am proposing is a higher level view, a kind of cookbook on how to do
different things with Emacs.

I just started my Emacs (from the main branch) with -q and opened a Rust
source file. Emacs out of the box does not even recognize the .rs file
extension: the file is opened in Fundamental mode. A novice Emacs user
might guess that he or she needs to install a Rust mode for Emacs to
recognize we are editing Rust source code. But by only doing this the user
is missing out on so much useful functionality Emacs has to offer. How is
the user supposed to know that ¨Eglot" is the way to connect to a language
server, or that a package named ¨Company" provides completion? The only way
right now is to search for this on the internet, which is associated with
the quality problems I described in my previous message.

Software has grown more complex during the years Emacs has been in
existence, and so have the expectations of the public using it. Emacs has
fantastic collections of packages, each focusing on different things. This
is a good modular design. Some of these packages can be used to form, for
example, a working Rust development environment. The problem is finding
these packages. How does a new Emacs user know what to look for?

So I am proposing a "task-oriented" category in the Emacs documentation. I
don´t think there is such a category.

Eglot is part of Emacs, but it cannot be started automatically because the
> LSP server, which is a
> separate piece of software, needs to be installed and configured first;
> are we supposed to be held
> responsible for that as well


No, all I am talking about is documentation. In fact I really dislike some
things that happen by magic, but are undocumented. They typically break
over time, which is a bigger headache to fix than configuring things by
hand using good documentation.

I'm guessing VSCode comes with pre-configured LSP servers, a single
> Rust mode, and a single Git interface.  Am I mistaken?
>

No, VSCode does not come pre-configured for Rust development. But, there is
a good, task-oriented web page that describes in simple terms what needs to
be installed and configured to start writing Rust code using VSCode.
Similar pages exist for Java, Javascript, C++, C#, Python, Go, etc. More
importantly, this documentation can be found on code.visualstudio.com (
https://code.visualstudio.com/docs/languages/rust), not on YouTube.com or
robert.kra.hn or some other random website.

Johan Myréen




On Wed, 9 Oct 2024 at 16:14, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Johan Myréen <johan.myreen@gmail.com>
> > Date: Wed, 9 Oct 2024 14:09:13 +0300
> >
> > I see this more as a documentation problem. Emacs lacks "official"
> documentation on how to configure an
> > environment to do certain things, which includes installing certain
> Elisp packages, and configuring them.
>
> My analysis is different.  Emacs lacks volunteers who'd sit down and
> write documentation on how to configure Emacs for this or that job.
> Once that is written, and written well, admitting it into Emacs is
> usually a no-brainer.
>
> Mind you: the above is an extremely non-trivial job, because the sheer
> number of possible "jobs" which Emacs can support is mind-boggling.
> Even if someone describes in excruciating detail how to configure
> Emacs for Rust development, that only helps people who need to develop
> programs in Rust, but doesn't help at all to, say, someone who needs to
> write a thesis about some academic subject, or read email from Gmail
> or even develop C++ programs, or...
>
> > In the good old days software development meant editing a few C files in
> Emacs and then running make.
> > This no longer meets the expectations people have of a software
> development environment. For example,
> > creating a contemporary environment to write and build software using
> the Rust programming language and
> > Emacs, you need Rust mode, rust-ts-mode for Treesitter integration,
> Eglot to communicate with
> > rust-analyzer (a Language Server implementation for Rust) for completion
> and goto definition, Company
> > mode for code completion, Magit for version control, DAP mode for
> debugging, and so on. Many of these
> > packages have alternative implementations, for example rustic-mode
> instead of rust-mode.
>
> This is an exaggeration to some degree.  rust-ts-mode is part of
> Emacs, and could be turned on automatically when a Rust file is
> visited; we didn't do that because we are unsure whether users of an
> unbundled Rust mode will protest.  Eglot is part of Emacs, but it
> cannot be started automatically because the LSP server, which is a
> separate piece of software, needs to be installed and configured
> first; are we supposed to be held responsible for that as well?  We do
> have TAGS support for Rust (goto definition etc., so alternative to
> LSP), and the new etags-regen-mode might just make the job of using
> TAGS much easier and seamless.  Magit is nice, but not really
> necessary, since we have VC built in, which doesn't need to be
> configured.  DAP is not necessary, since Emacs has a GDB front-end
> (which doesn't need to be configured, just invoked with a single
> command), and GDB supports debugging Rust programs.
>
> So things are not that bad, are they?
>
> I do agree that good tutorials which would mention all this stuff
> would make things better, at least for those who read documentation
> (how many do?), but that needs volunteers to sit down and write that
> up.  Would you please consider doing something like that for some jobs
> with which you are familiar?
>
> > I'm not saying you can't edit Rust code without all these packages, but
> these packages combined provide
> > the minimum that the competition (e.g. Visual Studio Code) offers.
>
> I'm guessing VSCode comes with pre-configured LSP servers, a single
> Rust mode, and a single Git interface.  Am I mistaken?  If so, is that
> how we want to treat our users? will they agree to be treated like
> that?
>

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

Re: An anonymous IRC user's opinion

[Ship Mints]

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

Speaking of cookbooks, some people prefer packaged food, some prefer
cooking. I see Emacs as a platform for those who prefer cooking. Public
support via reddit or stackoverflow or the Emacs mailing lists, tends to be
friendly and helpful but can't substitute users' own desires to cook for
themselves. When VSCode goes wrong, they have to figure stuff out for
themselves anyway (it's a fairly buggy ecosystem, in my experience). If
they can handle the complexity of the Rust compiler, they can handle the
complexity of Emacs. They just have to cook a little.

On Wed, Oct 9, 2024 at 12:07 PM Johan Myréen <johan.myreen@gmail.com> wrote:

> I understand Emacs is a volunteer project and finding good documentation
> writers is difficult. I was just suggesting what direction I would like to
> see Emacs documentation going. Emacs has a good and extensive manual that
> provides mostly a great reference to how to use Emacs as an editor. What I
> am proposing is a higher level view, a kind of cookbook on how to do
> different things with Emacs.
>
> I just started my Emacs (from the main branch) with -q and opened a Rust
> source file. Emacs out of the box does not even recognize the .rs file
> extension: the file is opened in Fundamental mode. A novice Emacs user
> might guess that he or she needs to install a Rust mode for Emacs to
> recognize we are editing Rust source code. But by only doing this the user
> is missing out on so much useful functionality Emacs has to offer. How is
> the user supposed to know that ¨Eglot" is the way to connect to a language
> server, or that a package named ¨Company" provides completion? The only way
> right now is to search for this on the internet, which is associated with
> the quality problems I described in my previous message.
>
> Software has grown more complex during the years Emacs has been in
> existence, and so have the expectations of the public using it. Emacs has
> fantastic collections of packages, each focusing on different things. This
> is a good modular design. Some of these packages can be used to form, for
> example, a working Rust development environment. The problem is finding
> these packages. How does a new Emacs user know what to look for?
>
> So I am proposing a "task-oriented" category in the Emacs documentation. I
> don´t think there is such a category.
>
> Eglot is part of Emacs, but it cannot be started automatically because the
>> LSP server, which is a
>> separate piece of software, needs to be installed and configured first;
>> are we supposed to be held
>> responsible for that as well
>
>
> No, all I am talking about is documentation. In fact I really dislike some
> things that happen by magic, but are undocumented. They typically break
> over time, which is a bigger headache to fix than configuring things by
> hand using good documentation.
>
> I'm guessing VSCode comes with pre-configured LSP servers, a single
>> Rust mode, and a single Git interface.  Am I mistaken?
>>
>
> No, VSCode does not come pre-configured for Rust development. But, there
> is a good, task-oriented web page that describes in simple terms what needs
> to be installed and configured to start writing Rust code using VSCode.
> Similar pages exist for Java, Javascript, C++, C#, Python, Go, etc. More
> importantly, this documentation can be found on code.visualstudio.com (
> https://code.visualstudio.com/docs/languages/rust), not on YouTube.com or
> robert.kra.hn or some other random website.
>
> Johan Myréen
>
>
>
>
> On Wed, 9 Oct 2024 at 16:14, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Johan Myréen <johan.myreen@gmail.com>
>> > Date: Wed, 9 Oct 2024 14:09:13 +0300
>> >
>> > I see this more as a documentation problem. Emacs lacks "official"
>> documentation on how to configure an
>> > environment to do certain things, which includes installing certain
>> Elisp packages, and configuring them.
>>
>> My analysis is different.  Emacs lacks volunteers who'd sit down and
>> write documentation on how to configure Emacs for this or that job.
>> Once that is written, and written well, admitting it into Emacs is
>> usually a no-brainer.
>>
>> Mind you: the above is an extremely non-trivial job, because the sheer
>> number of possible "jobs" which Emacs can support is mind-boggling.
>> Even if someone describes in excruciating detail how to configure
>> Emacs for Rust development, that only helps people who need to develop
>> programs in Rust, but doesn't help at all to, say, someone who needs to
>> write a thesis about some academic subject, or read email from Gmail
>> or even develop C++ programs, or...
>>
>> > In the good old days software development meant editing a few C files
>> in Emacs and then running make.
>> > This no longer meets the expectations people have of a software
>> development environment. For example,
>> > creating a contemporary environment to write and build software using
>> the Rust programming language and
>> > Emacs, you need Rust mode, rust-ts-mode for Treesitter integration,
>> Eglot to communicate with
>> > rust-analyzer (a Language Server implementation for Rust) for
>> completion and goto definition, Company
>> > mode for code completion, Magit for version control, DAP mode for
>> debugging, and so on. Many of these
>> > packages have alternative implementations, for example rustic-mode
>> instead of rust-mode.
>>
>> This is an exaggeration to some degree.  rust-ts-mode is part of
>> Emacs, and could be turned on automatically when a Rust file is
>> visited; we didn't do that because we are unsure whether users of an
>> unbundled Rust mode will protest.  Eglot is part of Emacs, but it
>> cannot be started automatically because the LSP server, which is a
>> separate piece of software, needs to be installed and configured
>> first; are we supposed to be held responsible for that as well?  We do
>> have TAGS support for Rust (goto definition etc., so alternative to
>> LSP), and the new etags-regen-mode might just make the job of using
>> TAGS much easier and seamless.  Magit is nice, but not really
>> necessary, since we have VC built in, which doesn't need to be
>> configured.  DAP is not necessary, since Emacs has a GDB front-end
>> (which doesn't need to be configured, just invoked with a single
>> command), and GDB supports debugging Rust programs.
>>
>> So things are not that bad, are they?
>>
>> I do agree that good tutorials which would mention all this stuff
>> would make things better, at least for those who read documentation
>> (how many do?), but that needs volunteers to sit down and write that
>> up.  Would you please consider doing something like that for some jobs
>> with which you are familiar?
>>
>> > I'm not saying you can't edit Rust code without all these packages, but
>> these packages combined provide
>> > the minimum that the competition (e.g. Visual Studio Code) offers.
>>
>> I'm guessing VSCode comes with pre-configured LSP servers, a single
>> Rust mode, and a single Git interface.  Am I mistaken?  If so, is that
>> how we want to treat our users? will they agree to be treated like
>> that?
>>
>

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

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Johan Myréen <johan.myreen@gmail.com>, emacs-devel@gnu.org
> Date: Wed, 09 Oct 2024 18:02:14 +0200
> 
> > My analysis is different.  Emacs lacks volunteers who'd sit down and
> > write documentation on how to configure Emacs for this or that job.
> 
> I think the problem is different: there are already people who write
> documentation on how to configure Emacs for tasks. There are also many
> .emacs.d reppositories.
> 
> There are awesome Emacs setups out there, much better than what I have.

Those people need to come here and work with us on integrating their
work into the Emacs documentation set.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: Johan Myréen <johan.myreen@gmail.com>
> Date: Wed, 9 Oct 2024 19:06:12 +0300
> 
> I just started my Emacs (from the main branch) with -q and opened a Rust source file. Emacs out of the box
> does not even recognize the .rs file extension: the file is opened in Fundamental mode.

I explained why we did it like that.  To have the .rs extension
recognized, you need to load rust-ts-mode first.

Emacs tries very hard not to break any user's configuration, and
sometimes that means newcomers have to work harder.

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Richard Stallman wrote:

>> You read the manuals for your TI-83 scientific calculator
>> and Makita impact driver as well?
>
> I have a feeling that question is sarcastic.

Oh, I'm never sarcastic. People never understand what I mean,
here and in life in geneal, just imagine how it would be if
I went around being sarcastic. Now you made me think ...

What I meant was: Does he read ALL tech manuals?

Or just SOME? If he reads some, is it because some stuff is
more complicated or is it because some stuff - that he cares
more for it and is more active with and around it?

> Sarcasm make the point unclear, so it leads to
> misunderstandings and confusion. I don't use either of those
> products, so I can't guess what the point was.
>
> Also, it tends to suggest hostility (even if none is
> actually meant). That often hurts feelings and makes the
> discussion acrimonious.
>
> Therefore we ask people to avoid sarcasm in our discussions.
> See https://gnu.org/philosophy/kind-communication.html.

Yes, I know, and I agree. You could add a paragraph what you
should do when you feel hurt. Not when you feel a lot hurt,
then instinct takes over anyway, but when you go from happy to
sad because of something someone said, be it the thing itself
or how it was formulated and put forward.

The only thing I've come up with is immediately as yourself,
"did this person intend to be a jerk to you?" I have found
that whatever answer you reach, it tends to have removed some
of the hurtness already.

You can also visualize yourself from the outside. You see
a guy with a keyboard, not feeling good, hurting, even, and
you see it is you, but still you have removed yourself from
pain and you can stay out as long as needed, and when you
return, you know about the pain, because it happened, and you
remember it, but you don't FEEL it in the same way.

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

> That's the point, yes: improving the newcomer experience

Good word! Much better than "beginner".

If we have newcomers, where are they, and how are we
communicating with them?

Becuse then I think we should just ask, what problems do
you experience? It is quite possible they have completely
unrelated issues to the ones we think they have.

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 09/10/2024 16:13, Eli Zaretskii wrote:
> rust-ts-mode is part of
> Emacs, and could be turned on automatically when a Rust file is
> visited; we didn't do that because we are unsure whether users of an
> unbundled Rust mode will protest

That seems unlikely: as long as the auto-mode-alist configuration for 
rust-ts-mode is done early on in Emacs's startup, any installed 3rd 
party package such as rust-mode would add its config later, and thus 
have priority.

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Hello, I was asked to send this to this list; it is from our
anonymous IRC fried.

-------------------------------------------------------------

Hi,

Thank you all for your interest in my message, and for taking
time to read it and time to reply. I will try to reply to all
your messages in this single message.

I first thought the implementation I proposed was obvious, so
I kept some space for your suggestions as you know emacs
better than me, but it seems that this brought a lot of
confusions, so this new message will bring all the details
about the implementation so you do not have to guess what
I meant.

I prefer that you keep in mind the main goal (and not the
implementation itself), which is: To make emacs up and running
with a useful configuration (not only as text editor, even
here many customizations can enhance emacs) in a reasonable
time, for almost every situation/scenario for everybody.

What I meant by "everybody" is any potential user, that emacs
can offer him to do what he needs to do (if emacs can do
something, and a user needs to do this thing, then he is
a potential emacs user). He can be dev/non-dev or
beginner/non-beginner, no difference between users.

Users who wants to read the manual first to use emacs, are
already taken care of, and the manual is great. But what about
all the other users ?

I stated in my previous message, that I immediately discarded
to propose the idea of a pre-configured init file
(pre-configured emacs), and this was for many reasons:

1. There are a lot of "elementary" use cases/customizations,
   which new users usually want to start with (only one task
   they need at the very moment). But what if they, just after
   that, want to mix between these to make more "complex" use
   cases/customizations? or even to change a single
   customization which does not suites them in a given
   pre-configuration? This quickly becomes unmanageable.

2. This also has a big problem which is to make everyone agree
   on what are those use cases to provide
   a pre-configuration for.

3. Another big problem is to make everyone agree on what are
   the "defaults" to put in each pre-configuration.

I think, in general, any idea which is very opinionated, will
start a long debate before it eventually fails (wasting lot of
efforts).

4. This will also need extra work to publish and maintain all
   these pre-configurations with their documentations.

Some suggested that this is a documentation problem, and emacs
needs to provide official documentations to customize emacs
for certain tasks. Even though this is a very useful
enhancement to emacs, it is very similar to the idea of
a pre-configured emacs, thus having the same drawbacks listed
above, in addition to leaving the user to do the
pre-configuration himself which brings all discussion to the
beginning (and also adding more documentations for the user to
read).

That is why I suggested the Q&A customization:

1. User can freely customize emacs for any use case (simple or
   complex/combination or even small tweaks).

2. User will customize emacs from the ground up (self cooking,
   with no magic). Hiding details he does not really need to
   know to start using emacs (he will, but this will happens
   later).

3. User will also be able to re-customize emacs (in the same
   way he did at the beginning).

4. emacs defaults are unchanged (avoiding any agreements
   problems).

5. no use cases (pre-configurations) to agree on.

6. no new defaults to be introduced or to agree on.

7. no extra effort to document, publish and maintain any
   pre-configuration (I think this implementation will help
   and encourage users to generate their own
   pre-configurations, for some specific tasks, in a very easy
   way, and start sharing them).

I wrote the implementation in HTML, which you can find at the
end of this message (all the links inside are empty and does
not link to any resources).

Please do not consider the design, fonts, colors and text
content, etc. I am not a designer and I may also have wrote
something wrong about emacs, so feel free to change or
correct anything.

If this implementation does not suites you, you can also
change it, this implementation is provided to have better view
of the main idea.

If this implementation suites you, I think it will need 3
things to be completed:

1. Fill the dots (...) and change/adapt the
   text,colors,links,... that I suggested.

2. List all the questions/customizations to be asked for user,
   and organize them in a hierarchy.

3. Write the code that will collect user input, and configure
   emacs accordingly.

It is not necessary to add all the possible
questions/customizations before making this feature available
in emacs. A useful subset is just fine, and more
questions/customizations can be added gradually later.

The implementation is mainly about 2 parts:

1. part1: "Getting started" (or introduction to emacs).

2. part2: "What is next" (or emacs customization).

For part1’s implementation, I had to modify the actual *GNU
Emacs* startup buffer, so I:

- moved some links to a new *Get Started* buffer (I have
  added).

- kept only what I guess should really be kept.

- modified/added some texts.

- added a "Get Started" link which should open the new *Get
  Started* buffer. (feel free to change the names or anything,
  as stated previously, the names I chose everywhere are only
  for demonstration).

Part1 can be added to emacs as of now, if everybody agree on
of course (with some work to fully complete it), because it is
totally independent from part2, and it enhances user first
experience with emacs. If you want, you can move part1 (part1
HTML) to a separate thread to collect everybody input on
it separately.

I added part2 also inside the same new *Get Started* buffer,
it can be easily moved to a separate *What Is Next* buffer if
needed (in this case a "What is Next" link should be added in
*Get Started* buffer to open the *What Is Next* buffer).

1. part1: Getting Started:

This part is to introduce user to emacs vocabulary/environment
in a very quick way, because emacs vocabulary is very special,
and the ui also like for example the modeline (which is useful
to start using emacs). Only things that user need to know to
start using emacs are to be shown, when the user is satisfied
he will be motivated to read further, and even read the
manual later.

Anything which is not really necessary to start using emacs
like keybindings, packages,..., better be avoided.

Even the minibuffer, that is why I only mentioned the "echo
area", new users does not need to know the difference between
the "echo area" and the minibuffer (if I am not wrong), and
previous emacs users will understand this as well (because the
minibuffer is displayed in the "echo area" anyway). New users
should also not know that they can open multiple frames, to
start using emacs, etc.

The introduction should not only be as short as possible, but
as easy, attractive, entertaining as possible, in other word
non-boring or difficult to understand.

For example when user start clicking on the links and see the
immediate result of his actions, he will continue clicking and
clicking, etc.

From the first time user open emacs, he will be guided, and
start clicking and clicking, and in about 20 to 25
entertaining clicks and 5 to 10min reading, he will be
familiar with emacs, and feels he can do something useful,
without even noticing the time he spent there.

This part is not fully completed (almost completed), but is
enough to give you a very clear idea. This part is also needed
for the part2 ("customizations" part), as the user cannot be
asked if he wants to remember the windows positions, without
him knowing what a window is in the first place. etc (even if
user is familiar with similar softwares, emacs has a special
vocabulary, as stated above, that user needs to know before
using/customizing emacs).

2. part2: What is next (the "customization" part):

This part can be moved to a separate dedicated *What Is Next*
buffer, if it is better, as stated above.

This part is also already described in my previous message (If
you landed here directly, I encourage you to read the first
message
https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00018.html).

This part give a user a fast way to customize emacs to his
needs, by asking him questions.

This is somehow similar to the idea of the actual "Customize
Startup" link located in the actual *GNU Emacs* startup
buffer, but this actual link contains only a very limited
subset and are also not beginner friendly (lot of advanced
vocabulary that needs user to read the manual first).

This is also similar to https://emacs.amodernist.com/
I mentioned in my previous message.

I also prefer this "customization" part to be questions asked
in the minibuffer if possible, and not a a sequence of buffers
with long texts, checkboxes, buttons, fields,..., like the
"customization interface".

This is just a personal preference, if you think this is not
possible or not user friendly or any other reason, it is ok.
If this will cause agreement issues, then maybe both can be
added, and let the user choose which one he wants to use (if
the ui interface is chosen/implemented, it will be very easy
to implement the Q&A in the minibuffer anyway).

It is basically a hierarchy of questions with the top level
questions being let say around 10, so when the user click the
"Start customizing Emacs" link (I added), he needs to press
the "Enter" key 10 times to know what he can do with emacs
(ui/themes, basic editing, communication suite, development,
org, ...), and only when the user chose to customize
something, he will be asked the corresponding next level
questions, also the next level questions should be as few as
possible, and the next level questions too, etc...

Similar to the "customization interface" hierarchy but using
more generic and beginner friendly terms, and proposing
features which can be found in GNU ELPA archive packages
(without the user having to know about packages, and use the
actual "package interface" to discover new packages and
install them manually, etc.)

When the user is satisfied, he will be motivated to read the
manual later and know more about emacs.

Imagine a developer who needs a code editor with a LSP client,
and he does not know anything at all about emacs and also
about some other editor. Compare the time he needs to use
emacs as a LSP client with auto-complete, and the time he
needs to use the other editor as LSP client with
auto-complete. He needs to spend at least days, if not weeks
to understand many things about emacs and have something
useful to work with.

This is just one and a very simple example among many.

This is not to mention all the compile errors when installing
a package sometimes, ..., and if he wants to customize emacs
by editing the init file directly, how many times emacs will
start with a blank page with an error, because he forgets
a single parentheses somewhere, and he finds himself totally
blocked, ... , this is not to mention too the packages that
are really useful to first use emacs specially for beginners,
like undo-tree, vertico+orderless if they want to read about
and use the minibuffer directly, ...).

All these times spent by previous emacs users, and that will
be spent by new emacs users, can be easily avoided, and maybe
converted into contributing to emacs. The thing is that you
need to encourage users to start using emacs in the first
place, by lowering the entry barrier, and many of them will
sooner or later go and read the manual, and know more about
emacs, and contribute to add some functionalities they need
and/or correct a bug they are facing, but if users are
discarded from the beginning, this is not good.

Some users may instead be interested in (or prefer) reading
the manual first, and using the customization interface or
manually editing the init file, why not, but even here, many
do not have enough time to do that, so they let it go.

That is why I think this feature is very useful. I may be
wrong, or I may have missed something.

I am not saying that users should not use the "customization
interface" or edit the init file directly. I only think that
the entry barrier to emacs is too high (to discourage most
users), and can be easily lowered.

This will not only be for beginners, even people who are
already using emacs can use it. There will be 3 ways to
configure emacs:

- customization interface.

- editing the init file directly.

- this new feature.

This feature can contains advanced customizations of course
(for example that needs user to read emacs manual or any other
documentation before using them), but they will be hidden
behind questions like "Do you want to customize IRC client
(yes/no) ?":

- users who does not know anything about IRC and not
  interested will choose "no".

- interested users will go to read about IRC to know more
  about it and come back later. They can even choose "yes" to
  see what are the next questions (without affecting emacs).

- and users who already know about IRC, will choose "yes", and
  will know how to answer the next questions and how to use
  IRC afterwards.

Thank you all for you time,

<!DOCTYPE html>
<html>
<head>
<style>
.ui {
  background-color: lightskyblue;
  color: #fff;
  display: inline-block;
  padding: 0px 3px;
  border-radius: 3px;
}

.action {
  background-color: lightgrey;
  color: #fff;
  display: inline-block;
  padding: 0px 3px;
  border-radius: 3px;
}
</style>
</head>
<body>

<span>[*GNU Emacs* buffer START]</span>
<div id="GNU Emacs">
<hr></hr>
<h1 style="text-align:center;">[EMACS LOGO]</h1>
<h2 style="text-align:center;">Welcome to GNU Emacs</a></h2>

<p style="color: #ff0000;">Welcome to <a href="">GNU Emacs</a>, one component of the <a href="">GNU/Linux</a> operating system.</p>

<h3>Before getting started, you may want to check:</h3>
<ol style="list-style: none; font-size: 14px; line-height: 32px; font-weight: bold;">
<li> <a href="">Absence of Warranty </a> GNU Emacs comes with ABSOLUTELY NO WARRANTY</li>
<li> <a href="">Copying Conditions</a> Conditions for redistributing and changing Emacs</li>
</ol>

<h2 style="text-align:center;"><a href="">Get Started</a></h2>
<p>This is GNU Emacs version ... build ...<br/>
Copyright (C) ... Free Software Foundation, Inc.<p>
<hr></hr>
</div>
<span>[*GNU Emacs* buffer END]</span>

<br></br>
<br></br>
<br></br>

<span>[*Get Started* buffer START]</span>
<div id="Get Started">
<hr></hr>
<h2 style="text-align:center;">Getting Started</h2>

<p>You can click on the words highlighted in <span class="ui">blue</span> to locate the corresponding item on the screen.<br/>
You can click on the words highlighted in <span class="action">grey</span> to execute the corresponding action.</p>

<p>The text you are actually reading, is displayed in a <a href="" class="ui">window</a></p>

<p>This window is inside a <a href="" class="ui">frame</a>.</p>

<p>You can open multiple windows inside a frame. For example, to open a new window to the right, you can click on the menu item <a href="" class="action">New Window on Right</a> inside the "File" menu in the <a href="" class="ui">menu bar</a> located at the top of the frame. Each menu item will execute a specific emacs "command" to accomplish a specific task. To close a window you can ... . If you accidently closed this window you can .... or you can close and open emacs again.</p>

<p>The menu bar contains all the commands you need to accomplish all kind of tasks in emacs.</p>

<p>In case you changed your mind and want to cancel a command you have already initiated, you need to press the "g" key while pressing and holding the "Control" key on your keyboard (C-g). You can also press this key combination if you think that a command is taking too much time to complete or is making emacs unresponsive to other commands you are trying to initiate.</p>

<p>You may have noticed that when you opened the new window, a message was displayed in the bar at the bottom of the frame. This bar is called the <a href="" class="ui">echo area</a>. Every action in emacs results in a brief message so you can ... . This message will disappear after a short time or when ... </p>

<p>Some commands you execute may need further input from your side, for example if you execute the search command to search for a specific word or phrase in a specific buffer, you need to provide the word or phrase you are are searching for. When you execute such commands, a brief and persistent message is displayed in the echo area which ends with a colon ":", showing what the command is expecting as input from your side. In this case it is the "Search for string:" message which is inviting you to enter the word or phrase you are searching for. You need to enter these directly after the colon ":". If you want to cancel the search command you need to press (C-g) as describe earlier. If you need to use the search command, you may want to read the documentation about it first in ... .</p>

<p>Each command is documented and you can find its documentation by clicking on ... &lt;&lt;<span style="background-color:yellow">user needs a simple way to access this. Same as clicking on [Help->Describe->Describe Key or Mouse Operation] then selecting the command (he wants) in the menubar (Without using keybindings or using the minibuffer)</span>&gt;&gt;</p>

<p> You can work inside a single window at a time, the one having the focus, this is usually indicated by a blinking <a href="" class="ui">cursor.</a> The cursor is also known as "point" and indicates where the text you are going to type will be inserted.</p>

<p> Each window display a single file content which is called <a href="" class="ui">buffer</a>. To open a new file in the right window, you need to click inside the right window first, to get the focus, and then click on the <a href="" class="ui">"New File" icon</a> in the <a href="" class="ui">toolbar</a>.</p>

<p>The toolbar contains some of the menubar commands for a quick and convenient access.</p>

<p>To close the file displayed in the right window, you need to ... but this will not close the window itself, to close the window you need to repeat the same step described earlier. Closing a window will not close the buffer displayed inside, the buffer will remain opened in emacs and you can display it again in any other window you want.</p>

<p>You can also open some special emacs buffers in a window, like the <a href="" class="action">*Messages*</a> buffer which displays ... and the <a href="" class="action">*Errors*</a> buffer which displays ... . If you encounter any error you may want to search ... first, or send an email to ... or join the IRC channel ... , or ...</p>

<p> Emacs special buffers names are always surrounded by **. The buffer you are actually reading is named *Get Started* as you can see in the <a href="" class="ui">modeline</a>. This buffer replaced the previous buffer that was opened in this window when you first started emacs and which was called <a href="" class="action">*GNU Emacs*</a> (also known as the startup buffer).</p>

<p>Each window has its own modeline. The modeline is used to display ... <a href="" class="ui">flag1</a> ... <a href="" class="ui">flag2</a> ... <a href="" class="ui">buffer name</a> ... <a href="" class="ui">buffer modes ...</a></p>

<p>This is all you need to get started using emacs.</p>

<p>If you want to learn more, you can read the manual:</p>
<ol style="list-style: none; font-size: 15px; line-height: 32px; font-weight: bold;">
<li> <a href="">View Emacs Manual</a>  View the Emacs manual using Info</li>
<li> <a href="">Ordering Manuals</a>   Purchasing printed copies of manuals</li>
</ol>
<p>You may also want to check:</p>
<ol style="list-style: none; font-size: 15px; line-height: 32px; font-weight: bold;">
<li> <a href="">Emacs Tutorial</a>  Learn basic keystroke commands</li>
</ol>

<h2 style="text-align:center;">What is next</h2>

<p>Now that you are familiar with emacs environment, and ready to start using emacs, you may want to customize emacs first to suites your specific needs.</p>

<p>You can customize everything in emacs. For example you can hide the toolbar, the menu bar, the modeline, you can change the items displayed in the modeline, you can change the startup buffer, you can choose to automatically save the files you are editing, and choose when they got saved, you may want to automatically keep a backup of these files too, ...</p>

<p>The following link will help you do that, and in the same time you will be discovering the mostly used features in emacs, you can also have an overview of some of these features in the <a href="">Emacs Guided Tour</a> at gnu.org.</p>

<p>Clicking on this link will execute a command like the ones you initiate from the menubar or the toolbar. This command needs further input from your side for each customization, which you will have to enter in the echo area as usual.</p>

<p>All the customizations have a pre-selected value, you can hit the "Enter" key to keep this value, or you can chose another value ....</p>

<p>You can repeat this step as much as you need, to re-customize emacs, or even to check what are the values for certain customizations. The values in green are the values you have never changed (emacs defaults), the values in red are the ones you have already changed, in a previous run, to a non-default value.</p>

<p>All the customizations will be stored under .... in case you want to backup your customizations, or you want to use the same customizations for another emacs instance running on a different device, without having to repeat this step again.</p>

<h3 style="text-align:center;"><a href="">Start Customizing emacs</a></h3>

<p>If you need a more advanced customizations, or you want to know what other features emacs can offer, you may want to read the emacs manual first, and then use the more advanced <a href="">customization interface.</a></p>

<hr></hr>
</div>
<span>[*Get Started* buffer END]</span>

</body>
</html>

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Thu, 10 Oct 2024 00:25:40 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 09/10/2024 16:13, Eli Zaretskii wrote:
> > rust-ts-mode is part of
> > Emacs, and could be turned on automatically when a Rust file is
> > visited; we didn't do that because we are unsure whether users of an
> > unbundled Rust mode will protest
> 
> That seems unlikely: as long as the auto-mode-alist configuration for 
> rust-ts-mode is done early on in Emacs's startup, any installed 3rd 
> party package such as rust-mode would add its config later, and thus 
> have priority.

I don't have objections to making Rust recognized automatically and
activating rust-ts-mode, if people think this danger is low or
non-existent, and if *.rs files are not commonly used for something
completely unrelated (e.g., I see on my Windows system quite a few
*.rs files that seem to be some kind of Windows data files).

Re: An anonymous IRC user's opinion

[Xiyue Deng]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 10 Oct 2024 00:25:40 +0300
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 09/10/2024 16:13, Eli Zaretskii wrote:
>> > rust-ts-mode is part of
>> > Emacs, and could be turned on automatically when a Rust file is
>> > visited; we didn't do that because we are unsure whether users of an
>> > unbundled Rust mode will protest
>> 
>> That seems unlikely: as long as the auto-mode-alist configuration for 
>> rust-ts-mode is done early on in Emacs's startup, any installed 3rd 
>> party package such as rust-mode would add its config later, and thus 
>> have priority.
>
> I don't have objections to making Rust recognized automatically and
> activating rust-ts-mode, if people think this danger is low or
> non-existent, and if *.rs files are not commonly used for something
> completely unrelated (e.g., I see on my Windows system quite a few
> *.rs files that seem to be some kind of Windows data files).
>

One thing to be cautious is that all *-ts-modes require tree-sitter
syntax libraries to be available to use, which are not shipped with
Emacs.

One can follow the instructions on masteringemacs[1], or install
treesit-auto[2] to install tree-sitter syntax libraries, which are not a
lot of trouble but may still be more work than a new comer would expect.

[1] https://www.masteringemacs.org/article/how-to-get-started-tree-sitter
[2] https://github.com/renzmann/treesit-auto

-- 
Regards,
Xiyue Deng

Re: An anonymous IRC user's opinion

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

>> My analysis is different. Emacs lacks volunteers who'd sit
>> down and write documentation on how to configure Emacs for
>> this or that job.
>
> I think the problem is different: there are already people
> who write documentation on how to configure Emacs for tasks.
> There are also many .emacs.d reppositories.
>
> There are awesome Emacs setups out there, much better than
> what I have.
>
> What's missing is a way to integrate these efforts into
> Emacs so new users can benefit from them.

100%!

Before I write a `defun', I always think, did someone else
already write this exact defun - in Emacs, in GNU ELPA, on
some -hub or some homepage, anywhere?

And the answer is always, "I don't know".

And then I ask: "Okay, but how do I find out then?"

"I don't know."

-- 
underground experts united
https://dataswamp.org/~incal

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: Xiyue Deng <manphiz@gmail.com>
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> Date: Wed, 09 Oct 2024 22:14:32 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Thu, 10 Oct 2024 00:25:40 +0300
> >> Cc: emacs-devel@gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >> 
> >> On 09/10/2024 16:13, Eli Zaretskii wrote:
> >> > rust-ts-mode is part of
> >> > Emacs, and could be turned on automatically when a Rust file is
> >> > visited; we didn't do that because we are unsure whether users of an
> >> > unbundled Rust mode will protest
> >> 
> >> That seems unlikely: as long as the auto-mode-alist configuration for 
> >> rust-ts-mode is done early on in Emacs's startup, any installed 3rd 
> >> party package such as rust-mode would add its config later, and thus 
> >> have priority.
> >
> > I don't have objections to making Rust recognized automatically and
> > activating rust-ts-mode, if people think this danger is low or
> > non-existent, and if *.rs files are not commonly used for something
> > completely unrelated (e.g., I see on my Windows system quite a few
> > *.rs files that seem to be some kind of Windows data files).
> >
> 
> One thing to be cautious is that all *-ts-modes require tree-sitter
> syntax libraries to be available to use, which are not shipped with
> Emacs.

If a required grammar library is not available, the user gets a
warning.  So what is the problem here?

Re: An anonymous IRC user's opinion

[Xiyue Deng]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Xiyue Deng <manphiz@gmail.com>
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> Date: Wed, 09 Oct 2024 22:14:32 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Thu, 10 Oct 2024 00:25:40 +0300
>> >> Cc: emacs-devel@gnu.org
>> >> From: Dmitry Gutov <dmitry@gutov.dev>
>> >> 
>> >> On 09/10/2024 16:13, Eli Zaretskii wrote:
>> >> > rust-ts-mode is part of
>> >> > Emacs, and could be turned on automatically when a Rust file is
>> >> > visited; we didn't do that because we are unsure whether users of an
>> >> > unbundled Rust mode will protest
>> >> 
>> >> That seems unlikely: as long as the auto-mode-alist configuration for 
>> >> rust-ts-mode is done early on in Emacs's startup, any installed 3rd 
>> >> party package such as rust-mode would add its config later, and thus 
>> >> have priority.
>> >
>> > I don't have objections to making Rust recognized automatically and
>> > activating rust-ts-mode, if people think this danger is low or
>> > non-existent, and if *.rs files are not commonly used for something
>> > completely unrelated (e.g., I see on my Windows system quite a few
>> > *.rs files that seem to be some kind of Windows data files).
>> >
>> 
>> One thing to be cautious is that all *-ts-modes require tree-sitter
>> syntax libraries to be available to use, which are not shipped with
>> Emacs.
>
> If a required grammar library is not available, the user gets a
> warning.  So what is the problem here?

Then a user doesn't really getting a useful major mode for editing Rust
files or other programming files when using their *-ts-mode (without
their grammar installed, that is).

Other non-ts based modes, though less accurate, are readily usable after
`M-x package-install', which IMHO is slightly more new user friendly.

Of course, if Emacs provide a built-in way to install the grammar
libraries automatically that would be better.

-- 
Regards,
Xiyue Deng

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Wed, 09 Oct 2024 23:55:16 +0200
> 
> Hello, I was asked to send this to this list; it is from our
> anonymous IRC fried.

Thanks.

> The implementation is mainly about 2 parts:
> 
> 1. part1: "Getting started" (or introduction to emacs).

This is basically an alternative to TUTORIAL.  It describes the Emacs
basics in a different order than the tutorial, and I'm not sure which
one is better.  The advantage of this method is that it's shorter and
introduces the basic concepts right away; the disadvantage is that the
description is necessarily much more abstract, and almost nothing in
it requires the reader to _do_ anything, which IME tends to bore and
lose the reader's attention.

> 2. part2: "What is next" (or emacs customization).
> 
> For part1’s implementation, I had to modify the actual *GNU
> Emacs* startup buffer, so I:
> 
> - moved some links to a new *Get Started* buffer (I have
>   added).
> 
> - kept only what I guess should really be kept.
> 
> - modified/added some texts.
> 
> - added a "Get Started" link which should open the new *Get
>   Started* buffer. (feel free to change the names or anything,
>   as stated previously, the names I chose everywhere are only
>   for demonstration).

I'm probably missing something because in the HTML you posted this
part is basically empty.  It mentions Customize in general terms, but
that's _how_ to customize Emacs, not _what_ to customize.  How is the
user supposed to know which variables/features to customize?

What did I miss?

> 1. part1: Getting Started:
> 
> This part is to introduce user to emacs vocabulary/environment
> in a very quick way, because emacs vocabulary is very special,
> and the ui also like for example the modeline (which is useful
> to start using emacs). Only things that user need to know to
> start using emacs are to be shown, when the user is satisfied
> he will be motivated to read further, and even read the
> manual later.
> 
> Anything which is not really necessary to start using emacs
> like keybindings, packages,..., better be avoided.
> 
> Even the minibuffer, that is why I only mentioned the "echo
> area", new users does not need to know the difference between
> the "echo area" and the minibuffer (if I am not wrong), and
> previous emacs users will understand this as well (because the
> minibuffer is displayed in the "echo area" anyway). New users
> should also not know that they can open multiple frames, to
> start using emacs, etc.
> 
> The introduction should not only be as short as possible, but
> as easy, attractive, entertaining as possible, in other word
> non-boring or difficult to understand.

That's a tough ticket.  There's so much in the Emacs display that is
or might be important that explaining it in a short text is hard, if
not impossible.  For example, the description you posted doesn't
mention the scroll bars, and the description of the mode line is only
hinted upon; filling that with actual information will likely make it
much longer.  I think we'd most welcome attempts to do what you are
trying to do, but it isn't easy.

> 2. part2: What is next (the "customization" part):
> 
> This part can be moved to a separate dedicated *What Is Next*
> buffer, if it is better, as stated above.
> 
> This part is also already described in my previous message (If
> you landed here directly, I encourage you to read the first
> message
> https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00018.html).
> 
> This part give a user a fast way to customize emacs to his
> needs, by asking him questions.

This is an idea that has come up before, more than once.  I think
everyone agrees that it's a good idea.  The hard part in this is to
come up with a good sequence of questions, which would address
different usage patterns that Emacs can support.  I don't think I've
seen any attempts to do this which are close to completion, I only saw
this idea being described and discussed, and a few attempts to produce
a starting point.  If you can post the more-or-less full list of
questions (which will probably be a tree or a DAG, not a linear list,
since the user should be asked quite early what are his/her needs that
they want to accomplish with Emacs, and perhaps also what are their UI
preferences.), please do: I think this could be a very good step in
the right direction.

> This is somehow similar to the idea of the actual "Customize
> Startup" link located in the actual *GNU Emacs* startup
> buffer, but this actual link contains only a very limited
> subset and are also not beginner friendly (lot of advanced
> vocabulary that needs user to read the manual first).
> 
> This is also similar to https://emacs.amodernist.com/
> I mentioned in my previous message.

I think https://emacs.amodernist.com/ is a good starting point, but
IMO it is nowhere near being complete.  I see the following ways to
improve it:

  . More background information on the features it asks about, so the
    readers could make up their minds about using them.  For example,
    it asks about Org without actually telling much about it: how is
    the reader supposed to know ehether he/she wants it?  It generally
    assumes that the readers already know what they want and need just
    to be pointed to the Emacs feature which implements some
    functionality.  A good example is "Version Control" -- are we sure
    everyone knows what this is about?
  . It leaves out many popular and important features in Emacs.  One
    notable example is email; another is access to remote files; yet
    another is debugging and the built-in GDB front-end; etc. etc.
  . The "Miscellaneous" section at the end is a very small subset of
    convenience features Emacs offers, and should be greatly expanded
    and classified into groups (otherwise it will be a very large
    unsorted list of unrelated settings, which will be hard to read
    and understand).  It also needs to describe each feature in more
    than just a single sentence.

> I also prefer this "customization" part to be questions asked
> in the minibuffer if possible, and not a a sequence of buffers
> with long texts, checkboxes, buttons, fields,..., like the
> "customization interface".

If you want to code a customization interface that is based on asking
questions, then doing that for complex values might be difficult or
cumbersome.  As a simple example, how do you propose to let users to
customize a face by asking questions instead of having checkboxes and
fields?  The basic disadvantage of asking one question at a time is
that the user doesn't see the whole picture, and also that there's no
easy way of going back to a previous question and answering it in a
different way.

> Imagine a developer who needs a code editor with a LSP client,
> and he does not know anything at all about emacs and also
> about some other editor. Compare the time he needs to use
> emacs as a LSP client with auto-complete, and the time he
> needs to use the other editor as LSP client with
> auto-complete. He needs to spend at least days, if not weeks
> to understand many things about emacs and have something
> useful to work with.

If a developer already knows about LSP, and already decided LSP server
is the best solution for what the developer has in mind, then yes.
But what if the developer doesn't know about the alternatives Emacs
provides that don't require an LSP client?  Setting up an LSP server
is not a trivial task, so if Emacs provides an alternative, the
customization helper you describe should give enough information for
the developer to consider these alternatives and make up his/her mind
about the one best for him/her.  E.g., many people don't know about
etags and the many languages it supports, or about ElDoc and its
backends other than LSP-driven Eglot.  IMO, the customization wizard
should mention those.

> Some users may instead be interested in (or prefer) reading
> the manual first, and using the customization interface or
> manually editing the init file, why not, but even here, many
> do not have enough time to do that, so they let it go.

We don't recommend reading the manual in its entirety anywhere.
Instead, we recommend reading those chapters and sections in the
manual that are relevant to the job in hand.  The manuals are well
indexed and organized to allow this method and to make it
time-efficient for our users.

Thanks again for working on these important aspects of Emacs.

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Emanuel Berg <incal@dataswamp.org> writes:

>> Therefore we ask people to avoid sarcasm in our discussions.
>> See https://gnu.org/philosophy/kind-communication.html.
>
> Yes, I know, and I agree. You could add a paragraph what you
> should do when you feel hurt.

That is a good point, though not a simple one.

> "did this person intend to be a jerk to you?"

That’s the common method of "putting yourself in their shoes".

I just checked if nonviolent communication could be an option, but that
doesn’t fit:
https://en.wikipedia.org/wiki/Nonviolent_Communication#Components

And sadly there’s no Englisch version of the page about Streitkultur:
https://de.wikipedia.org/wiki/Streitkultur#Streitkultur_lernen

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Eli Zaretskii <eliz@gnu.org> writes:
>> This is also similar to https://emacs.amodernist.com/
>> I mentioned in my previous message.
>
> I think https://emacs.amodernist.com/ is a good starting point, but
> IMO it is nowhere near being complete.  I see the following ways to
> improve it:
>
>   . More background information on the features it asks about, so the

This is an indication that asking is the wrong approach.

We can only ask questions that users can give an informed answer to. If
we need more than a few words to give that information, then asking the
users puts an undue strain on them.

If questions require lots of reading to understand the answers (or their
implications), we should provide a default and enable already informed
users to deviate from the default. And maybe provide links for further
reading for those who want to dig.

To avoid causing problems to those who want to tinker, an option like
"minimalistic" could help. That would disable all potentially
conflicting customizations.

> Setting up an LSP server is not a trivial task, so if Emacs provides
> an alternative, the customization helper you describe should give
> enough information for the developer to consider these alternatives
> and make up his/her mind about the one best for him/her.

Also my experience with the difference between js2-mode and the
typescript (ts) lsp is that js2-mode is much, much more enjoyable to
use, because it feels instantaneous while the lsp always causes delays.

But js2-mode only works for Javascript (maybe with jsdoc), but not for
Typescript. That’s why I know the difference.

I don’t know whether it is the same for other lsp servers and their
provided alternatives, but if it is, then suggesting an lsp may not be
the best.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: emacs-devel@gnu.org
> Date: Thu, 10 Oct 2024 11:35:12 +0200
> 
> If questions require lots of reading to understand the answers (or their
> implications), we should provide a default and enable already informed
> users to deviate from the default. And maybe provide links for further
> reading for those who want to dig.

That's basically what we already do: our defaults are set up like
that, except that we are very conservative with changing them, and so
might decide to adapt to some changes quite some time after the
changes happened.

Re: An anonymous IRC user's opinion

[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. ]]]

  > We generally try to make all sorts of packages for various uses of
  > Emacs coexist in a single Emacs job.  I get the impression people are
  > assuming that these different configurations are mutually incompatible,
  > so that it is necessary to choose which one to install.

  > Is that what people assume?  If people do, why so?  Why can't
  > users select one at run time?

In general we make it possible for a single Emacs job to
contain various different configurations at the same time,
and the user can switch between them,  Usually it is controlled
by which buffer is current.

Am I right in thinking that Spacemacs and Doom require the
user to choose at an earlier stage?  Or did the descriptions
posted here give me the wrong impression?

If I understood that point correctly, is there any inherent reason why
we could not in Emacs offer the sorts of configurations that Spacemacs
and Doom do, but designed such that they can coexist in a single Emacs
job, perhaps with the current buffer controlling which one is active?

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

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Richard Stallman <rms@gnu.org> writes:

> Am I right in thinking that Spacemacs and Doom require the
> user to choose at an earlier stage?  Or did the descriptions
> posted here give me the wrong impression?

At least Doom provides collections of packages for specific tasks.
That way it’s a bit more abstract — but maintenance of parts of the
configuration is shifted from the user to Doom.

The downside of that is that a friend who used it regularly complained
that after updating Doom, the configuration was broken, so I do not
think that just copying that model would be a good idea.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 10/10/2024 07:56, Eli Zaretskii wrote:
>> That seems unlikely: as long as the auto-mode-alist configuration for
>> rust-ts-mode is done early on in Emacs's startup, any installed 3rd
>> party package such as rust-mode would add its config later, and thus
>> have priority.
> I don't have objections to making Rust recognized automatically and
> activating rust-ts-mode, if people think this danger is low or
> non-existent, and if *.rs files are not commonly used for something
> completely unrelated (e.g., I see on my Windows system quite a few
> *.rs files that seem to be some kind of Windows data files).

Actually, thinking back the last time we made such a move, we got a 
report from a user who preferred to have files in question (*.toml) in 
fundamental-mode, because they didn't want the hassle of installing the 
toml tree-sitter grammar (bug#60559).

The said user didn't have Emacs compiled with tree-sitter, so if we 
wanted to revisit that issue, we could enable ts mode globally when 
Emacs is compiled with that support, and when it isn't, keep them out of 
auto-mode-alist.

That could still lead to inconveniences sometimes, but at the very least 
it would follow the reporter's request from down the thread:

> If emacs was configured with tree-sitter, it seems productive to
warn the user when tree-sitter grammars are missing.  It seems
likely that user intended to have tree-sitter.

> When emacs is NOT configured with tree-sitter, it seems
counter-productive to warn about missing tree-sitter.

> I even pass --without-tree-sitter to configure now.  It seems
particularly surprising to me that I explicitly tell emacs "don't
use tree-sitter" and then it immediately starts complaining to me
that it doesn't have tree-sitter.

Re: An anonymous IRC user's opinion

[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. ]]]

  > The downside of that is that a friend who used it regularly complained
  > that after updating Doom, the configuration was broken, so I do not
  > think that just copying that model would be a good idea.

I'm simply trying to clarify what sort of feature we are aiming for.
How to implement it would ne the next question, and since I don't know
anything about how Doom implements it, I am not arguing for or against
using the same approach.

Once we have it clear what features we want, we can come up with a good
implementation.

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

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Fri, 11 Oct 2024 23:30:12 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> 
> On 10/10/2024 07:56, Eli Zaretskii wrote:
> >> That seems unlikely: as long as the auto-mode-alist configuration for
> >> rust-ts-mode is done early on in Emacs's startup, any installed 3rd
> >> party package such as rust-mode would add its config later, and thus
> >> have priority.
> > I don't have objections to making Rust recognized automatically and
> > activating rust-ts-mode, if people think this danger is low or
> > non-existent, and if *.rs files are not commonly used for something
> > completely unrelated (e.g., I see on my Windows system quite a few
> > *.rs files that seem to be some kind of Windows data files).
> 
> Actually, thinking back the last time we made such a move, we got a 
> report from a user who preferred to have files in question (*.toml) in 
> fundamental-mode, because they didn't want the hassle of installing the 
> toml tree-sitter grammar (bug#60559).
> 
> The said user didn't have Emacs compiled with tree-sitter, so if we 
> wanted to revisit that issue, we could enable ts mode globally when 
> Emacs is compiled with that support, and when it isn't, keep them out of 
> auto-mode-alist.

If we want to be selective, we should also check if the grammar
library is installed.

Or we could tell the user, when a Rust file is first visited and the
grammar is not available, that we recommend to install the grammar.

Either way, this is not very trivial, and someone should do the work
of designing the best UI and coding it.

> > I even pass --without-tree-sitter to configure now.  It seems
> particularly surprising to me that I explicitly tell emacs "don't
> use tree-sitter" and then it immediately starts complaining to me
> that it doesn't have tree-sitter.

Feel free to improve what we have.  My point is that it is not very
trivial; what we have is basically a compromise, which could be
improved, at least for some languages, if we want to be smarter.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 12/10/2024 10:34, Eli Zaretskii wrote:

>> Actually, thinking back the last time we made such a move, we got a
>> report from a user who preferred to have files in question (*.toml) in
>> fundamental-mode, because they didn't want the hassle of installing the
>> toml tree-sitter grammar (bug#60559).
>>
>> The said user didn't have Emacs compiled with tree-sitter, so if we
>> wanted to revisit that issue, we could enable ts mode globally when
>> Emacs is compiled with that support, and when it isn't, keep them out of
>> auto-mode-alist.
> 
> If we want to be selective, we should also check if the grammar
> library is installed.
> 
> Or we could tell the user, when a Rust file is first visited and the
> grammar is not available, that we recommend to install the grammar.

Telling that the grammar is not installed is still useful. Even if we 
say "grammar xyz not available" only once per session, we still have to 
decide whether the major mode switch happens (with perhaps reduced 
features - such as non-working indentation/font-lock/etc, but with for 
example Eglot recognizing the file type now).

> Either way, this is not very trivial, and someone should do the work
> of designing the best UI and coding it.
> 
>>> I even pass --without-tree-sitter to configure now.  It seems
>> particularly surprising to me that I explicitly tell emacs "don't
>> use tree-sitter" and then it immediately starts complaining to me
>> that it doesn't have tree-sitter.
> 
> Feel free to improve what we have.  My point is that it is not very
> trivial; what we have is basically a compromise, which could be
> improved, at least for some languages, if we want to be smarter.

The proposal I'm quoting is straightforward: if Emacs is compiled with 
tree-sitter support, enable the modes and warn when the grammars are not 
available. If Emacs is not compiled with tree-sitter, do neither.

That kind of rule has predictability: for example if the grammar was not 
installed originally but the user did that while Emacs was running, the 
corresponding major mode will start working the next time the user tries 
to enable it. That wouldn't be the case if we conditionally alter 
auto-mode-alist based on grammar availability.

The above approach should be quite easy to implement, if there's 
agreement to it. Otherwise, the issue is about choosing the details of 
the UI first.

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Dmitry Gutov <dmitry@gutov.dev> writes:

> The proposal I'm quoting is straightforward: if Emacs is compiled with
> tree-sitter support, enable the modes and warn when the grammars are
> not available. If Emacs is not compiled with tree-sitter, do neither.

This sounds like having external grammars is a UX problem.

Are they so big that they cannot be included?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[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. ]]]

  > I think https://emacs.amodernist.com/ is a good starting point, but
  > IMO it is nowhere near being complete.

That site looks like a good approach to me, but we should beware of trying
to make it "complete", because that would make it so many questions
thta it would overload beginners, and even not-quite-beginners.
It needs to selectively show only fairly important options.

It should limit itself to things that  are part of Emacs: core and GNU
ELPA.  Things that we recommend in Emacs should not depend on packages
in NonGNU ELPA.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Sat, 12 Oct 2024 23:27:01 +0300
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > Feel free to improve what we have.  My point is that it is not very
> > trivial; what we have is basically a compromise, which could be
> > improved, at least for some languages, if we want to be smarter.
> 
> The proposal I'm quoting is straightforward: if Emacs is compiled with 
> tree-sitter support, enable the modes and warn when the grammars are not 
> available. If Emacs is not compiled with tree-sitter, do neither.
> 
> That kind of rule has predictability: for example if the grammar was not 
> installed originally but the user did that while Emacs was running, the 
> corresponding major mode will start working the next time the user tries 
> to enable it. That wouldn't be the case if we conditionally alter 
> auto-mode-alist based on grammar availability.
> 
> The above approach should be quite easy to implement, if there's 
> agreement to it. Otherwise, the issue is about choosing the details of 
> the UI first.

It is not clear which modes you suggest that should behave like that.
Surely, not all of them, i.e. including those for which non-TS modes
are part of Emacs?

And yes, I would like to hear from more people what they think about
the possible behaviors in these cases, including how to handle missing
grammar libraries.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  johan.myreen@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 12 Oct 2024 23:00:16 +0200
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > The proposal I'm quoting is straightforward: if Emacs is compiled with
> > tree-sitter support, enable the modes and warn when the grammars are
> > not available. If Emacs is not compiled with tree-sitter, do neither.
> 
> This sounds like having external grammars is a UX problem.

It is a UI problem because users could have a TS-enabled Emacs, but
not grammar libraries for the language(s) he/she wants to edit.  The
problem in that case is how to present this situation to the user.

> Are they so big that they cannot be included?

They are not large, but they are written in C or C++ and are developed
by their own teams in their own repositories.  They are also a lot
when taken together (e.g., my personal collection includes more than
70 grammar libraries, and even what we have in core needs almost 20
different libraries).  So we cannot distribute them as part of Emacs
source tarballs.

If you are talking about what downstream Emacs distros do for
packaging, that's a separate issue on which we have no control.  But
if a distro packages grammar libraries, it could also enable the
corresponding modes in their customizations of Emacs.

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Are they so big that they cannot be included?
>
> They are not large, but they are written in C or C++ and are developed
> by their own teams in their own repositories.  They are also a lot
> when taken together (e.g., my personal collection includes more than
> 70 grammar libraries, and even what we have in core needs almost 20
> different libraries).  So we cannot distribute them as part of Emacs
> source tarballs.

Then that’s technical and organisatorial; sounds like we have to live
with that for now.

I wasn’t aware that it’s so much. Thank you for explaining!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 13/10/2024 07:41, Eli Zaretskii wrote:

>> The proposal I'm quoting is straightforward: if Emacs is compiled with
>> tree-sitter support, enable the modes and warn when the grammars are not
>> available. If Emacs is not compiled with tree-sitter, do neither.
>>
>> That kind of rule has predictability: for example if the grammar was not
>> installed originally but the user did that while Emacs was running, the
>> corresponding major mode will start working the next time the user tries
>> to enable it. That wouldn't be the case if we conditionally alter
>> auto-mode-alist based on grammar availability.
>>
>> The above approach should be quite easy to implement, if there's
>> agreement to it. Otherwise, the issue is about choosing the details of
>> the UI first.
> 
> It is not clear which modes you suggest that should behave like that.
> Surely, not all of them, i.e. including those for which non-TS modes
> are part of Emacs?

I don't have a strong opinion on which set should be enabled - maybe 
just all TS modes which we don't have built-in counterparts. Maybe not 
even toml-ts-mode, since there is conf-toml-mode.

Maybe make some exceptions for TS modes that provide significantly 
better functionality than the classic ones. Not sure which ones.

What I think is important, though, is avoiding major mode functions 
modiying auto-mode-alist at runtime.

> And yes, I would like to hear from more people what they think about
> the possible behaviors in these cases, including how to handle missing
> grammar libraries.

Everybody's welcome to chime in.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Sun, 13 Oct 2024 12:37:38 +0300
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > It is not clear which modes you suggest that should behave like that.
> > Surely, not all of them, i.e. including those for which non-TS modes
> > are part of Emacs?
> 
> I don't have a strong opinion on which set should be enabled - maybe 
> just all TS modes which we don't have built-in counterparts. Maybe not 
> even toml-ts-mode, since there is conf-toml-mode.
> 
> Maybe make some exceptions for TS modes that provide significantly 
> better functionality than the classic ones.

I tend to agree.

> What I think is important, though, is avoiding major mode functions 
> modiying auto-mode-alist at runtime.

But CC Mode already does, and always did?

> > And yes, I would like to hear from more people what they think about
> > the possible behaviors in these cases, including how to handle missing
> > grammar libraries.
> 
> Everybody's welcome to chime in.

Right.

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 13/10/2024 07:41, Eli Zaretskii wrote:
>> And yes, I would like to hear from more people what they think about
>> the possible behaviors in these cases, including how to handle missing
>> grammar libraries.
>
> Everybody's welcome to chime in.

Since the grammar libraries are compiled code: is automatically
downloading them a risk of remote code execution errors?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

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

On Sun, Oct 13, 2024, at 12:39 PM, Eli Zaretskii wrote:
> > Date: Sun, 13 Oct 2024 12:37:38 +0300
> > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> > 
> > > It is not clear which modes you suggest that should behave like that.
> > > Surely, not all of them, i.e. including those for which non-TS modes
> > > are part of Emacs?
> > 
> > I don't have a strong opinion on which set should be enabled - maybe 
> > just all TS modes which we don't have built-in counterparts. Maybe not 
> > even toml-ts-mode, since there is conf-toml-mode.
> > 
> > Maybe make some exceptions for TS modes that provide significantly 
> > better functionality than the classic ones.
> 
> I tend to agree.
> 
> > What I think is important, though, is avoiding major mode functions 
> > modiying auto-mode-alist at runtime.
> 
> But CC Mode already does, and always did?
I don't think so: those alterations happen in 'autoload' blocks, which means that it happens either during Emacs' startup, or during package initialization, if cc-mode is installed as an ELPA package.

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

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Sun, 13 Oct 2024 17:31:33 +0200
> From: "Dmitry Gutov" <dmitry@gutov.dev>
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> 
> On Sun, Oct 13, 2024, at 12:39 PM, Eli Zaretskii wrote:
> 
>  > What I think is important, though, is avoiding major mode functions 
>  > modiying auto-mode-alist at runtime.
> 
>  But CC Mode already does, and always did?
> 
> I don't think so: those alterations happen in 'autoload' blocks, which means that it happens either during
> Emacs' startup, or during package initialization, if cc-mode is installed as an ELPA package.

In any case, I don't understand what is so sacred about
auto-mode-alist that it should not be modified at run time.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 13/10/2024 18:53, Eli Zaretskii wrote:
> In any case, I don't understand what is so sacred about
> auto-mode-alist that it should not be modified at run time.

The ad-hoc behaviors the creates and offers the users, or the bugs like 
'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example) 
doing the same because it loads cc-mode.

Re: An anonymous IRC user's opinion

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Oct 14, 2024 at 12:32:31 +0300, Dmitry Gutov wrote:
> On 13/10/2024 18:53, Eli Zaretskii wrote:
> > In any case, I don't understand what is so sacred about
> > auto-mode-alist that it should not be modified at run time.

> The ad-hoc behaviors the creates and offers the users, or the bugs like 
> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example) 
> doing the same because it loads cc-mode.

Not sure exactly what you mean there.  With emacs -Q, the CC Mode
entries are already on auto-mode-alist.  Does anything more happen with
M-x js-ts-mode?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Mon, 14 Oct 2024 12:32:31 +0300
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 13/10/2024 18:53, Eli Zaretskii wrote:
> > In any case, I don't understand what is so sacred about
> > auto-mode-alist that it should not be modified at run time.
> 
> The ad-hoc behaviors the creates and offers the users, or the bugs like 
> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example) 
> doing the same because it loads cc-mode.

We have such issues all over the place in Emacs: "C-h" commands that
load packages modify the global state.  There's nothing new here, nor
anything outlandish.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 14/10/2024 17:16, Eli Zaretskii wrote:
>> The ad-hoc behaviors the creates and offers the users, or the bugs like
>> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example)
>> doing the same because it loads cc-mode.
> We have such issues all over the place in Emacs: "C-h" commands that
> load packages modify the global state.  There's nothing new here, nor
> anything outlandish.

It might not be a huge deal, but packages being loaded at various times, 
sometimes unexpected, is why we try to avoid doing too many things 
during that time.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

Hi Alan,

On 14/10/2024 14:09, Alan Mackenzie wrote:
>> The ad-hoc behaviors the creates and offers the users, or the bugs like
>> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example)
>> doing the same because it loads cc-mode.
> Not sure exactly what you mean there.  With emacs -Q, the CC Mode
> entries are already on auto-mode-alist.  Does anything more happen with
> M-x js-ts-mode?

I'd rather not get into full detail right now (not filing a bug report), 
we can treat it as an outline of a scenario which could happen with 
different modes anyway if they are allowed to alter a-m-a during package 
loading.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 15 Oct 2024 04:36:55 +0300
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 14/10/2024 17:16, Eli Zaretskii wrote:
> >> The ad-hoc behaviors the creates and offers the users, or the bugs like
> >> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example)
> >> doing the same because it loads cc-mode.
> > We have such issues all over the place in Emacs: "C-h" commands that
> > load packages modify the global state.  There's nothing new here, nor
> > anything outlandish.
> 
> It might not be a huge deal, but packages being loaded at various times, 
> sometimes unexpected, is why we try to avoid doing too many things 
> during that time.

I agree that we should try to avoid that if possible, but you
originally made a stronger argument, or so I interpreted it.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

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

On 15/10/2024 15:03, Eli Zaretskii wrote:
>> Date: Tue, 15 Oct 2024 04:36:55 +0300
>> Cc:johan.myreen@gmail.com,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> On 14/10/2024 17:16, Eli Zaretskii wrote:
>>>> The ad-hoc behaviors the creates and offers the users, or the bugs like
>>>> 'C-h f' altering auto-mode-alist, or 'M-x js-ts-mode' (for example)
>>>> doing the same because it loads cc-mode.
>>> We have such issues all over the place in Emacs: "C-h" commands that
>>> load packages modify the global state.  There's nothing new here, nor
>>> anything outlandish.
>> It might not be a huge deal, but packages being loaded at various times,
>> sometimes unexpected, is why we try to avoid doing too many things
>> during that time.
> I agree that we should try to avoid that if possible, but you
> originally made a stronger argument, or so I interpreted it.

I could mention the problems (most of them known), but perhaps we should 
discuss a possible fix instead.

Here's a patch along the lines described in this thread.

Additionally, as mentioned, we could drop some modes from the default 
set (removing toml-ts-mode and maybe dockerfile-ts-mode as well).

[-- Attachment #2: treesit-auto-mode-autoloads.diff --]
[-- Type: text/x-patch, Size: 14019 bytes --]

diff --git a/lisp/files.el b/lisp/files.el
index 9c105dbe1a5..9f256695011 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -3059,9 +3059,13 @@ auto-mode-alist
      ("\\.dbk\\'" . xml-mode)
      ("\\.dtd\\'" . sgml-mode)
      ("\\.ds\\(ss\\)?l\\'" . dsssl-mode)
-     ("\\.js[mx]?\\'" . javascript-mode)
+     ("\\.js[mx]?\\'" . ,(if (treesit-available-p)
+                             'js-ts-mode
+                           'javascript-mode))
      ;; https://en.wikipedia.org/wiki/.har
-     ("\\.har\\'" . javascript-mode)
+     ("\\.har\\'" . ,(if (treesit-available-p)
+                         'js-ts-mode
+                       'javascript-mode))
      ("\\.json\\'" . js-json-mode)
      ("\\.[ds]?va?h?\\'" . verilog-mode)
      ("\\.by\\'" . bovine-grammar-mode)
diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 3823c553fda..5b89fe917c2 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -35,12 +35,6 @@
 ;; To use these modes by default, assuming you have the respective
 ;; tree-sitter grammars available, do one of the following:
 ;;
-;; - If you have both C and C++ grammars installed, add
-;;
-;;    (require 'c-ts-mode)
-;;
-;;   to your init file.
-;;
 ;; - Add one or mode of the following to your init file:
 ;;
 ;;    (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))
@@ -1539,21 +1533,6 @@ c-or-c++-ts-mode
            'c-ts-mode)))
     (funcall (major-mode-remap mode))))
 
-;; The entries for C++ must come first to prevent *.c files be taken
-;; as C++ on case-insensitive filesystems, since *.C files are C++,
-;; not C.
-(if (treesit-ready-p 'cpp)
-    (add-to-list 'major-mode-remap-defaults
-                 '(c++-mode . c++-ts-mode)))
-
-(when (treesit-ready-p 'c)
-  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)))
-
-(when (and (treesit-ready-p 'cpp)
-           (treesit-ready-p 'c))
-  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)))
-
 (when (and c-ts-mode-enable-doxygen (not (treesit-ready-p 'doxygen t)))
   (message "Doxygen syntax highlighting can't be enabled, please install the language grammar."))
 
diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index c5bb075c7f6..867d47ee0a2 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -3377,22 +3377,6 @@ c-submit-bug-report
 	(insert (format "Buffer Style: %s\nc-emacs-features: %s\n"
 			style c-features)))))))
 
-\f
-;; Make entries in `major-mode-remap-defaults' to ensure that when CC
-;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's
-;; modes rather than c-ts-mode etc..
-(when (boundp 'major-mode-remap-defaults)
-  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode))
-  (let (entry)
-    (dolist (mode '(c-mode c++-mode c-or-c++-mode))
-      (if (and (setq entry (assq mode major-mode-remap-defaults))
-	       (null (cdr entry)))
-	  (setq major-mode-remap-defaults
-		(delq entry major-mode-remap-defaults)))
-      (push (cons mode nil) major-mode-remap-defaults))))
-
 \f
 (cc-provide 'cc-mode)
 
diff --git a/lisp/progmodes/cmake-ts-mode.el b/lisp/progmodes/cmake-ts-mode.el
index 597ef69d9b8..f40147a94b0 100644
--- a/lisp/progmodes/cmake-ts-mode.el
+++ b/lisp/progmodes/cmake-ts-mode.el
@@ -244,7 +244,8 @@ cmake-ts-mode
 
 (derived-mode-add-parents 'cmake-ts-mode '(cmake-mode))
 
-(if (treesit-ready-p 'cmake)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist
                  '("\\(?:CMakeLists\\.txt\\|\\.cmake\\)\\'" . cmake-ts-mode)))
 
diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index b86555b1d87..dbf169a048c 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -1089,9 +1089,11 @@ csharp-ts-mode
                 ("Struct" "\\`struct_declaration\\'" nil nil)
                 ("Method" "\\`method_declaration\\'" nil nil)))
 
-  (treesit-major-mode-setup)
+  (treesit-major-mode-setup))
 
-  (add-to-list 'auto-mode-alist '("\\.cs\\'" . csharp-ts-mode)))
+;;;###autoload
+(if (treesit-available-p)
+    (add-to-list 'auto-mode-alist '("\\.cs\\'" . csharp-ts-mode)))
 
 (derived-mode-add-parents 'csharp-ts-mode '(csharp-mode))
 
diff --git a/lisp/progmodes/dockerfile-ts-mode.el b/lisp/progmodes/dockerfile-ts-mode.el
index 42fa7482a87..2d33c6c2c65 100644
--- a/lisp/progmodes/dockerfile-ts-mode.el
+++ b/lisp/progmodes/dockerfile-ts-mode.el
@@ -167,7 +167,8 @@ dockerfile-ts-mode
 
 (derived-mode-add-parents 'dockerfile-ts-mode '(dockerfile-mode))
 
-(if (treesit-ready-p 'dockerfile)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist
                  ;; NOTE: We can't use `rx' here, as it breaks bootstrap.
                  '("\\(?:Dockerfile\\(?:\\..*\\)?\\|\\.[Dd]ockerfile\\)\\'"
diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mode.el
index cacdb266298..a3b9f7d5611 100644
--- a/lisp/progmodes/elixir-ts-mode.el
+++ b/lisp/progmodes/elixir-ts-mode.el
@@ -755,7 +755,8 @@ elixir-ts-mode
 
 (derived-mode-add-parents 'elixir-ts-mode '(elixir-mode))
 
-(if (treesit-ready-p 'elixir)
+;;;###autoload
+(if (treesit-available-p)
     (progn
       (add-to-list 'auto-mode-alist '("\\.elixir\\'" . elixir-ts-mode))
       (add-to-list 'auto-mode-alist '("\\.ex\\'" . elixir-ts-mode))
diff --git a/lisp/progmodes/go-ts-mode.el b/lisp/progmodes/go-ts-mode.el
index 86e74ad58a8..3e1bc4bea40 100644
--- a/lisp/progmodes/go-ts-mode.el
+++ b/lisp/progmodes/go-ts-mode.el
@@ -305,7 +305,8 @@ go-ts-mode
 
 (derived-mode-add-parents 'go-ts-mode '(go-mode))
 
-(if (treesit-ready-p 'go)
+;;;###autoload
+(if (treesit-available-p)
     ;; FIXME: Should we instead put `go-mode' in `auto-mode-alist'
     ;; and then use `major-mode-remap-defaults' to map it to `go-ts-mode'?
     (add-to-list 'auto-mode-alist '("\\.go\\'" . go-ts-mode)))
@@ -562,7 +563,8 @@ go-mod-ts-mode
 
 (derived-mode-add-parents 'go-mod-ts-mode '(go-mod-mode))
 
-(if (treesit-ready-p 'gomod)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("/go\\.mod\\'" . go-mod-ts-mode)))
 
 (provide 'go-ts-mode)
diff --git a/lisp/progmodes/heex-ts-mode.el b/lisp/progmodes/heex-ts-mode.el
index 84fd513525c..3f26f0a9b14 100644
--- a/lisp/progmodes/heex-ts-mode.el
+++ b/lisp/progmodes/heex-ts-mode.el
@@ -191,7 +191,8 @@ heex-ts-mode
 
 (derived-mode-add-parents 'heex-ts-mode '(heex-mode))
 
-(if (treesit-ready-p 'heex)
+;;;###autoload
+(if (treesit-available-p)
     ;; Both .heex and the deprecated .leex files should work
     ;; with the tree-sitter-heex grammar.
     (add-to-list 'auto-mode-alist '("\\.[hl]?eex\\'" . heex-ts-mode)))
diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el
index 177f914160c..860cb433f71 100644
--- a/lisp/progmodes/java-ts-mode.el
+++ b/lisp/progmodes/java-ts-mode.el
@@ -436,7 +436,8 @@ java-ts-mode
 
 (derived-mode-add-parents 'java-ts-mode '(java-mode))
 
-(if (treesit-ready-p 'java)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.java\\'" . java-ts-mode)))
 
 (when (and java-ts-mode-enable-doxygen (not (treesit-ready-p 'doxygen t)))
diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index f74b8ab1c46..a4d4399012c 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -3961,10 +3961,7 @@ js-ts-mode
                                         "method_definition")
                                 eos)
                    nil nil)))
-    (treesit-major-mode-setup)
-
-    (add-to-list 'auto-mode-alist
-                 '("\\(\\.js[mx]\\|\\.har\\)\\'" . js-ts-mode))))
+    (treesit-major-mode-setup)))
 
 (derived-mode-add-parents 'js-ts-mode '(js-mode))
 
diff --git a/lisp/progmodes/json-ts-mode.el b/lisp/progmodes/json-ts-mode.el
index 7409c6be833..e0d8cf72841 100644
--- a/lisp/progmodes/json-ts-mode.el
+++ b/lisp/progmodes/json-ts-mode.el
@@ -166,7 +166,8 @@ json-ts-mode
 
 (derived-mode-add-parents 'json-ts-mode '(json-mode))
 
-(if (treesit-ready-p 'json)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist
                  '("\\.json\\'" . json-ts-mode)))
 
diff --git a/lisp/progmodes/lua-ts-mode.el b/lisp/progmodes/lua-ts-mode.el
index 20bc1f3e158..58328332e68 100644
--- a/lisp/progmodes/lua-ts-mode.el
+++ b/lisp/progmodes/lua-ts-mode.el
@@ -837,7 +837,8 @@ lua-ts-mode
 
 (derived-mode-add-parents 'lua-ts-mode '(lua-mode))
 
-(when (treesit-ready-p 'lua)
+;;;###autoload
+(if (treesit-available-p)
   (add-to-list 'auto-mode-alist '("\\.lua\\'" . lua-ts-mode)))
 
 (provide 'lua-ts-mode)
diff --git a/lisp/progmodes/php-ts-mode.el b/lisp/progmodes/php-ts-mode.el
index 07a0c266d78..b090da01ce8 100644
--- a/lisp/progmodes/php-ts-mode.el
+++ b/lisp/progmodes/php-ts-mode.el
@@ -1824,7 +1824,8 @@ php-ts-mode-kill-process
   (with-current-buffer php-ts-mode-inferior-php-buffer
     (kill-buffer-and-window)))
 
-(when (treesit-ready-p 'php)
+;;;###autoload
+(when (treesit-available-p)
   (add-to-list
    'auto-mode-alist '("\\.\\(?:php[s345]?\\|phtml\\)\\'" . php-ts-mode))
   (add-to-list
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 283a545bfb4..f8903771aa2 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -287,9 +287,13 @@ python--auto-mode-alist-regexp
       eos))
 
 ;;;###autoload
-(add-to-list 'auto-mode-alist (cons python--auto-mode-alist-regexp 'python-mode))
+(add-to-list 'auto-mode-alist
+             (cons python--auto-mode-alist-regexp
+                   (if (treesit-available-p) 'python-ts-mode 'python-mode)))
 ;;;###autoload
-(add-to-list 'interpreter-mode-alist (cons (purecopy "python[0-9.]*") 'python-mode))
+(add-to-list 'interpreter-mode-alist
+             (cons (purecopy "python[0-9.]*")
+                   (if (treesit-available-p) 'python-ts-mode 'python-mode)))
 
 (defgroup python nil
   "Python Language's flying circus support for Emacs."
diff --git a/lisp/progmodes/ruby-ts-mode.el b/lisp/progmodes/ruby-ts-mode.el
index aff0b8911b9..646de8a4ec3 100644
--- a/lisp/progmodes/ruby-ts-mode.el
+++ b/lisp/progmodes/ruby-ts-mode.el
@@ -1237,7 +1237,8 @@ ruby-ts-mode
 
 (derived-mode-add-parents 'ruby-ts-mode '(ruby-mode))
 
-(if (treesit-ready-p 'ruby)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'major-mode-remap-defaults
                  '(ruby-mode . ruby-ts-mode)))
 
diff --git a/lisp/progmodes/rust-ts-mode.el b/lisp/progmodes/rust-ts-mode.el
index e52ea3b125a..4ee671e16e4 100644
--- a/lisp/progmodes/rust-ts-mode.el
+++ b/lisp/progmodes/rust-ts-mode.el
@@ -566,7 +566,8 @@ rust-ts-mode
 
 (derived-mode-add-parents 'rust-ts-mode '(rust-mode))
 
-(if (treesit-ready-p 'rust)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.rs\\'" . rust-ts-mode)))
 
 (provide 'rust-ts-mode)
diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el
index ef5dbe51ada..bfb7f1afc84 100644
--- a/lisp/progmodes/typescript-ts-mode.el
+++ b/lisp/progmodes/typescript-ts-mode.el
@@ -535,7 +535,8 @@ typescript-ts-mode
 
 (derived-mode-add-parents 'typescript-ts-mode '(typescript-mode))
 
-(if (treesit-ready-p 'typescript)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode)))
 
 ;;;###autoload
@@ -631,7 +632,8 @@ tsx-ts--syntax-propertize-captures
       (put-text-property ns (1+ ns) 'syntax-table syntax)
       (put-text-property (1- ne) ne 'syntax-table syntax))))
 
-(if (treesit-ready-p 'tsx)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.tsx\\'" . tsx-ts-mode)))
 
 (provide 'typescript-ts-mode)
diff --git a/lisp/textmodes/css-mode.el b/lisp/textmodes/css-mode.el
index c8da28187ee..04e1cce807e 100644
--- a/lisp/textmodes/css-mode.el
+++ b/lisp/textmodes/css-mode.el
@@ -1826,12 +1826,14 @@ css-ts-mode
     (setq-local treesit-simple-imenu-settings
                 `(( nil ,(rx bos (or "rule_set" "media_statement") eos)
                     nil nil)))
-    (treesit-major-mode-setup)
-
-    (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode))))
+    (treesit-major-mode-setup)))
 
 (derived-mode-add-parents 'css-ts-mode '(css-mode))
 
+;;;###autoload
+(if (treesit-available-p)
+    (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
+
 ;;;###autoload
 (define-derived-mode css-mode css-base-mode "CSS"
   "Major mode to edit Cascading Style Sheets (CSS).
diff --git a/lisp/textmodes/html-ts-mode.el b/lisp/textmodes/html-ts-mode.el
index f78fbdde1da..c21d187be28 100644
--- a/lisp/textmodes/html-ts-mode.el
+++ b/lisp/textmodes/html-ts-mode.el
@@ -136,7 +136,8 @@ html-ts-mode
 
 (derived-mode-add-parents 'html-ts-mode '(html-mode))
 
-(if (treesit-ready-p 'html)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.html\\'" . html-ts-mode)))
 
 (provide 'html-ts-mode)
diff --git a/lisp/textmodes/toml-ts-mode.el b/lisp/textmodes/toml-ts-mode.el
index 806f045c23b..fcb9a056353 100644
--- a/lisp/textmodes/toml-ts-mode.el
+++ b/lisp/textmodes/toml-ts-mode.el
@@ -155,7 +155,8 @@ toml-ts-mode
 
 (derived-mode-add-parents 'toml-ts-mode '(toml-mode))
 
-(if (treesit-ready-p 'toml)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.toml\\'" . toml-ts-mode)))
 
 (provide 'toml-ts-mode)
diff --git a/lisp/textmodes/yaml-ts-mode.el b/lisp/textmodes/yaml-ts-mode.el
index 42d7c2e1798..b39d32148c0 100644
--- a/lisp/textmodes/yaml-ts-mode.el
+++ b/lisp/textmodes/yaml-ts-mode.el
@@ -171,7 +171,8 @@ yaml-ts-mode
 
 (derived-mode-add-parents 'yaml-ts-mode '(yaml-mode))
 
-(if (treesit-ready-p 'yaml)
+;;;###autoload
+(if (treesit-available-p)
     (add-to-list 'auto-mode-alist '("\\.ya?ml\\'" . yaml-ts-mode)))
 
 (provide 'yaml-ts-mode)

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Sun, 3 Nov 2024 05:10:26 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> I could mention the problems (most of them known), but perhaps we should 
> discuss a possible fix instead.
> 
> Here's a patch along the lines described in this thread.
> 
> Additionally, as mentioned, we could drop some modes from the default 
> set (removing toml-ts-mode and maybe dockerfile-ts-mode as well).

Can we please talk in English, at least in addition to posting the
code and hoping that it explains your ideas clearly enough?  Because I
really don't understand the idea.  Apologies if the idea is lost in
this discussion that spans many moons.

Is the idea to expect the users to have all the grammar libraries
installed when they use an Emacs which was built with Tree-Sitter?
Because your code seems to only test the latter, or so it seems.  If
so, I don't think it's an idea to which I'd agree.  E.g., imagine a
user who installed Emacs from some distro which decided to build with
Tree-Sitter, but doesn't provide all the grammar libraries we require,
for whatever reasons.

A minor nit: I don't see how c-ts-mode will be invoked under your
proposal.  What did I miss?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 03/11/2024 08:37, Eli Zaretskii wrote:
>> Date: Sun, 3 Nov 2024 05:10:26 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> I could mention the problems (most of them known), but perhaps we should
>> discuss a possible fix instead.
>>
>> Here's a patch along the lines described in this thread.
>>
>> Additionally, as mentioned, we could drop some modes from the default
>> set (removing toml-ts-mode and maybe dockerfile-ts-mode as well).
> 
> Can we please talk in English, at least in addition to posting the
> code and hoping that it explains your ideas clearly enough?  Because I
> really don't understand the idea.  Apologies if the idea is lost in
> this discussion that spans many moons.

Sure. The general idea is this:

As long as Emacs is configured with support for tree-sitter, we enable 
file associations (using auto-mode-alist) for a certain set of 
tree-sitter based modes. Chefly those that don't have existing 
"traditional" modes, but that's debatable.

For others (modes that are not enabled by default), we document the way 
to enable them somewhere - in packages' Commentary, for example. The 
traditional way to do that has been with us for decades (people need to 
add an auto-mode-alist entry in their config script) - and now we also 
have a way to do that using major-mode-remap-alist. Either way, adding a 
line or two to their .emacs.

The overall effect is that the file associations become stable again: 
set during Emacs's startup and not changing when a package gets loaded, 
or a major mode function is called.

> Is the idea to expect the users to have all the grammar libraries
> installed when they use an Emacs which was built with Tree-Sitter?

In a way yes, but also no, because they are only needed when the 
corresponding file is visited. And only for modes that we decide to 
enable by default.

> Because your code seems to only test the latter, or so it seems.  If
> so, I don't think it's an idea to which I'd agree.  E.g., imagine a
> user who installed Emacs from some distro which decided to build with
> Tree-Sitter, but doesn't provide all the grammar libraries we require,
> for whatever reasons.

Then, when visiting let's say a Go file (or Rust, or TypeScript) they 
will right away be greeted by a warning that the grammar is not 
available, search the docs how to deal with that, and hopefully install 
it somehow (maybe using M-x treesit-install-language-grammar). If they 
don't, perhaps they'll disable the file association manually - or live 
with the warning when visiting such files.

Is that better or worse than what we have now? For users that hoped to 
use tree-sitter modes, seems strictly better. For others, might add an 
inconvenience - but the amount depends on the set of ts modes that we 
ultimately decide to enable.

To remind, the bug report that made us change our plan previously was 
about a scenario where the user a) configured their Emacs to build 
without tree-sitter explicitly, b) visited a .toml file (a config file - 
where the annoyance of installing the grammar is likely not paid off 
with the features it provides).

> A minor nit: I don't see how c-ts-mode will be invoked under your
> proposal.  What did I miss?

You mean how it will be enabled globally, right? Not just invoked.

c-ts-mode has instructions in its Commentary, which currently has 3 
options. The patch removes one of them, leaving these two:

   ;; - Add one or mode of the following to your init file:
   ;;
   ;;    (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))
   ...

and

   ;; - Customize 'auto-mode-alist' to turn one or more of the modes
   ;;   automatically.  For example:
   ;;
   ;;     (add-to-list 'auto-mode-alist
   ;; 
'("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'"
   ;;                    . c++-ts-mode))

BTW, I missed this paragraph after, it will need to be removed too I 
guess (or limited to just the first sentence):

   ;; You can also turn on these modes manually in a buffer.  Doing so
   ;; will set up Emacs to use the C/C++ modes defined here for other
   ;; files, provided that you have the corresponding parser grammar
   ;; libraries installed.

(Because 'M-x c-ts-mode' won't alter file associations for the remainder 
of the session.)

I recommend the major-mode-remap-alist way, personally.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Sun, 3 Nov 2024 21:24:27 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> As long as Emacs is configured with support for tree-sitter, we enable 
> file associations (using auto-mode-alist) for a certain set of 
> tree-sitter based modes. Chefly those that don't have existing 
> "traditional" modes, but that's debatable.
> 
> For others (modes that are not enabled by default), we document the way 
> to enable them somewhere - in packages' Commentary, for example. The 
> traditional way to do that has been with us for decades (people need to 
> add an auto-mode-alist entry in their config script) - and now we also 
> have a way to do that using major-mode-remap-alist. Either way, adding a 
> line or two to their .emacs.
> 
> The overall effect is that the file associations become stable again: 
> set during Emacs's startup and not changing when a package gets loaded, 
> or a major mode function is called.
> 
> > Is the idea to expect the users to have all the grammar libraries
> > installed when they use an Emacs which was built with Tree-Sitter?
> 
> In a way yes, but also no, because they are only needed when the 
> corresponding file is visited. And only for modes that we decide to 
> enable by default.

I'd prefer not to assume that the mere presence of libtree-sitter
means the user wants to use modes.  At the very least we should
perhaps have a special user option to tell that.  In the simplest case
it should be a simple boolean, but it could also be a list of
languages/grammars for which to enable these modes.  Then the relevant
parts of auto-mode-alist should test that variable, in addition to
whether tree-sitter is supported and available in general.

> > Because your code seems to only test the latter, or so it seems.  If
> > so, I don't think it's an idea to which I'd agree.  E.g., imagine a
> > user who installed Emacs from some distro which decided to build with
> > Tree-Sitter, but doesn't provide all the grammar libraries we require,
> > for whatever reasons.
> 
> Then, when visiting let's say a Go file (or Rust, or TypeScript) they 
> will right away be greeted by a warning that the grammar is not 
> available, search the docs how to deal with that, and hopefully install 
> it somehow (maybe using M-x treesit-install-language-grammar). If they 
> don't, perhaps they'll disable the file association manually - or live 
> with the warning when visiting such files.

Without the user's say-so, this could be considered a nuisance.  Why
should Emacs annoy a user with some potential feature when the user
didn't say she wants to use it?  This is not a marketing stance, is
it?

> > A minor nit: I don't see how c-ts-mode will be invoked under your
> > proposal.  What did I miss?
> 
> You mean how it will be enabled globally, right? Not just invoked.
> 
> c-ts-mode has instructions in its Commentary, which currently has 3 
> options. The patch removes one of them, leaving these two:

I don't understand why you decided to treat c-ts-mode differently
from, say, js-ts-mode.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 04/11/2024 14:11, Eli Zaretskii wrote:

> I'd prefer not to assume that the mere presence of libtree-sitter
> means the user wants to use modes.

If we don't override existing traditional modes, what's the harm? If we 
also exclude "small" modes like toml-ts-mode and dockerfile-ts-mode from 
being enabled by default, we can be reasonably sure that when the user 
visits a matching file, they will want to have the grammar installed.

>>> Because your code seems to only test the latter, or so it seems.  If
>>> so, I don't think it's an idea to which I'd agree.  E.g., imagine a
>>> user who installed Emacs from some distro which decided to build with
>>> Tree-Sitter, but doesn't provide all the grammar libraries we require,
>>> for whatever reasons.
>>
>> Then, when visiting let's say a Go file (or Rust, or TypeScript) they
>> will right away be greeted by a warning that the grammar is not
>> available, search the docs how to deal with that, and hopefully install
>> it somehow (maybe using M-x treesit-install-language-grammar). If they
>> don't, perhaps they'll disable the file association manually - or live
>> with the warning when visiting such files.
> 
> Without the user's say-so, this could be considered a nuisance.  Why
> should Emacs annoy a user with some potential feature when the user
> didn't say she wants to use it?

Could be considered a nuisance, or a boon.

Somebody tries to open a Go file, and sees *no* syntax highlighting, 
indentation support, etc. When the grammar is not installed, our options 
here are either:

- Silently provide no features, nor explanations why they are not 
working. Whether the major mode is enabled or not, it offers no 
explanation on how to fix things.

- Or issue a warning that the grammar is not installed. This would make 
it easier to find the next steps.

 > This is not a marketing stance, is
 > it?

If making a feature easier to set up and use is a marketing stance, then 
okay, it is.

Note that I don't have a goal of forcing tree-sitter on everybody: 
previously I suggested to have all ts mode off by default. But if we're 
going to set them up, the above seems to make the most sense.

>>> A minor nit: I don't see how c-ts-mode will be invoked under your
>>> proposal.  What did I miss?
>>
>> You mean how it will be enabled globally, right? Not just invoked.
>>
>> c-ts-mode has instructions in its Commentary, which currently has 3
>> options. The patch removes one of them, leaving these two:
> 
> I don't understand why you decided to treat c-ts-mode differently
> from, say, js-ts-mode.

I really don't mind removing js-ts-mode, ruby-ts-mode (some other 
examples?) from being enabled by default. Let's tell the users how to 
set those up too, it's not hard.

We can turn them on later in some future release when we can ensure 
grammars' availability.

And to return to the beginning of your message:

 > At the very least we should
 > perhaps have a special user option to tell that.  In the simplest case
 > it should be a simple boolean, but it could also be a list of
 > languages/grammars for which to enable these modes.  Then the relevant
 > parts of auto-mode-alist should test that variable, in addition to
 > whether tree-sitter is supported and available in general.

This is also a valid approach, albeit a more complex one. This variable 
would only be tested during Emacs' startup, though, and during 
'package-initialize', making its use not very transparent. E.g. we 
wouldn't react to having it changed in Customize. So it's not my 
preferred approach to this problem.

If we did have such a variable, though, we could enable more modes by 
default. And it seems like it would be most consistent to enable all 
tree-sitter modes that we have - including c-ts-mode and so on. I expect 
some resistance to such a change.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 19:41:13 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 04/11/2024 14:11, Eli Zaretskii wrote:
> 
> > I'd prefer not to assume that the mere presence of libtree-sitter
> > means the user wants to use modes.
> 
> If we don't override existing traditional modes, what's the harm?

Oh, but we do.  Even if there's no mode defined for a file, people
might expect to have Fundamental mode.  We had this discussion before,
and we even had someone who complained that some file suddenly turned
on a TS mode where previously there was Fundamental mode.  That was
one of the reasons we made these modes optional in Emacs 29, so let's
not repeat past mistakes.

> If we 
> also exclude "small" modes like toml-ts-mode and dockerfile-ts-mode from 
> being enabled by default, we can be reasonably sure that when the user 
> visits a matching file, they will want to have the grammar installed.

I don't think we can be reasonably sure, no.

> > Without the user's say-so, this could be considered a nuisance.  Why
> > should Emacs annoy a user with some potential feature when the user
> > didn't say she wants to use it?
> 
> Could be considered a nuisance, or a boon.

See above: we've been there already, and we know it isn't a boon.

> Somebody tries to open a Go file, and sees *no* syntax highlighting, 
> indentation support, etc. When the grammar is not installed, our options 
> here are either:
> 
> - Silently provide no features, nor explanations why they are not 
> working. Whether the major mode is enabled or not, it offers no 
> explanation on how to fix things.
> 
> - Or issue a warning that the grammar is not installed. This would make 
> it easier to find the next steps.

Silently providing no features (and relying on people to read the docs
and set up their Emacs) is perhaps not the ideal situation, but
annoying users with warning messages they didn't ask for is worse.

Again, we've been there, and I'm not going to agree to go back.

> Note that I don't have a goal of forcing tree-sitter on everybody: 
> previously I suggested to have all ts mode off by default. But if we're 
> going to set them up, the above seems to make the most sense.

Not to me, it doesn't.

Why is it a problem to ask users to whitelist some of these modes?

>  > At the very least we should
>  > perhaps have a special user option to tell that.  In the simplest case
>  > it should be a simple boolean, but it could also be a list of
>  > languages/grammars for which to enable these modes.  Then the relevant
>  > parts of auto-mode-alist should test that variable, in addition to
>  > whether tree-sitter is supported and available in general.
> 
> This is also a valid approach, albeit a more complex one. This variable 
> would only be tested during Emacs' startup, though, and during 
> 'package-initialize', making its use not very transparent.

It will be tested right there in auto-mode-alist, like the change you
proposed, just with another test.

> E.g. we 
> wouldn't react to having it changed in Customize. So it's not my 
> preferred approach to this problem.

I don't see why this couldn't be a defcustom.

> If we did have such a variable, though, we could enable more modes by 
> default.

Subject to users whitelisting those modes? yes, that's the idea.

> And it seems like it would be most consistent to enable all 
> tree-sitter modes that we have - including c-ts-mode and so on. I expect 
> some resistance to such a change.

Again, if the user sets this variable to t, meaning enable all of TS
modes, why would there be a resistance?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 04/11/2024 21:18, Eli Zaretskii wrote:

>> If we don't override existing traditional modes, what's the harm?
> 
> Oh, but we do.  Even if there's no mode defined for a file, people
> might expect to have Fundamental mode.  We had this discussion before,
> and we even had someone who complained that some file suddenly turned
> on a TS mode where previously there was Fundamental mode.  That was
> one of the reasons we made these modes optional in Emacs 29, so let's
> not repeat past mistakes.

That was with toml-ts-mode.

So you think we should prioritize the scenario where people prefer 
fundamental-mode over go-ts-mode or typescript-ts-mode as well?

>> If we
>> also exclude "small" modes like toml-ts-mode and dockerfile-ts-mode from
>> being enabled by default, we can be reasonably sure that when the user
>> visits a matching file, they will want to have the grammar installed.
> 
> I don't think we can be reasonably sure, no.
> 
>>> Without the user's say-so, this could be considered a nuisance.  Why
>>> should Emacs annoy a user with some potential feature when the user
>>> didn't say she wants to use it?
>>
>> Could be considered a nuisance, or a boon.
> 
> See above: we've been there already, and we know it isn't a boon.

We've been there in a particular configuration (one that included Emacs 
being configured --without-tree-sitter).

> Silently providing no features (and relying on people to read the docs
> and set up their Emacs) is perhaps not the ideal situation, but
> annoying users with warning messages they didn't ask for is worse.
> 
> Again, we've been there, and I'm not going to agree to go back.

Ok.

>> Note that I don't have a goal of forcing tree-sitter on everybody:
>> previously I suggested to have all ts mode off by default. But if we're
>> going to set them up, the above seems to make the most sense.
> 
> Not to me, it doesn't.
> 
> Why is it a problem to ask users to whitelist some of these modes?

Not a problem, no. They can do this already by customizing 
major-mode-remap-alist, for example.

>> This is also a valid approach, albeit a more complex one. This variable
>> would only be tested during Emacs' startup, though, and during
>> 'package-initialize', making its use not very transparent.
> 
> It will be tested right there in auto-mode-alist, like the change you
> proposed, just with another test.

I'm concerned about the ergonomics of this option.

>> E.g. we
>> wouldn't react to having it changed in Customize. So it's not my
>> preferred approach to this problem.
> 
> I don't see why this couldn't be a defcustom.

Would it have a non-default setter?

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 22:59:06 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 04/11/2024 21:18, Eli Zaretskii wrote:
> 
> >> If we don't override existing traditional modes, what's the harm?
> > 
> > Oh, but we do.  Even if there's no mode defined for a file, people
> > might expect to have Fundamental mode.  We had this discussion before,
> > and we even had someone who complained that some file suddenly turned
> > on a TS mode where previously there was Fundamental mode.  That was
> > one of the reasons we made these modes optional in Emacs 29, so let's
> > not repeat past mistakes.
> 
> That was with toml-ts-mode.
> 
> So you think we should prioritize the scenario where people prefer 
> fundamental-mode over go-ts-mode or typescript-ts-mode as well?

No, we should de-prioritize the scenario where what used to work
without any warnings suddenly triggers warnings when visiting files,
asking the user to install something she never asked for in the first
place.

(Are we really going to reiterate that old discussion?  Nothing's
changed since then, so the opinions and conclusions will be exactly
the same.)

> > See above: we've been there already, and we know it isn't a boon.
> 
> We've been there in a particular configuration (one that included Emacs 
> being configured --without-tree-sitter).

Since the person who uses Emacs is many times different from the one
who configured it, I don't think that how Emacs was configured is
relevant.

> > Why is it a problem to ask users to whitelist some of these modes?
> 
> Not a problem, no. They can do this already by customizing 
> major-mode-remap-alist, for example.

That's true, but customizing a single variable might be easier and
more easily discoverable, I'd think?  If not, then we should leave
things as they are.

> >> This is also a valid approach, albeit a more complex one. This variable
> >> would only be tested during Emacs' startup, though, and during
> >> 'package-initialize', making its use not very transparent.
> > 
> > It will be tested right there in auto-mode-alist, like the change you
> > proposed, just with another test.
> 
> I'm concerned about the ergonomics of this option.

What ergonomics?

> >> E.g. we
> >> wouldn't react to having it changed in Customize. So it's not my
> >> preferred approach to this problem.
> > 
> > I don't see why this couldn't be a defcustom.
> 
> Would it have a non-default setter?

Probably.  Why is that a problem?

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> > Without the user's say-so, this could be considered a nuisance.  Why
>> > should Emacs annoy a user with some potential feature when the user
>> > didn't say she wants to use it?
>> 
>> Could be considered a nuisance, or a boon.
>
> See above: we've been there already, and we know it isn't a boon.

Thank you for making sure that Emacs doesn’t suddenly cause problems!

Though I think the disagreement hints that there’s something more
general that’s not as good as it could be: discoverability.

For keybindings, which-key-mode mostly solves that for me. But I don’t
know a way to finding that there’s a feature that could help me isn’t
better.

Tools like IntelliJ show (annoying) information toast messages. I don’t
know a good way for Emacs yet. But Emacs might benefit from getting an
unobtrusive way to inform users about more advanced options to solve
their tasks.

Maybe that could also be a thirdparty package: recommendations where
different people can show their different opinions.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  johan.myreen@gmail.com,
>   emacs-devel@gnu.org
> Date: Tue, 05 Nov 2024 14:21:36 +0100
> 
> Though I think the disagreement hints that there’s something more
> general that’s not as good as it could be: discoverability.

Discoverability doesn't mean the things need to be in my face.  It
means they are easy to discover _when_I_need_them_.  Nothing else will
work well in a package such as Emacs with thousands of features.

In order to be able to discover stuff in Emacs, I need at least to
know what I'm looking for.  I need to know to ask the questions.  If I
know to ask the right questions and use the right words, then the
built-in documentation has several commands which will make
discoverability easy.  (If they don't, please report specific bugs.)
But if I don't even know to ask the questions, I need to try, or to
guess, or to use some clever search engine, or just wait for that TIL
day to come.

> For keybindings, which-key-mode mostly solves that for me.

which-key-mode will not help you discover key bindings of packages you
haven't loaded into your session.  So various optional features that
define useful key bindings will not be discoverable that way.  For
example, if you type "C-c", which-key-mode will not tell you about key
bindings of, say, Outline mode, unless that mode is already activated.

> But I don’t know a way to finding that there’s a feature that could
> help me isn’t better.

Emacs has several Help commands specifically designed to ease
discoverability.  Take a look at the beginning of the Help chapter in
the Emacs user manual, where these facilities are described.

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Though I think the disagreement hints that there’s something more
>> general that’s not as good as it could be: discoverability.
>
> Discoverability doesn't mean the things need to be in my face.  It
> means they are easy to discover _when_I_need_them_.

That’s what I also wish for, yes.

>> For keybindings, which-key-mode mostly solves that for me.
>
> which-key-mode will not help you discover key bindings of packages you
> haven't loaded into your session.

Fully agreed. It’s a hint for possible solutions, not a solution to
discoverability of packages.

>> But I don’t know a way to finding that there’s a feature that could
>> help me isn’t better.
>
> Emacs has several Help commands specifically designed to ease
> discoverability.  Take a look at the beginning of the Help chapter in
> the Emacs user manual, where these facilities are described.

C-h p is neat! (I didn’t know about it — thank you!)

Most packages it shows me are built-in. Do I guess it right that the
reason is that most elpa and melpa packages don’t use package keywords?
If yes, that would give a clear way forward to improve discoverability
that does not depend on the core development team: file pull-requests
with packages to include the matching keywords.
That would be a nice task for a collaborative Emacs user hackathon.

Is there something similar for file-extensions?
I did not find that in the help page of the manual.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 05/11/2024 14:11, Eli Zaretskii wrote:

> (Are we really going to reiterate that old discussion?  Nothing's
> changed since then, so the opinions and conclusions will be exactly
> the same.)

No need. I thought we were in agreement earlier in this thread 
(https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00319.html), 
but apparently not.

>>> Why is it a problem to ask users to whitelist some of these modes?
>>
>> Not a problem, no. They can do this already by customizing
>> major-mode-remap-alist, for example.
> 
> That's true, but customizing a single variable might be easier and
> more easily discoverable, I'd think?  If not, then we should leave
> things as they are.

The key improvement is to make modes stop altering auto-mode-alist or 
major-mode-remap-defaults during package loading or in major mode functions.

>>>> This is also a valid approach, albeit a more complex one. This variable
>>>> would only be tested during Emacs' startup, though, and during
>>>> 'package-initialize', making its use not very transparent.
>>>
>>> It will be tested right there in auto-mode-alist, like the change you
>>> proposed, just with another test.
>>
>> I'm concerned about the ergonomics of this option.
> 
> What ergonomics?

User expectations, see below.

>>>> E.g. we
>>>> wouldn't react to having it changed in Customize. So it's not my
>>>> preferred approach to this problem.
>>>
>>> I don't see why this couldn't be a defcustom.
>>
>> Would it have a non-default setter?
> 
> Probably.  Why is that a problem?

Suppose the user customizes treesit-modes-enabled (the new option) to t.

Would that have to enable the file associations for all treesit major 
modes right away, in the same Emacs session? That would require having 
more data stored somewhere, which currently isn't. Some other 
registration hook for all ts modes to use.

If that's not necessary - not a problem then, easy to implement.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: dmitry@gutov.dev,  johan.myreen@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 05 Nov 2024 17:52:24 +0100
> 
> C-h p is neat! (I didn’t know about it — thank you!)
> 
> Most packages it shows me are built-in. Do I guess it right that the
> reason is that most elpa and melpa packages don’t use package keywords?

I don't know.  Maybe Philip (CC'ed) does.

> Is there something similar for file-extensions?

You mean, find a mode that handles files of certain extensions?  No, I
don't think so.  But I also don't really understand why you'd need
that, since the appropriate mode will be turned on automatically when
you visit such a file.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 5 Nov 2024 19:05:42 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/11/2024 14:11, Eli Zaretskii wrote:
> 
> > (Are we really going to reiterate that old discussion?  Nothing's
> > changed since then, so the opinions and conclusions will be exactly
> > the same.)
> 
> No need. I thought we were in agreement earlier in this thread 
> (https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00319.html), 
> but apparently not.

It was a misunderstanding.  Blame me.

> The key improvement is to make modes stop altering auto-mode-alist or 
> major-mode-remap-defaults during package loading or in major mode functions.

That might be an improvement from the POV of us the developers, but it
is of a very minor significance, if at all, from the users' POV.

> Suppose the user customizes treesit-modes-enabled (the new option) to t.
> 
> Would that have to enable the file associations for all treesit major 
> modes right away, in the same Emacs session?

Yes, I think so.

> That would require having more data stored somewhere, which
> currently isn't. Some other registration hook for all ts modes to
> use.

I don't think I understand what data are you talking about.

Re: An anonymous IRC user's opinion

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: dmitry@gutov.dev,  johan.myreen@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 05 Nov 2024 17:52:24 +0100
>> 
>> C-h p is neat! (I didn’t know about it — thank you!)
>> 
>> Most packages it shows me are built-in. Do I guess it right that the
>> reason is that most elpa and melpa packages don’t use package keywords?
>
> I don't know.  Maybe Philip (CC'ed) does.

I wouldn't say most, according

(let ((count 0))
  (dolist (desc package-archive-contents)
    (unless (package-desc--keywords (cadr desc))
      (message "Keyword for %s" (car desc))
      (cl-incf count)))
  (/ (float count) (length package-archive-contents)))

it is about 20%, which is more than I assumed, but certainly not a rule.
What I think is the issue here is that finder only lists installed
packages, which would explain why most are built-in.

A different issue is that not all packages use keywords that are listed
under `finder-known-keywords'.

>> Is there something similar for file-extensions?

Do you mean suggestions for packages based on file extension?  I wrote
up a draft for something like that a while back but never got around to
finishing it.  If you want to, I can try to create a scratch/ branch in
emacs.git to make it easier to try it out?

> You mean, find a mode that handles files of certain extensions?  No, I
> don't think so.  But I also don't really understand why you'd need
> that, since the appropriate mode will be turned on automatically when
> you visit such a file.

-- 
	Philip Kaludercic on siskin

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Philip Kaludercic <philipk@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> Is there something similar for file-extensions?
>
> Do you mean suggestions for packages based on file extension?  

That’ss what I mean, yes.

> I wrote up a draft for something like that a while back but never got
> around to finishing it. If you want to, I can try to create a scratch/
> branch in emacs.git to make it easier to try it out?

That would be nice!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 05/11/2024 19:28, Eli Zaretskii wrote:

>> Suppose the user customizes treesit-modes-enabled (the new option) to t.
>>
>> Would that have to enable the file associations for all treesit major
>> modes right away, in the same Emacs session?
> 
> Yes, I think so.
> 
>> That would require having more data stored somewhere, which
>> currently isn't. Some other registration hook for all ts modes to
>> use.
> 
> I don't think I understand what data are you talking about.

Suppose we have this in css-mode.el:

   ;;;###autoload
   (if (and (treesit-available-p)
            treesit-modes-enabled)
       (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))

And treesit-mode-enabled is originally nil.

Then the user customizes it to t.

What does its setter do? For css-ts-mode and other modes.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 5 Nov 2024 21:40:42 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/11/2024 19:28, Eli Zaretskii wrote:
> 
> >> Suppose the user customizes treesit-modes-enabled (the new option) to t.
> >>
> >> Would that have to enable the file associations for all treesit major
> >> modes right away, in the same Emacs session?
> > 
> > Yes, I think so.
> > 
> >> That would require having more data stored somewhere, which
> >> currently isn't. Some other registration hook for all ts modes to
> >> use.
> > 
> > I don't think I understand what data are you talking about.
> 
> Suppose we have this in css-mode.el:
> 
>    ;;;###autoload
>    (if (and (treesit-available-p)
>             treesit-modes-enabled)
>        (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
> 
> And treesit-mode-enabled is originally nil.
> 
> Then the user customizes it to t.
> 
> What does its setter do? For css-ts-mode and other modes.

It could turn the mode on in every buffer that visits a .css file.  Or
not.

Why do you ask?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 05/11/2024 21:53, Eli Zaretskii wrote:
>> Date: Tue, 5 Nov 2024 21:40:42 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 05/11/2024 19:28, Eli Zaretskii wrote:
>>
>>>> Suppose the user customizes treesit-modes-enabled (the new option) to t.
>>>>
>>>> Would that have to enable the file associations for all treesit major
>>>> modes right away, in the same Emacs session?
>>>
>>> Yes, I think so.
>>>
>>>> That would require having more data stored somewhere, which
>>>> currently isn't. Some other registration hook for all ts modes to
>>>> use.
>>>
>>> I don't think I understand what data are you talking about.
>>
>> Suppose we have this in css-mode.el:
>>
>>     ;;;###autoload
>>     (if (and (treesit-available-p)
>>              treesit-modes-enabled)
>>         (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
>>
>> And treesit-mode-enabled is originally nil.
>>
>> Then the user customizes it to t.
>>
>> What does its setter do? For css-ts-mode and other modes.
> 
> It could turn the mode on in every buffer that visits a .css file.  Or
> not.

Based on which information? We'd only have

   (define-derived-mode css-ts-mode css-base-mode "CSS"
     "Major mode to edit Cascading Style Sheets (CSS).
   \\<css-ts-mode-map>
     ...)

which has the name of the mode but not file extensions it applies to (or 
buffer names etc) and

   (defcustom treesit-enable-modes t
     "If non-nil, enable file associations for tree-sitter major modes."
     :version "31.1"
     :type 'boolean)

which does not reference the modes or the file names.

Re: An anonymous IRC user's opinion

[Philip Kaludercic]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> Is there something similar for file-extensions?
>>
>> Do you mean suggestions for packages based on file extension?  
>
> That’ss what I mean, yes.
>
>> I wrote up a draft for something like that a while back but never got
>> around to finishing it. If you want to, I can try to create a scratch/
>> branch in emacs.git to make it easier to try it out?
>
> That would be nice!

I have pushed some code to feature/package-autosuggest after cleaning it
up a bit.  The main issues right now are 1. that when clicking on the
suggestion to install a new package via the button in the major mode,
the UI wants to confirm this by pressing enter in the minibuffer which
is not automatically suggested 2. that the database of suggestions isn't
populated properly.  I'll probably write a script to scrape ELPA for
suggestions and generate them in the right format.

>
> Best wishes,
> Arne

-- 
	Philip Kaludercic on siskin

Re: An anonymous IRC user's opinion

[Dr. Arne Babenhauserheide]

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

Philip Kaludercic <philipk@posteo.net> writes:

> I have pushed some code to feature/package-autosuggest after cleaning it
> up a bit.  The main issues right now are 1. that when clicking on the
> suggestion to install a new package via the button in the major mode,
> the UI wants to confirm this by pressing enter in the minibuffer which
> is not automatically suggested 2. that the database of suggestions isn't
> populated properly.  I'll probably write a script to scrape ELPA for
> suggestions and generate them in the right format.

Thank you!

Is the modeline indicating option clickable?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: An anonymous IRC user's opinion

[Philip Kaludercic]

Yes.  But I have to adjust it so that if you click on it, a GUI confirmation can be displayed.

On 6 November 2024 10:35:33 CET, "Dr. Arne Babenhauserheide" <arne_bab@web.de> wrote:
>Philip Kaludercic <philipk@posteo.net> writes:
>
>> I have pushed some code to feature/package-autosuggest after cleaning it
>> up a bit.  The main issues right now are 1. that when clicking on the
>> suggestion to install a new package via the button in the major mode,
>> the UI wants to confirm this by pressing enter in the minibuffer which
>> is not automatically suggested 2. that the database of suggestions isn't
>> populated properly.  I'll probably write a script to scrape ELPA for
>> suggestions and generate them in the right format.
>
>Thank you!
>
>Is the modeline indicating option clickable?
>
>Best wishes,
>Arne

-- 
Sent from my phone. Please excuse my brevity and bad formatting.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 5 Nov 2024 22:59:09 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/11/2024 21:53, Eli Zaretskii wrote:
> >> Suppose we have this in css-mode.el:
> >>
> >>     ;;;###autoload
> >>     (if (and (treesit-available-p)
> >>              treesit-modes-enabled)
> >>         (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
> >>
> >> And treesit-mode-enabled is originally nil.
> >>
> >> Then the user customizes it to t.
> >>
> >> What does its setter do? For css-ts-mode and other modes.
> > 
> > It could turn the mode on in every buffer that visits a .css file.  Or
> > not.
> 
> Based on which information?

buffer-file-name and auto-mode-alist, I guess?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

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

On Wed, Nov 6, 2024, at 2:15 PM, Eli Zaretskii wrote:
> > Date: Tue, 5 Nov 2024 22:59:09 +0200
> > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> > 
> > On 05/11/2024 21:53, Eli Zaretskii wrote:
> > >> Suppose we have this in css-mode.el:
> > >>
> > >>     ;;;###autoload
> > >>     (if (and (treesit-available-p)
> > >>              treesit-modes-enabled)
> > >>         (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
> > >>
> > >> And treesit-mode-enabled is originally nil.
> > >>
> > >> Then the user customizes it to t.
> > >>
> > >> What does its setter do? For css-ts-mode and other modes.
> > > 
> > > It could turn the mode on in every buffer that visits a .css file.  Or
> > > not.
> > 
> > Based on which information?
> 
> buffer-file-name and auto-mode-alist, I guess?
But auto-mode-alist won't have any relevant entries because when its form (above) was evaluated, treesit-modes-enabled was nil.

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

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Wed, 06 Nov 2024 14:46:48 +0200
> From: "Dmitry Gutov" <dmitry@gutov.dev>
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> 
> 
> On Wed, Nov 6, 2024, at 2:15 PM, Eli Zaretskii wrote:
> 
>  > Date: Tue, 5 Nov 2024 22:59:09 +0200
>  > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>  > From: Dmitry Gutov <dmitry@gutov.dev>
>  > 
>  > On 05/11/2024 21:53, Eli Zaretskii wrote:
>  > >> Suppose we have this in css-mode.el:
>  > >>
>  > >>     ;;;###autoload
>  > >>     (if (and (treesit-available-p)
>  > >>              treesit-modes-enabled)
>  > >>         (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
>  > >>
>  > >> And treesit-mode-enabled is originally nil.
>  > >>
>  > >> Then the user customizes it to t.
>  > >>
>  > >> What does its setter do? For css-ts-mode and other modes.
>  > > 
>  > > It could turn the mode on in every buffer that visits a .css file.  Or
>  > > not.
>  > 
>  > Based on which information?
> 
>  buffer-file-name and auto-mode-alist, I guess?
> 
> But auto-mode-alist won't have any relevant entries because when its form (above) was evaluated,
> treesit-modes-enabled was nil.

Are you saying that it is impossible to turn on the mode in relevant
buffers?  I find that hard to believe, but if you are right, then we
could refrain from doing this retroactively.

(And I still don't understand where this discussion is going.  What
point are you trying to make?)

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 06/11/2024 15:25, Eli Zaretskii wrote:
>> Date: Wed, 06 Nov 2024 14:46:48 +0200
>> From: "Dmitry Gutov" <dmitry@gutov.dev>
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>>
>>
>> On Wed, Nov 6, 2024, at 2:15 PM, Eli Zaretskii wrote:
>>
>>   > Date: Tue, 5 Nov 2024 22:59:09 +0200
>>   > Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>>   > From: Dmitry Gutov <dmitry@gutov.dev>
>>   >
>>   > On 05/11/2024 21:53, Eli Zaretskii wrote:
>>   > >> Suppose we have this in css-mode.el:
>>   > >>
>>   > >>     ;;;###autoload
>>   > >>     (if (and (treesit-available-p)
>>   > >>              treesit-modes-enabled)
>>   > >>         (add-to-list 'auto-mode-alist '("\\.css\\'" . css-ts-mode)))
>>   > >>
>>   > >> And treesit-mode-enabled is originally nil.
>>   > >>
>>   > >> Then the user customizes it to t.
>>   > >>
>>   > >> What does its setter do? For css-ts-mode and other modes.
>>   > >
>>   > > It could turn the mode on in every buffer that visits a .css file.  Or
>>   > > not.
>>   >
>>   > Based on which information?
>>
>>   buffer-file-name and auto-mode-alist, I guess?
>>
>> But auto-mode-alist won't have any relevant entries because when its form (above) was evaluated,
>> treesit-modes-enabled was nil.
> 
> Are you saying that it is impossible to turn on the mode in relevant
> buffers?  I find that hard to believe, but if you are right, then we
> could refrain from doing this retroactively.
> 
> (And I still don't understand where this discussion is going.  What
> point are you trying to make?)

I'm not trying to make a point, but to find the right tradeoffs.

You wanted a user option - sure, no problem. But if taken the most 
straightforward approach, the option would only have effect after 
restart, and not on the current session. Otherwise it would need more 
information available somehow. You asked which data - the description 
was in the previous messages.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Wed, 6 Nov 2024 18:07:46 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 06/11/2024 15:25, Eli Zaretskii wrote:
> >>
> >> But auto-mode-alist won't have any relevant entries because when its form (above) was evaluated,
> >> treesit-modes-enabled was nil.
> > 
> > Are you saying that it is impossible to turn on the mode in relevant
> > buffers?  I find that hard to believe, but if you are right, then we
> > could refrain from doing this retroactively.
> > 
> > (And I still don't understand where this discussion is going.  What
> > point are you trying to make?)
> 
> I'm not trying to make a point, but to find the right tradeoffs.
> 
> You wanted a user option - sure, no problem. But if taken the most 
> straightforward approach, the option would only have effect after 
> restart, and not on the current session. Otherwise it would need more 
> information available somehow. You asked which data - the description 
> was in the previous messages.

First, I still believe we can find a way of turning the enabled modes
on in the existing buffers.  Your arguments and questions seem to
imply that the simplest solutions might have difficulties, but they
didn't convince me that this is impossible or impractical in
principle.

But even if the customization will affect only files visited after it,
that's not a catastrophe, IMO, as we already have other customizations
with similar behaviors.  And since we now have restart-emacs,
restarting is not a big problem, either.

So I think a tradeoff of asking users to explicitly express their
preferences for these modes before we enable them is an okay tradeoff.

Automatic Suggestion of Packages

[Philip Kaludercic]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I have pushed some code to feature/package-autosuggest after cleaning it
>> up a bit.  The main issues right now are 1. that when clicking on the
>> suggestion to install a new package via the button in the major mode,
>> the UI wants to confirm this by pressing enter in the minibuffer which
>> is not automatically suggested 2. that the database of suggestions isn't
>> populated properly.  I'll probably write a script to scrape ELPA for
>> suggestions and generate them in the right format.
>
> Thank you!
>
> Is the modeline indicating option clickable?

If it is useful, I have made a little screen-recording of how the
feature looks like as of current state on feature/package-autosuggest:

https://spectra.video/w/e93b3XqNzN6yXucZbNnu7c

I have copied the approach used by `gnu-elpa' to scrape the autoload
files of ELPA packages to gather suggestions.  You can find the database
here:

https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/package-autosuggest.eld?h=feature/package-autosuggest

> Best wishes,
> Arne

-- 
	Philip Kaludercic on siskin

Re: Automatic Suggestion of Packages

[Visuwesh]

[வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> I have pushed some code to feature/package-autosuggest after cleaning it
>>> up a bit.  The main issues right now are 1. that when clicking on the
>>> suggestion to install a new package via the button in the major mode,
>>> the UI wants to confirm this by pressing enter in the minibuffer which
>>> is not automatically suggested 2. that the database of suggestions isn't
>>> populated properly.  I'll probably write a script to scrape ELPA for
>>> suggestions and generate them in the right format.
>>
>> Thank you!
>>
>> Is the modeline indicating option clickable?
>
> If it is useful, I have made a little screen-recording of how the
> feature looks like as of current state on feature/package-autosuggest:
>
> https://spectra.video/w/e93b3XqNzN6yXucZbNnu7c

Can we have an user option to both `message' the user and have a button
in the mode-line?  I usually don't notice changes in the mode-line
often, but notice messages in the echo-area.  Just having `message'
would lose the convenient mode-line button to auto-install the suggested
package.

Re: Automatic Suggestion of Packages

[Philip Kaludercic]

Visuwesh <visuweshm@gmail.com> writes:

> [வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:
>
>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> I have pushed some code to feature/package-autosuggest after cleaning it
>>>> up a bit.  The main issues right now are 1. that when clicking on the
>>>> suggestion to install a new package via the button in the major mode,
>>>> the UI wants to confirm this by pressing enter in the minibuffer which
>>>> is not automatically suggested 2. that the database of suggestions isn't
>>>> populated properly.  I'll probably write a script to scrape ELPA for
>>>> suggestions and generate them in the right format.
>>>
>>> Thank you!
>>>
>>> Is the modeline indicating option clickable?
>>
>> If it is useful, I have made a little screen-recording of how the
>> feature looks like as of current state on feature/package-autosuggest:
>>
>> https://spectra.video/w/e93b3XqNzN6yXucZbNnu7c
>
> Can we have an user option to both `message' the user and have a button
> in the mode-line?  I usually don't notice changes in the mode-line
> often, but notice messages in the echo-area.  Just having `message'
> would lose the convenient mode-line button to auto-install the suggested
> package.

We can do that, it might be worth discussing if the user option should
be re-designed.  The current styles of presenting suggestions are:

1. A button in the mode-line (default)
2. A message with a hint to use `package-autosuggest' (which I think is
   convenient enough)
3. A `yes-or-no-p'-prompt to install a package (either every time a
   suggestion is available or only once per package)

I don't know if the last one makes sense to have, as it is pretty
aggressive.  Perhaps it makes sense to always present a message if the
minor mode is enabled, and add a separate option to enable the mode-line
button?

-- 
	Philip Kaludercic on siskin

Re: Automatic Suggestion of Packages

[Visuwesh]

[வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:

>> Can we have an user option to both `message' the user and have a button
>> in the mode-line?  I usually don't notice changes in the mode-line
>> often, but notice messages in the echo-area.  Just having `message'
>> would lose the convenient mode-line button to auto-install the suggested
>> package.
>
> We can do that, it might be worth discussing if the user option should
> be re-designed.  The current styles of presenting suggestions are:
>
> 1. A button in the mode-line (default)
> 2. A message with a hint to use `package-autosuggest' (which I think is
>    convenient enough)
> 3. A `yes-or-no-p'-prompt to install a package (either every time a
>    suggestion is available or only once per package)
>
> I don't know if the last one makes sense to have, as it is pretty
> aggressive.

Indeed, I agree that it feels very un-Emacsy to be up in the face like
that.

> Perhaps it makes sense to always present a message if the minor mode
> is enabled, and add a separate option to enable the mode-line button?

I would be happy with this (though I would turn the mode-line button on
by default).

Re: Automatic Suggestion of Packages

[Visuwesh]

[வெள்ளி நவம்பர் 08, 2024] Visuwesh wrote:

> [வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:
>
>>> Can we have an user option to both `message' the user and have a button
>>> in the mode-line?  I usually don't notice changes in the mode-line
>>> often, but notice messages in the echo-area.  Just having `message'
>>> would lose the convenient mode-line button to auto-install the suggested
>>> package.
>>
>> We can do that, it might be worth discussing if the user option should
>> be re-designed.  The current styles of presenting suggestions are:
>>
>> 1. A button in the mode-line (default)
>> 2. A message with a hint to use `package-autosuggest' (which I think is
>>    convenient enough)
>> 3. A `yes-or-no-p'-prompt to install a package (either every time a
>>    suggestion is available or only once per package)
>>
>> I don't know if the last one makes sense to have, as it is pretty
>> aggressive.
>
> Indeed, I agree that it feels very un-Emacsy to be up in the face like
> that.
>
>> Perhaps it makes sense to always present a message if the minor mode
>> is enabled, and add a separate option to enable the mode-line button?
>
> I would be happy with this (though I would turn the mode-line button on
> by default).

BTW, I looked at the code to see what it does when there's multiple
packages suggested for a single (e.g., racket: racket-mode and
geiser-racket).  It seems to install and enable only the first
suggestion: should we instead prompt the user about it?  But asking the
user would defeat the purpose of the feature, which helps in assisting
her in setting up her environment for her work.

Re: Automatic Suggestion of Packages

[Philip Kaludercic]

Visuwesh <visuweshm@gmail.com> writes:

> [வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:
>
>>> Can we have an user option to both `message' the user and have a button
>>> in the mode-line?  I usually don't notice changes in the mode-line
>>> often, but notice messages in the echo-area.  Just having `message'
>>> would lose the convenient mode-line button to auto-install the suggested
>>> package.
>>
>> We can do that, it might be worth discussing if the user option should
>> be re-designed.  The current styles of presenting suggestions are:
>>
>> 1. A button in the mode-line (default)
>> 2. A message with a hint to use `package-autosuggest' (which I think is
>>    convenient enough)
>> 3. A `yes-or-no-p'-prompt to install a package (either every time a
>>    suggestion is available or only once per package)
>>
>> I don't know if the last one makes sense to have, as it is pretty
>> aggressive.
>
> Indeed, I agree that it feels very un-Emacsy to be up in the face like
> that.
>
>> Perhaps it makes sense to always present a message if the minor mode
>> is enabled, and add a separate option to enable the mode-line button?
>
> I would be happy with this (though I would turn the mode-line button on
> by default).

The issue with enable-by-default in the current implementation is that
we would have to load package.el by default, which is currently avoided
to reduce the startup time (see `package-enable-at-startup').

We could extract the autosuggest logic into a separate file and suggest
loading that by default.

We could also consider not using the mode line, but the menu bar to hint
at package suggestions, but that might be easy to miss especially if a
lot of people advise disabling the menu bar.

Visuwesh <visuweshm@gmail.com> writes:

> [வெள்ளி நவம்பர் 08, 2024] Visuwesh wrote:
>
>> [வியாழன் நவம்பர் 07, 2024] Philip Kaludercic wrote:
>>
>>>> Can we have an user option to both `message' the user and have a button
>>>> in the mode-line?  I usually don't notice changes in the mode-line
>>>> often, but notice messages in the echo-area.  Just having `message'
>>>> would lose the convenient mode-line button to auto-install the suggested
>>>> package.
>>>
>>> We can do that, it might be worth discussing if the user option should
>>> be re-designed.  The current styles of presenting suggestions are:
>>>
>>> 1. A button in the mode-line (default)
>>> 2. A message with a hint to use `package-autosuggest' (which I think is
>>>    convenient enough)
>>> 3. A `yes-or-no-p'-prompt to install a package (either every time a
>>>    suggestion is available or only once per package)
>>>
>>> I don't know if the last one makes sense to have, as it is pretty
>>> aggressive.
>>
>> Indeed, I agree that it feels very un-Emacsy to be up in the face like
>> that.
>>
>>> Perhaps it makes sense to always present a message if the minor mode
>>> is enabled, and add a separate option to enable the mode-line button?
>>
>> I would be happy with this (though I would turn the mode-line button on
>> by default).
>
> BTW, I looked at the code to see what it does when there's multiple
> packages suggested for a single (e.g., racket: racket-mode and
> geiser-racket).  It seems to install and enable only the first
> suggestion: should we instead prompt the user about it?  But asking the
> user would defeat the purpose of the feature, which helps in assisting
> her in setting up her environment for her work.

No the current implementation would just install everything.  Neither of
the two solutions are really ideal.  Perhaps we need to pop up a buffer
with clickable elements to present the package suggestions and propose
installing one of them?

-- 
	Philip Kaludercic on siskin

Re: Automatic Suggestion of Packages

[Visuwesh]

[வெள்ளி நவம்பர் 08, 2024] Philip Kaludercic wrote:

>>> [...]
>>> Perhaps it makes sense to always present a message if the minor mode
>>> is enabled, and add a separate option to enable the mode-line button?
>>
>> I would be happy with this (though I would turn the mode-line button on
>> by default).
>
> The issue with enable-by-default in the current implementation is that
> we would have to load package.el by default, which is currently avoided
> to reduce the startup time (see `package-enable-at-startup').

I see.

>
> We could extract the autosuggest logic into a separate file and suggest
> loading that by default.
>
> We could also consider not using the mode line, but the menu bar to hint
> at package suggestions, but that might be easy to miss especially if a
> lot of people advise disabling the menu bar.

That is a good idea too.

>> BTW, I looked at the code to see what it does when there's multiple
>> packages suggested for a single (e.g., racket: racket-mode and
>> geiser-racket).  It seems to install and enable only the first
>> suggestion: should we instead prompt the user about it?  But asking the
>> user would defeat the purpose of the feature, which helps in assisting
>> her in setting up her environment for her work.
>
> No the current implementation would just install everything.  Neither of
> the two solutions are really ideal.  Perhaps we need to pop up a buffer
> with clickable elements to present the package suggestions and propose
> installing one of them?

It would help the user decide between the packages if some kind of
popularity metric is shown.  If they cannot decide between the options,
they could at least pick the most popular one and go with that.  I think
the current one shown in the GNU ELPA website should be sufficient for
most cases.
Although I dislike the idea myself personally, "last updated time" might
be a good indication too.  [ I dislike it because stable packages don't
need to get updated.  After all, they just work.  ]

Re: Automatic Suggestion of Packages

[Philip Kaludercic]

Visuwesh <visuweshm@gmail.com> writes:

> [வெள்ளி நவம்பர் 08, 2024] Philip Kaludercic wrote:
>
>>>> [...]
>>>> Perhaps it makes sense to always present a message if the minor mode
>>>> is enabled, and add a separate option to enable the mode-line button?
>>>
>>> I would be happy with this (though I would turn the mode-line button on
>>> by default).
>>
>> The issue with enable-by-default in the current implementation is that
>> we would have to load package.el by default, which is currently avoided
>> to reduce the startup time (see `package-enable-at-startup').
>
> I see.
>
>>
>> We could extract the autosuggest logic into a separate file and suggest
>> loading that by default.
>>
>> We could also consider not using the mode line, but the menu bar to hint
>> at package suggestions, but that might be easy to miss especially if a
>> lot of people advise disabling the menu bar.
>
> That is a good idea too.
>
>>> BTW, I looked at the code to see what it does when there's multiple
>>> packages suggested for a single (e.g., racket: racket-mode and
>>> geiser-racket).  It seems to install and enable only the first
>>> suggestion: should we instead prompt the user about it?  But asking the
>>> user would defeat the purpose of the feature, which helps in assisting
>>> her in setting up her environment for her work.
>>
>> No the current implementation would just install everything.  Neither of
>> the two solutions are really ideal.  Perhaps we need to pop up a buffer
>> with clickable elements to present the package suggestions and propose
>> installing one of them?
>
> It would help the user decide between the packages if some kind of
> popularity metric is shown.  If they cannot decide between the options,
> they could at least pick the most popular one and go with that.  I think
> the current one shown in the GNU ELPA website should be sufficient for
> most cases.
> Although I dislike the idea myself personally, "last updated time" might
> be a good indication too.  [ I dislike it because stable packages don't
> need to get updated.  After all, they just work.  ]

AFAIK we don't currently expose the ranking information via some API,
but that might change in the future.  Last updated has advantages and
disadvantages that one should be weary of (a stable package might be
seldom updated and a newer package more frequently as it is trying to
become more mature).

The core of the problem to me seems that we have situations where a file
extensions might be used by multiple languages (as is currently the
situation with Perl and Prolog, both commonly using ".p").  Assuming
these were ELPA packages and not-built-in, we could try to combine the
data, e.g. if the interpreter and the file name agree, only the propose
Perl and not Prolog.  Yet it is probably the safest option to engage
human judgement and present the options, in a simple menu listing
package names, their summaries and a button to install the package.

Based on what I am imagining, the complementary issue that you
mention, "racket-mode" vs "geiser-racket" would pop up a buffer that
would look something this:

--8<---------------cut here---------------start------------->8---
There are multiple package suggestions based on the available
information:

 - "racket-mode"                                        [install]

     Racket editing, REPL, and more

   Suggested due to: file name matching \.rkt\', the interpreter
   matching "racket".

 - "geiser-racket"                                      [install]

     Support for Racket in Geiser

   Suggested due to: file name matching \.rkt\'
--8<---------------cut here---------------end--------------->8---

-- 
	Philip Kaludercic on siskin

Re: Automatic Suggestion of Packages

[Mekeor Melire]

Thanks, Philip, for working on this feature.

As far as I can tell, your code is based on this workflow: Emacs
maintainers regularly locally build GNU Elpa as well as NonGNU
Elpa. They run the admin/scrape-elpa.el script which updates the
package-autosuggest.eld file that is part of the Emacs Git
repository. They review the changes and commit them.

This has some disadvantages: It is quiet some work for the core Emacs
maintainers: They need to judge if a package is a valid package for a
certain file. Only GNU and NonGNU Elpa packages are respected; other
package archives are not. Changes to the package-autosuggest.eld file
would not reach end-users until another Emacs release.

More generally, I have the impression that this is not the right place
to implement this feature. I think every package should be able to
suggest itself for certain file extensions (or even file beginnings or
endings like magic-mode-alist). I suggest to introduce a new package
header similar to these:

;; Covered-File-Extensions: ("\\.c$" "\\.h$")
;; Covered-Magic-Beginnings: ("^#!/bin/sh")

These headers would become part of the package structure and would be
distributed by package archives and would end on the end-users' local
device. In particular, if you have Melpa set up locally, you would be
able to find out which Melpa-packages cover .c extensions by filtering
your local package list accordingly.

This, of course, is much more work; but it seems to be the right thing
to do, to me. What do you think?

Re: Automatic Suggestion of Packages

[Philip Kaludercic]

Mekeor Melire <mekeor@posteo.de> writes:

> Thanks, Philip, for working on this feature.
>
> As far as I can tell, your code is based on this workflow: Emacs
> maintainers regularly locally build GNU Elpa as well as NonGNU
> Elpa. They run the admin/scrape-elpa.el script which updates the
> package-autosuggest.eld file that is part of the Emacs Git
> repository. They review the changes and commit them.

Right.

> This has some disadvantages: It is quiet some work for the core Emacs
> maintainers: They need to judge if a package is a valid package for a
> certain file. 

This is true, but it would usually be the ELPA maintainers that update
package-autosuggest.eld anyway, and I hope it should be manageable to
just review the diff.

>               Only GNU and NonGNU Elpa packages are respected; other
> package archives are not. Changes to the package-autosuggest.eld file
> would not reach end-users until another Emacs release.

These are valid points, though not unsubstantiated.  Restricting the
packages to {,Non}GNU ELPA is intentional, as all users should have
these archives configured (unless they intentionally disabled them,
which is unusual AFAIK).  These packages should also align with Emacs
free-software policy, to ensure that a upfront suggestion to install a
package respects user-freedom.

That being said, there have been discussions to update the
package.el-API (the "archive-contents" file), in which case we could
consider providing package suggestions.  In that case I would like to
add an option to filter what archives are allowed to make suggestions
(following the above logic, this would be set to the ELPAs by default,
but the user could add personal or third-party if they wish to the
list).

> More generally, I have the impression that this is not the right place
> to implement this feature. I think every package should be able to
> suggest itself for certain file extensions (or even file beginnings or
> endings like magic-mode-alist). I suggest to introduce a new package
> header similar to these:
>
> ;; Covered-File-Extensions: ("\\.c$" "\\.h$")
> ;; Covered-Magic-Beginnings: ("^#!/bin/sh")
>
> These headers would become part of the package structure and would be
> distributed by package archives and would end on the end-users' local
> device. In particular, if you have Melpa set up locally, you would be
> able to find out which Melpa-packages cover .c extensions by filtering
> your local package list accordingly.
>
> This, of course, is much more work; but it seems to be the right thing
> to do, to me. What do you think?

The main issue is that we wouldn't have anything to work with right
away.  We could consider this in the future (along with the updated API
idea, where archives could decide on how to implement this on their
own), but my question is wouldn't these archives coincide with
autoloaded `add-to-list' expressions?  When would a package hint that it
could be useful for .foo-files, but not update `auto-mode-alist'?

The headers might be interesting to hint different priorities, so as to
differentiate between something as foundational as a major mode and
something nice-to-have like a minor-mode or a set of commands.

-- 
	Philip Kaludercic on siskin

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

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

On 06/11/2024 19:14, Eli Zaretskii wrote:

>> You wanted a user option - sure, no problem. But if taken the most
>> straightforward approach, the option would only have effect after
>> restart, and not on the current session. Otherwise it would need more
>> information available somehow. You asked which data - the description
>> was in the previous messages.
> 
> First, I still believe we can find a way of turning the enabled modes
> on in the existing buffers.

Existing buffers vs new buffers is not the main issue. Getting the 
auto-mode-alist or major-mode-alias-alist entries for modes that were 
previously "off" is something we'd need a registry for.

Meaning, for example, new variables like treesit-auto-mode-alist and 
treesit-major-mode-alist-alist which would keep the associations "in 
store" until we decide to enable the modes. On balance, it seems like 
overkill.

Unless... we move all association settings from the built-in modes into 
treesit.el - then this stuff would only live in one place, at least. No 
access to the data from the "outside" => no new public vars necessary.

The way to use the attached change (the main part is in treesit.el):

   (require 'treesit)
   (setopt treesit-enable-modes t)

We could also autoload the new defcustom to make the first line 
unnecessary (though that's generally discouraged), or move its 
definition to an existing preloaded file.

[-- Attachment #2: treesit-enable-modes.diff --]
[-- Type: text/x-patch, Size: 5094 bytes --]

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 3823c553fda..5b89fe917c2 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -35,12 +35,6 @@
 ;; To use these modes by default, assuming you have the respective
 ;; tree-sitter grammars available, do one of the following:
 ;;
-;; - If you have both C and C++ grammars installed, add
-;;
-;;    (require 'c-ts-mode)
-;;
-;;   to your init file.
-;;
 ;; - Add one or mode of the following to your init file:
 ;;
 ;;    (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))
@@ -1539,21 +1533,6 @@ c-or-c++-ts-mode
            'c-ts-mode)))
     (funcall (major-mode-remap mode))))
 
-;; The entries for C++ must come first to prevent *.c files be taken
-;; as C++ on case-insensitive filesystems, since *.C files are C++,
-;; not C.
-(if (treesit-ready-p 'cpp)
-    (add-to-list 'major-mode-remap-defaults
-                 '(c++-mode . c++-ts-mode)))
-
-(when (treesit-ready-p 'c)
-  (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode))
-  (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)))
-
-(when (and (treesit-ready-p 'cpp)
-           (treesit-ready-p 'c))
-  (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)))
-
 (when (and c-ts-mode-enable-doxygen (not (treesit-ready-p 'doxygen t)))
   (message "Doxygen syntax highlighting can't be enabled, please install the language grammar."))
 
diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mode.el
index cacdb266298..0adfbff1115 100644
--- a/lisp/progmodes/elixir-ts-mode.el
+++ b/lisp/progmodes/elixir-ts-mode.el
@@ -755,13 +755,6 @@ elixir-ts-mode
 
 (derived-mode-add-parents 'elixir-ts-mode '(elixir-mode))
 
-(if (treesit-ready-p 'elixir)
-    (progn
-      (add-to-list 'auto-mode-alist '("\\.elixir\\'" . elixir-ts-mode))
-      (add-to-list 'auto-mode-alist '("\\.ex\\'" . elixir-ts-mode))
-      (add-to-list 'auto-mode-alist '("\\.exs\\'" . elixir-ts-mode))
-      (add-to-list 'auto-mode-alist '("mix\\.lock" . elixir-ts-mode))))
-
 (provide 'elixir-ts-mode)
 
 ;;; elixir-ts-mode.el ends here
diff --git a/lisp/progmodes/go-ts-mode.el b/lisp/progmodes/go-ts-mode.el
index 86e74ad58a8..f306b6c3c37 100644
--- a/lisp/progmodes/go-ts-mode.el
+++ b/lisp/progmodes/go-ts-mode.el
@@ -305,11 +305,6 @@ go-ts-mode
 
 (derived-mode-add-parents 'go-ts-mode '(go-mode))
 
-(if (treesit-ready-p 'go)
-    ;; FIXME: Should we instead put `go-mode' in `auto-mode-alist'
-    ;; and then use `major-mode-remap-defaults' to map it to `go-ts-mode'?
-    (add-to-list 'auto-mode-alist '("\\.go\\'" . go-ts-mode)))
-
 (defun go-ts-mode--defun-name (node &optional skip-prefix)
   "Return the defun name of NODE.
 Return nil if there is no name or if NODE is not a defun node.
@@ -562,9 +557,6 @@ go-mod-ts-mode
 
 (derived-mode-add-parents 'go-mod-ts-mode '(go-mod-mode))
 
-(if (treesit-ready-p 'gomod)
-    (add-to-list 'auto-mode-alist '("/go\\.mod\\'" . go-mod-ts-mode)))
-
 (provide 'go-ts-mode)
 
 ;;; go-ts-mode.el ends here
diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index f74b8ab1c46..a4d4399012c 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -3961,10 +3961,7 @@ js-ts-mode
                                         "method_definition")
                                 eos)
                    nil nil)))
-    (treesit-major-mode-setup)
-
-    (add-to-list 'auto-mode-alist
-                 '("\\(\\.js[mx]\\|\\.har\\)\\'" . js-ts-mode))))
+    (treesit-major-mode-setup)))
 
 (derived-mode-add-parents 'js-ts-mode '(js-mode))
 
diff --git a/lisp/treesit.el b/lisp/treesit.el
index 6f5d065cc24..94b8278b2b6 100644
--- a/lisp/treesit.el
+++ b/lisp/treesit.el
@@ -950,6 +950,38 @@ treesit-font-lock-level
   :set #'treesit--font-lock-level-setter
   :version "29.1")
 
+(defvar treesit--mode-associations
+  '((javascript-mode . js-ts-mode )
+    (c-or-c++-mode . c-or-c++-ts-mode)
+    (c-mode . c-ts-mode)
+    (c++-mode . c++-ts-mode)
+    ("\\.elixir\\'" . elixir-ts-mode)
+    ("\\.ex\\'" . elixir-ts-mode)
+    ("\\.go\\'" . go-ts-mode)
+    ;; And so on.
+    ;; Some info needed for interpreter-mode-alist as well.
+    ))
+
+(defun treesit-enable-modes--set (sym value)
+  (set-default sym value)
+
+  (dolist (elem treesit--mode-associations)
+    (let* ((use-ama (stringp (car elem))))
+      (if value
+          (if (stringp (car elem))
+              (add-to-list 'auto-mode-alist elem)
+            (add-to-list 'major-mode-remap-alist elem))
+        (if use-ama
+            (setq auto-mode-alist (delete elem auto-mode-alist))
+          (setq major-mode-remap-alist
+                (delete elem major-mode-remap-alist)))))))
+
+(defcustom treesit-enable-modes nil
+  "Non-nil to enable tree-sitter modes during Emacs's startup."
+  :type 'boolean
+  :version "31.1"
+  :set #'treesit-enable-modes--set)
+
 (defvar-local treesit--font-lock-query-expand-range (cons 0 0)
   "The amount to expand the start and end of the region when fontifying.
 This should be a cons cell (START . END).  When fontifying a

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 19 Nov 2024 04:44:06 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> You wanted a user option - sure, no problem. But if taken the most
> >> straightforward approach, the option would only have effect after
> >> restart, and not on the current session. Otherwise it would need more
> >> information available somehow. You asked which data - the description
> >> was in the previous messages.
> > 
> > First, I still believe we can find a way of turning the enabled modes
> > on in the existing buffers.
> 
> Existing buffers vs new buffers is not the main issue. Getting the 
> auto-mode-alist or major-mode-alias-alist entries for modes that were 
> previously "off" is something we'd need a registry for.

I don't think I follow: what are the problems with simply adding
associations to auto-mode-alist?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 19/11/2024 17:41, Eli Zaretskii wrote:
>> Date: Tue, 19 Nov 2024 04:44:06 +0200
>> Cc:johan.myreen@gmail.com,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>>>> You wanted a user option - sure, no problem. But if taken the most
>>>> straightforward approach, the option would only have effect after
>>>> restart, and not on the current session. Otherwise it would need more
>>>> information available somehow. You asked which data - the description
>>>> was in the previous messages.
>>> First, I still believe we can find a way of turning the enabled modes
>>> on in the existing buffers.
>> Existing buffers vs new buffers is not the main issue. Getting the
>> auto-mode-alist or major-mode-alias-alist entries for modes that were
>> previously "off" is something we'd need a registry for.
> I don't think I follow: what are the problems with simply adding
> associations to auto-mode-alist?

When treesit-enable-modes is nil?

Which it apparently will be by default.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 19 Nov 2024 18:13:31 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 19/11/2024 17:41, Eli Zaretskii wrote:
> >> Date: Tue, 19 Nov 2024 04:44:06 +0200
> >> Cc:johan.myreen@gmail.com,emacs-devel@gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >>>> You wanted a user option - sure, no problem. But if taken the most
> >>>> straightforward approach, the option would only have effect after
> >>>> restart, and not on the current session. Otherwise it would need more
> >>>> information available somehow. You asked which data - the description
> >>>> was in the previous messages.
> >>> First, I still believe we can find a way of turning the enabled modes
> >>> on in the existing buffers.
> >> Existing buffers vs new buffers is not the main issue. Getting the
> >> auto-mode-alist or major-mode-alias-alist entries for modes that were
> >> previously "off" is something we'd need a registry for.
> > I don't think I follow: what are the problems with simply adding
> > associations to auto-mode-alist?
> 
> When treesit-enable-modes is nil?

No, when the user customizes it to specify some TS modes as preferred.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 19/11/2024 19:10, Eli Zaretskii wrote:
>>> I don't think I follow: what are the problems with simply adding
>>> associations to auto-mode-alist?
>> When treesit-enable-modes is nil?
> No, when the user customizes it to specify some TS modes as preferred.

Using which data? We seem to be going in circles.

Anyway, see the patch from my message 15 hours ago, lmk what you think.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 19 Nov 2024 19:40:18 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 19/11/2024 19:10, Eli Zaretskii wrote:
> >>> I don't think I follow: what are the problems with simply adding
> >>> associations to auto-mode-alist?
> >> When treesit-enable-modes is nil?
> > No, when the user customizes it to specify some TS modes as preferred.
> 
> Using which data?

What data is needed?

> We seem to be going in circles.

That's probably due to long gaps between messages.

> Anyway, see the patch from my message 15 hours ago, lmk what you think.

Wasn't the idea that the user will tell us which files she wants to
visit in each mode?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 19/11/2024 19:47, Eli Zaretskii wrote:
>> Date: Tue, 19 Nov 2024 19:40:18 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 19/11/2024 19:10, Eli Zaretskii wrote:
>>>>> I don't think I follow: what are the problems with simply adding
>>>>> associations to auto-mode-alist?
>>>> When treesit-enable-modes is nil?
>>> No, when the user customizes it to specify some TS modes as preferred.
>>
>> Using which data?
> 
> What data is needed?

The values to put into auto-mode-alist, e.g. the regexp(s).

Normally, such an entry is added to auto-mode-alist during Emacs's 
startup (whether from that option's init form, or using package 
autoloads). If we want to do it later from the newly added option's 
setter, the setter needs to get the values from somewhere.

>> Anyway, see the patch from my message 15 hours ago, lmk what you think.
> 
> Wasn't the idea that the user will tell us which files she wants to
> visit in each mode?

I think we talked about making the option more granular (allowing to set 
it not just to t, but to a list of modes). That will be easy to add.

But specifying the files as well is news to me. Wouldn't users who want 
that level of detail just go and customize auto-mode-alist instead?

Re: An anonymous IRC user's opinion

[Juri Linkov]

> +(defvar treesit--mode-associations
> +  '((javascript-mode . js-ts-mode )
> +    (c-or-c++-mode . c-or-c++-ts-mode)
> +    (c-mode . c-ts-mode)
> +    (c++-mode . c++-ts-mode)
> +    ("\\.elixir\\'" . elixir-ts-mode)
> +    ("\\.ex\\'" . elixir-ts-mode)
> +    ("\\.go\\'" . go-ts-mode)
> +    ;; And so on.
> +    ;; Some info needed for interpreter-mode-alist as well.
> +    ))
> +
> +(defcustom treesit-enable-modes nil
> +  "Non-nil to enable tree-sitter modes during Emacs's startup."
> +  :type 'boolean
> +  :version "31.1"
> +  :set #'treesit-enable-modes--set)

This could support a list to enable ts-modes selectively,
e.g. (setq treesit-enable-modes '(elixir-ts-mode js-ts-mode))
to not enable 'c-ts-mode', etc.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 19 Nov 2024 19:56:05 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > Wasn't the idea that the user will tell us which files she wants to
> > visit in each mode?
> 
> I think we talked about making the option more granular (allowing to set 
> it not just to t, but to a list of modes). That will be easy to add.
> 
> But specifying the files as well is news to me. Wouldn't users who want 
> that level of detail just go and customize auto-mode-alist instead?

Maybe so, but that is not always easy nor user-friendly: getting the
regexps right is not trivial, many people make mistakes.  And I
thought this discussion at some point mentioned that Emacs should
suggest a mode for the file being visited? in which case specifying
the file is trivial.

I'm also not opposed to having the data ready somewhere in advance.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 19/11/2024 19:59, Juri Linkov wrote:
>> +(defcustom treesit-enable-modes nil
>> +  "Non-nil to enable tree-sitter modes during Emacs's startup."
>> +  :type 'boolean
>> +  :version "31.1"
>> +  :set #'treesit-enable-modes--set)
> This could support a list to enable ts-modes selectively,
> e.g. (setq treesit-enable-modes '(elixir-ts-mode js-ts-mode))
> to not enable 'c-ts-mode', etc.

Right, that's easy enough - a few extra lines of Lisp.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 19/11/2024 21:01, Eli Zaretskii wrote:
>> Date: Tue, 19 Nov 2024 19:56:05 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> Wasn't the idea that the user will tell us which files she wants to
>>> visit in each mode?
>>
>> I think we talked about making the option more granular (allowing to set
>> it not just to t, but to a list of modes). That will be easy to add.
>>
>> But specifying the files as well is news to me. Wouldn't users who want
>> that level of detail just go and customize auto-mode-alist instead?
> 
> Maybe so, but that is not always easy nor user-friendly: getting the
> regexps right is not trivial, many people make mistakes.

Even if that's true, I'm not sure what workflow you have in mind. My 
goal here is to fix the problem of ts modes installing themselves into 
auto-mode-alist (and major-mode-remap-defaults) haphazardly, with 
associated problems like https://debbugs.gnu.org/74339#38, for example.

If editing regexp directly is a difficulty, we could either add some 
helpers in the Customize interface, or a command which would prompt for 
mode, for file extension(s), and then customize auto-mode-alist based on 
that. But that's not specific to tree-sitter modes, and not a 
replacement for the current setup.

> And I
> thought this discussion at some point mentioned that Emacs should
> suggest a mode for the file being visited? in which case specifying
> the file is trivial.

Philip K. has proposed a package package-autosuggest - which is 
something that approaches similar needs from an opposite direction 
(providing automatic suggestions when the user visit a file which is 
currently not supported but could be after installing a package or doing 
some extra customization). A totally valid approach - and well-tested by 
the likes of VS Code.

I haven't tested that branch myself yet, and it seems to come with a 
bunch of UI decisions, so it's a bigger endeavor.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Tue, 19 Nov 2024 22:12:09 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 19/11/2024 21:01, Eli Zaretskii wrote:
> >> Date: Tue, 19 Nov 2024 19:56:05 +0200
> >> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >>> Wasn't the idea that the user will tell us which files she wants to
> >>> visit in each mode?
> >>
> >> I think we talked about making the option more granular (allowing to set
> >> it not just to t, but to a list of modes). That will be easy to add.
> >>
> >> But specifying the files as well is news to me. Wouldn't users who want
> >> that level of detail just go and customize auto-mode-alist instead?
> > 
> > Maybe so, but that is not always easy nor user-friendly: getting the
> > regexps right is not trivial, many people make mistakes.
> 
> Even if that's true, I'm not sure what workflow you have in mind.

Someone mentioned the possibility that Emacs could propose using some
mode when user visits a file, AFAIR.  So the workflow would be to ask
the user whether she wants to turn on mode FOO in files like this one,
and if the answer is YES, modify auto-mode-alist accordingly.

> My 
> goal here is to fix the problem of ts modes installing themselves into 
> auto-mode-alist (and major-mode-remap-defaults) haphazardly, with 
> associated problems like https://debbugs.gnu.org/74339#38, for example.

We all want to find a better solution, the challenge is to find one.

> If editing regexp directly is a difficulty, we could either add some 
> helpers in the Customize interface, or a command which would prompt for 
> mode, for file extension(s), and then customize auto-mode-alist based on 
> that.

The latter is the idea I had in mind.

> But that's not specific to tree-sitter modes

No, but that shouldn't prevent us from implementing something specific
to tree-sitter modes for starters.

> and not a replacement for the current setup.

What current setup?

> > And I
> > thought this discussion at some point mentioned that Emacs should
> > suggest a mode for the file being visited? in which case specifying
> > the file is trivial.
> 
> Philip K. has proposed a package package-autosuggest - which is 
> something that approaches similar needs from an opposite direction 
> (providing automatic suggestions when the user visit a file which is 
> currently not supported but could be after installing a package or doing 
> some extra customization). A totally valid approach - and well-tested by 
> the likes of VS Code.
> 
> I haven't tested that branch myself yet, and it seems to come with a 
> bunch of UI decisions, so it's a bigger endeavor.

We could start from something specific to tree-sitter modes, and merge
these two features later.

Re: An anonymous IRC user's opinion

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>> +(defvar treesit--mode-associations
>> +  '((javascript-mode . js-ts-mode )
>> +    (c-or-c++-mode . c-or-c++-ts-mode)
>> +    (c-mode . c-ts-mode)
>> +    (c++-mode . c++-ts-mode)
>> +    ("\\.elixir\\'" . elixir-ts-mode)
>> +    ("\\.ex\\'" . elixir-ts-mode)
>> +    ("\\.go\\'" . go-ts-mode)
>> +    ;; And so on.
>> +    ;; Some info needed for interpreter-mode-alist as well.
>> +    ))
>> +
>> +(defcustom treesit-enable-modes nil
>> +  "Non-nil to enable tree-sitter modes during Emacs's startup."
>> +  :type 'boolean
>> +  :version "31.1"
>> +  :set #'treesit-enable-modes--set)
>
> This could support a list to enable ts-modes selectively,
> e.g. (setq treesit-enable-modes '(elixir-ts-mode js-ts-mode))
> to not enable 'c-ts-mode', etc.

I might have missed something, but how would that then differ from
configuring `major-mode-remap-alist' appropriately?

-- 
	Philip Kaludercic on siskin

Re: An anonymous IRC user's opinion

[Juri Linkov]

>>> +(defvar treesit--mode-associations
>>> +  '((javascript-mode . js-ts-mode )
>>> +    (c-or-c++-mode . c-or-c++-ts-mode)
>>> +    (c-mode . c-ts-mode)
>>> +    (c++-mode . c++-ts-mode)
>>> +    ("\\.elixir\\'" . elixir-ts-mode)
>>> +    ("\\.ex\\'" . elixir-ts-mode)
>>> +    ("\\.go\\'" . go-ts-mode)
>>> +    ;; And so on.
>>> +    ;; Some info needed for interpreter-mode-alist as well.
>>> +    ))
>>> +
>>> +(defcustom treesit-enable-modes nil
>>> +  "Non-nil to enable tree-sitter modes during Emacs's startup."
>>> +  :type 'boolean
>>> +  :version "31.1"
>>> +  :set #'treesit-enable-modes--set)
>>
>> This could support a list to enable ts-modes selectively,
>> e.g. (setq treesit-enable-modes '(elixir-ts-mode js-ts-mode))
>> to not enable 'c-ts-mode', etc.
>
> I might have missed something, but how would that then differ from
> configuring `major-mode-remap-alist' appropriately?

Maybe because it would be a little easier to customize?

But you are right, `major-mode-remap-alist' is already
easy to use.  And customizing it has much more predictable
result than enabling ts-modes by loading .el files.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 20/11/2024 18:47, Philip Kaludercic wrote:
>>> +(defcustom treesit-enable-modes nil
>>> +  "Non-nil to enable tree-sitter modes during Emacs's startup."
>>> +  :type 'boolean
>>> +  :version "31.1"
>>> +  :set #'treesit-enable-modes--set)
>> This could support a list to enable ts-modes selectively,
>> e.g. (setq treesit-enable-modes '(elixir-ts-mode js-ts-mode))
>> to not enable 'c-ts-mode', etc.
> I might have missed something, but how would that then differ from
> configuring `major-mode-remap-alist' appropriately?

Perhaps the potential to customize it like this would make it worth it:

   (setopt treesit-enable-nodes '(not c-ts-mode))

Similar to the syntax in font-lock-global-modes.

I'm certainly happy to keep the feature set minimum, though.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 20/11/2024 14:59, Eli Zaretskii wrote:
>>> Maybe so, but that is not always easy nor user-friendly: getting the
>>> regexps right is not trivial, many people make mistakes.
>>
>> Even if that's true, I'm not sure what workflow you have in mind.
> 
> Someone mentioned the possibility that Emacs could propose using some
> mode when user visits a file, AFAIR.  So the workflow would be to ask
> the user whether she wants to turn on mode FOO in files like this one,
> and if the answer is YES, modify auto-mode-alist accordingly.

And the init script. Or .custom.el. Keeping in mind that that value 
might be modified somewhere else during startup, I guess.

Philip's branch is the closest to that idea. Would you be comfortable to 
replace the current setup with it?

The result can be that all ts modes are disabled by default, but when 
visiting a file extension that is currently associated with 
fundamental-mode, but we have a alternative mode available, we'd offer 
to the user to "install" that. For built-in modes, it would mean a 
corresponding major-mode-remap-alist or auto-mode-alist customization.

I'm fine with that idea, but it'd seem like a change in paradigm.

>> My
>> goal here is to fix the problem of ts modes installing themselves into
>> auto-mode-alist (and major-mode-remap-defaults) haphazardly, with
>> associated problems like https://debbugs.gnu.org/74339#38, for example.
> 
> We all want to find a better solution, the challenge is to find one.

If a solution is presented that solves the scenarios that the current 
one does, while avoiding some existing problems, it should be considered 
a win. Even if it doesn't include some additional nice-to-haves.

>> and not a replacement for the current setup.
> 
> What current setup?

Please look at the patch in 
https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html, 
the current setup is on the lines being removed, and the proposed one is 
on the lines being added.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Wed, 20 Nov 2024 20:38:05 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 20/11/2024 14:59, Eli Zaretskii wrote:
> >>> Maybe so, but that is not always easy nor user-friendly: getting the
> >>> regexps right is not trivial, many people make mistakes.
> >>
> >> Even if that's true, I'm not sure what workflow you have in mind.
> > 
> > Someone mentioned the possibility that Emacs could propose using some
> > mode when user visits a file, AFAIR.  So the workflow would be to ask
> > the user whether she wants to turn on mode FOO in files like this one,
> > and if the answer is YES, modify auto-mode-alist accordingly.
> 
> And the init script. Or .custom.el. Keeping in mind that that value 
> might be modified somewhere else during startup, I guess.

That's basic customization for you, yes.

> Philip's branch is the closest to that idea. Would you be comfortable to 
> replace the current setup with it?
> 
> The result can be that all ts modes are disabled by default, but when 
> visiting a file extension that is currently associated with 
> fundamental-mode, but we have a alternative mode available, we'd offer 
> to the user to "install" that. For built-in modes, it would mean a 
> corresponding major-mode-remap-alist or auto-mode-alist customization.

This is okay as an opt-in feature, but it cannot be the only way for
users to tell Emacs they prefer one or more TS-based modes.  For
starters, some people might be annoyed by these suggestions, and might
prefer more proactive ways of enabling those modes.

> I'm fine with that idea, but it'd seem like a change in paradigm.

Yes, indeed.  So I think it has to be an optional feature, and we
should offer more "direct" ways for expressing such preferences.

> >> My
> >> goal here is to fix the problem of ts modes installing themselves into
> >> auto-mode-alist (and major-mode-remap-defaults) haphazardly, with
> >> associated problems like https://debbugs.gnu.org/74339#38, for example.
> > 
> > We all want to find a better solution, the challenge is to find one.
> 
> If a solution is presented that solves the scenarios that the current 
> one does, while avoiding some existing problems, it should be considered 
> a win. Even if it doesn't include some additional nice-to-haves.

I'm more worried by the UI and the UX of such solutions.  Other than
that, I agree that avoiding at least some of the current problems is
progress.

> >> and not a replacement for the current setup.
> > 
> > What current setup?
> 
> Please look at the patch in 
> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html, 
> the current setup is on the lines being removed, and the proposed one is 
> on the lines being added.

Then I don't understand why you say modifying auto-mode-alist is not a
replacement.  That's what we did in Emacs 29, just less cleanly.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 20/11/2024 21:01, Eli Zaretskii wrote:

>> Philip's branch is the closest to that idea. Would you be comfortable to
>> replace the current setup with it?
>>
>> The result can be that all ts modes are disabled by default, but when
>> visiting a file extension that is currently associated with
>> fundamental-mode, but we have a alternative mode available, we'd offer
>> to the user to "install" that. For built-in modes, it would mean a
>> corresponding major-mode-remap-alist or auto-mode-alist customization.
> 
> This is okay as an opt-in feature, but it cannot be the only way for
> users to tell Emacs they prefer one or more TS-based modes.  For
> starters, some people might be annoyed by these suggestions, and might
> prefer more proactive ways of enabling those modes.

In that case, I suggest we leave that feature request for later, and 
discuss my proposal first.

>> I'm fine with that idea, but it'd seem like a change in paradigm.
> 
> Yes, indeed.  So I think it has to be an optional feature, and we
> should offer more "direct" ways for expressing such preferences.

Such as a user option called treesit-enable-modes?

>>>> and not a replacement for the current setup.
>>>
>>> What current setup?
>>
>> Please look at the patch in
>> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html,
>> the current setup is on the lines being removed, and the proposed one is
>> on the lines being added.
> 
> Then I don't understand why you say modifying auto-mode-alist is not a
> replacement.  That's what we did in Emacs 29, just less cleanly.

I said that "helpers in the Customize interface, or a command which 
would prompt for mode, for file extension(s), and then customize 
auto-mode-alist based on that" would not be ... "a replacement for the 
current setup", which you seem to confirm in the latest messages.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Wed, 20 Nov 2024 21:23:56 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> I'm fine with that idea, but it'd seem like a change in paradigm.
> > 
> > Yes, indeed.  So I think it has to be an optional feature, and we
> > should offer more "direct" ways for expressing such preferences.
> 
> Such as a user option called treesit-enable-modes?

Something like that, yes.  Because no better idea was presented.

> >>>> and not a replacement for the current setup.
> >>>
> >>> What current setup?
> >>
> >> Please look at the patch in
> >> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html,
> >> the current setup is on the lines being removed, and the proposed one is
> >> on the lines being added.
> > 
> > Then I don't understand why you say modifying auto-mode-alist is not a
> > replacement.  That's what we did in Emacs 29, just less cleanly.
> 
> I said that "helpers in the Customize interface, or a command which 
> would prompt for mode, for file extension(s), and then customize 
> auto-mode-alist based on that" would not be ... "a replacement for the 
> current setup", which you seem to confirm in the latest messages.

I do?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 20/11/2024 21:55, Eli Zaretskii wrote:
>> Date: Wed, 20 Nov 2024 21:23:56 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>> I'm fine with that idea, but it'd seem like a change in paradigm.
>>>
>>> Yes, indeed.  So I think it has to be an optional feature, and we
>>> should offer more "direct" ways for expressing such preferences.
>>
>> Such as a user option called treesit-enable-modes?
> 
> Something like that, yes.  Because no better idea was presented.

Take a look at the patch, then?

>>>>>> and not a replacement for the current setup.
>>>>>
>>>>> What current setup?
>>>>
>>>> Please look at the patch in
>>>> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html,
>>>> the current setup is on the lines being removed, and the proposed one is
>>>> on the lines being added.
>>>
>>> Then I don't understand why you say modifying auto-mode-alist is not a
>>> replacement.  That's what we did in Emacs 29, just less cleanly.
>>
>> I said that "helpers in the Customize interface, or a command which
>> would prompt for mode, for file extension(s), and then customize
>> auto-mode-alist based on that" would not be ... "a replacement for the
>> current setup", which you seem to confirm in the latest messages.
> 
> I do?

As far as I was able to understand, yes.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Wed, 20 Nov 2024 21:57:14 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 20/11/2024 21:55, Eli Zaretskii wrote:
> >> Date: Wed, 20 Nov 2024 21:23:56 +0200
> >> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >>>> I'm fine with that idea, but it'd seem like a change in paradigm.
> >>>
> >>> Yes, indeed.  So I think it has to be an optional feature, and we
> >>> should offer more "direct" ways for expressing such preferences.
> >>
> >> Such as a user option called treesit-enable-modes?
> > 
> > Something like that, yes.  Because no better idea was presented.
> 
> Take a look at the patch, then?

I did.  What's the next step?

> 
> >>>>>> and not a replacement for the current setup.
> >>>>>
> >>>>> What current setup?
> >>>>
> >>>> Please look at the patch in
> >>>> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html,
> >>>> the current setup is on the lines being removed, and the proposed one is
> >>>> on the lines being added.
> >>>
> >>> Then I don't understand why you say modifying auto-mode-alist is not a
> >>> replacement.  That's what we did in Emacs 29, just less cleanly.
> >>
> >> I said that "helpers in the Customize interface, or a command which
> >> would prompt for mode, for file extension(s), and then customize
> >> auto-mode-alist based on that" would not be ... "a replacement for the
> >> current setup", which you seem to confirm in the latest messages.
> > 
> > I do?
> 
> As far as I was able to understand, yes.

Then you should understand that I think it _is_ a replacement for the
current setup, which AFAIK we all consider as sub-optimal.

IOW, we do want to avoid the situation where loading a mode changes
auto-mode-alist or major-mode-remap-defaults or any other global data,
right?  If so, why wouldn't those alternatives be the replacement for
that?

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 21/11/2024 07:46, Eli Zaretskii wrote:

>>>>>> I'm fine with that idea, but it'd seem like a change in paradigm.
>>>>>
>>>>> Yes, indeed.  So I think it has to be an optional feature, and we
>>>>> should offer more "direct" ways for expressing such preferences.
>>>>
>>>> Such as a user option called treesit-enable-modes?
>>>
>>> Something like that, yes.  Because no better idea was presented.
>>
>> Take a look at the patch, then?
> 
> I did.  What's the next step?

It would be nice to understand the minimum requirements to replace the 
current approach.

>>>>>>>> and not a replacement for the current setup.
>>>>>>>
>>>>>>> What current setup?
>>>>>>
>>>>>> Please look at the patch in
>>>>>> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html,
>>>>>> the current setup is on the lines being removed, and the proposed one is
>>>>>> on the lines being added.
>>>>>
>>>>> Then I don't understand why you say modifying auto-mode-alist is not a
>>>>> replacement.  That's what we did in Emacs 29, just less cleanly.
>>>>
>>>> I said that "helpers in the Customize interface, or a command which
>>>> would prompt for mode, for file extension(s), and then customize
>>>> auto-mode-alist based on that" would not be ... "a replacement for the
>>>> current setup", which you seem to confirm in the latest messages.
>>>
>>> I do?
>>
>> As far as I was able to understand, yes.
> 
> Then you should understand that I think it _is_ a replacement for the
> current setup, which AFAIK we all consider as sub-optimal.

Here's a quote one of your previous emails:

 > This is okay as an opt-in feature, but it cannot be the only way for
 > users to tell Emacs they prefer one or more TS-based modes.  For
 > starters, some people might be annoyed by these suggestions, and might
 > prefer more proactive ways of enabling those modes.

I have proposed an implementation of a "more proactive way". If it seems 
insufficient to you, perhaps you could describe missing scenarios that 
are supported with the the current approach. They might be easy enough 
to add (or explain how they are supported already through other means).

> IOW, we do want to avoid the situation where loading a mode changes
> auto-mode-alist or major-mode-remap-defaults or any other global data,
> right?

Sure.

> If so, why wouldn't those alternatives be the replacement for
> that?

Sorry, I don't understand your proposed alternative.

If you want to see just a different set of capabilities instead, could 
you enumerate them?

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Thu, 21 Nov 2024 21:47:29 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/11/2024 07:46, Eli Zaretskii wrote:
> 
> >>>>>> I'm fine with that idea, but it'd seem like a change in paradigm.
> >>>>>
> >>>>> Yes, indeed.  So I think it has to be an optional feature, and we
> >>>>> should offer more "direct" ways for expressing such preferences.
> >>>>
> >>>> Such as a user option called treesit-enable-modes?
> >>>
> >>> Something like that, yes.  Because no better idea was presented.
> >>
> >> Take a look at the patch, then?
> > 
> > I did.  What's the next step?
> 
> It would be nice to understand the minimum requirements to replace the 
> current approach.

If you think that I have all of them figured out, you are wrong.
Coming up with such requirements is not easy, and should probably be a
team job.  I will try, when I have time, to post a list of what I
think should be part of those requirements, but feel free to beat me
to it.

> > Then you should understand that I think it _is_ a replacement for the
> > current setup, which AFAIK we all consider as sub-optimal.
> 
> Here's a quote one of your previous emails:
> 
>  > This is okay as an opt-in feature, but it cannot be the only way for
>  > users to tell Emacs they prefer one or more TS-based modes.  For
>  > starters, some people might be annoyed by these suggestions, and might
>  > prefer more proactive ways of enabling those modes.
> 
> I have proposed an implementation of a "more proactive way". If it seems 
> insufficient to you, perhaps you could describe missing scenarios that 
> are supported with the the current approach. They might be easy enough 
> to add (or explain how they are supported already through other means).

I already did: IMO we should have user commands to tell Emacs that the
user wants to use these modes, not only suggestions by Emacs to use
them, triggered by visiting files.

> > IOW, we do want to avoid the situation where loading a mode changes
> > auto-mode-alist or major-mode-remap-defaults or any other global data,
> > right?
> 
> Sure.
> 
> > If so, why wouldn't those alternatives be the replacement for
> > that?
> 
> Sorry, I don't understand your proposed alternative.
> 
> If you want to see just a different set of capabilities instead, could 
> you enumerate them?

See above.  And if there are others, I'd be glad to hear and consider
them.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 21/11/2024 22:03, Eli Zaretskii wrote:

>> It would be nice to understand the minimum requirements to replace the
>> current approach.
> 
> If you think that I have all of them figured out, you are wrong.
> Coming up with such requirements is not easy, and should probably be a
> team job.  I will try, when I have time, to post a list of what I
> think should be part of those requirements, but feel free to beat me
> to it.

Well, the thing is that I figured the patch already covers roughly the 
same area as the current capabilities (while removing certain downsides).

>>> Then you should understand that I think it _is_ a replacement for the
>>> current setup, which AFAIK we all consider as sub-optimal.
>>
>> Here's a quote one of your previous emails:
>>
>>   > This is okay as an opt-in feature, but it cannot be the only way for
>>   > users to tell Emacs they prefer one or more TS-based modes.  For
>>   > starters, some people might be annoyed by these suggestions, and might
>>   > prefer more proactive ways of enabling those modes.
>>
>> I have proposed an implementation of a "more proactive way". If it seems
>> insufficient to you, perhaps you could describe missing scenarios that
>> are supported with the the current approach. They might be easy enough
>> to add (or explain how they are supported already through other means).
> 
> I already did: IMO we should have user commands to tell Emacs that the
> user wants to use these modes, not only suggestions by Emacs to use
> them, triggered by visiting files.

"Suggestions by Emacs to use them" is a different feature (implemented 
by Philip K. in his branch), it's not what my patch does.

>>> IOW, we do want to avoid the situation where loading a mode changes
>>> auto-mode-alist or major-mode-remap-defaults or any other global data,
>>> right?
>>
>> Sure.
>>
>>> If so, why wouldn't those alternatives be the replacement for
>>> that?
>>
>> Sorry, I don't understand your proposed alternative.
>>
>> If you want to see just a different set of capabilities instead, could
>> you enumerate them?
> 
> See above.  And if there are others, I'd be glad to hear and consider
> them.

Thanks.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Thu, 21 Nov 2024 22:11:48 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/11/2024 22:03, Eli Zaretskii wrote:
> 
> >> It would be nice to understand the minimum requirements to replace the
> >> current approach.
> > 
> > If you think that I have all of them figured out, you are wrong.
> > Coming up with such requirements is not easy, and should probably be a
> > team job.  I will try, when I have time, to post a list of what I
> > think should be part of those requirements, but feel free to beat me
> > to it.
> 
> Well, the thing is that I figured the patch already covers roughly the 
> same area as the current capabilities (while removing certain downsides).

I don't understand what you want to say here and how it is relevant to
your request to see the minimum requirements.

> >>> Then you should understand that I think it _is_ a replacement for the
> >>> current setup, which AFAIK we all consider as sub-optimal.
> >>
> >> Here's a quote one of your previous emails:
> >>
> >>   > This is okay as an opt-in feature, but it cannot be the only way for
> >>   > users to tell Emacs they prefer one or more TS-based modes.  For
> >>   > starters, some people might be annoyed by these suggestions, and might
> >>   > prefer more proactive ways of enabling those modes.
> >>
> >> I have proposed an implementation of a "more proactive way". If it seems
> >> insufficient to you, perhaps you could describe missing scenarios that
> >> are supported with the the current approach. They might be easy enough
> >> to add (or explain how they are supported already through other means).
> > 
> > I already did: IMO we should have user commands to tell Emacs that the
> > user wants to use these modes, not only suggestions by Emacs to use
> > them, triggered by visiting files.
> 
> "Suggestions by Emacs to use them" is a different feature (implemented 
> by Philip K. in his branch), it's not what my patch does.

I didn't say it did!  The "quote from my previous email" was about the
suggestions by Emacs proposal, and I wrote that because you asked
whether the branch could be the solution for letting users express
their will to use TS modes.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 21/11/2024 22:24, Eli Zaretskii wrote:
>> Date: Thu, 21 Nov 2024 22:11:48 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 21/11/2024 22:03, Eli Zaretskii wrote:
>>
>>>> It would be nice to understand the minimum requirements to replace the
>>>> current approach.
>>>
>>> If you think that I have all of them figured out, you are wrong.
>>> Coming up with such requirements is not easy, and should probably be a
>>> team job.  I will try, when I have time, to post a list of what I
>>> think should be part of those requirements, but feel free to beat me
>>> to it.
>>
>> Well, the thing is that I figured the patch already covers roughly the
>> same area as the current capabilities (while removing certain downsides).
> 
> I don't understand what you want to say here and how it is relevant to
> your request to see the minimum requirements.

If my patch covers all that we already support (or will cover after 
minor updates), and removes certain problems, then we could agree to 
install it, couldn't we?

>>>>> Then you should understand that I think it _is_ a replacement for the
>>>>> current setup, which AFAIK we all consider as sub-optimal.
>>>>
>>>> Here's a quote one of your previous emails:
>>>>
>>>>    > This is okay as an opt-in feature, but it cannot be the only way for
>>>>    > users to tell Emacs they prefer one or more TS-based modes.  For
>>>>    > starters, some people might be annoyed by these suggestions, and might
>>>>    > prefer more proactive ways of enabling those modes.
>>>>
>>>> I have proposed an implementation of a "more proactive way". If it seems
>>>> insufficient to you, perhaps you could describe missing scenarios that
>>>> are supported with the the current approach. They might be easy enough
>>>> to add (or explain how they are supported already through other means).
>>>
>>> I already did: IMO we should have user commands to tell Emacs that the
>>> user wants to use these modes, not only suggestions by Emacs to use
>>> them, triggered by visiting files.
>>
>> "Suggestions by Emacs to use them" is a different feature (implemented
>> by Philip K. in his branch), it's not what my patch does.
> 
> I didn't say it did!  The "quote from my previous email" was about the
> suggestions by Emacs proposal, and I wrote that because you asked
> whether the branch could be the solution for letting users express
> their will to use TS modes.

If we settle on the decision that it doesn't, then it might be sensible 
to decide on the replacement for the "core" functionality first, and 
then review Philip's branch as an optional feature.

That's what my patch aims to do, to be the replacement for the 
capabilities we currently have, but in a more "ecological" way. And add 
a user option, like I think you requested.

Re: An anonymous IRC user's opinion

[Eli Zaretskii]

> Date: Thu, 21 Nov 2024 22:56:41 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 21/11/2024 22:24, Eli Zaretskii wrote:
> >> Date: Thu, 21 Nov 2024 22:11:48 +0200
> >> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >> On 21/11/2024 22:03, Eli Zaretskii wrote:
> >>
> >>>> It would be nice to understand the minimum requirements to replace the
> >>>> current approach.
> >>>
> >>> If you think that I have all of them figured out, you are wrong.
> >>> Coming up with such requirements is not easy, and should probably be a
> >>> team job.  I will try, when I have time, to post a list of what I
> >>> think should be part of those requirements, but feel free to beat me
> >>> to it.
> >>
> >> Well, the thing is that I figured the patch already covers roughly the
> >> same area as the current capabilities (while removing certain downsides).
> > 
> > I don't understand what you want to say here and how it is relevant to
> > your request to see the minimum requirements.
> 
> If my patch covers all that we already support (or will cover after 
> minor updates), and removes certain problems, then we could agree to 
> install it, couldn't we?

Is this what you think is the answer to what I asked N emails ago,
viz.:

>>>>>> I'm fine with that idea, but it'd seem like a change in paradigm.
>>>>>
>>>>> Yes, indeed.  So I think it has to be an optional feature, and we
>>>>> should offer more "direct" ways for expressing such preferences.
>>>>
>>>> Such as a user option called treesit-enable-modes?
>>>
>>> Something like that, yes.  Because no better idea was presented.
>>
>> Take a look at the patch, then?
> 
> I did.  What's the next step?

To which your response was:

> It would be nice to understand the minimum requirements to replace the 
> current approach.

But now you seem to say that the next step is to consider installing
your patch?  Or did I again misunderstand?

> >>>> I have proposed an implementation of a "more proactive way". If it seems
> >>>> insufficient to you, perhaps you could describe missing scenarios that
> >>>> are supported with the the current approach. They might be easy enough
> >>>> to add (or explain how they are supported already through other means).
> >>>
> >>> I already did: IMO we should have user commands to tell Emacs that the
> >>> user wants to use these modes, not only suggestions by Emacs to use
> >>> them, triggered by visiting files.
> >>
> >> "Suggestions by Emacs to use them" is a different feature (implemented
> >> by Philip K. in his branch), it's not what my patch does.
> > 
> > I didn't say it did!  The "quote from my previous email" was about the
> > suggestions by Emacs proposal, and I wrote that because you asked
> > whether the branch could be the solution for letting users express
> > their will to use TS modes.
> 
> If we settle on the decision that it doesn't, then it might be sensible 
> to decide on the replacement for the "core" functionality first, and 
> then review Philip's branch as an optional feature.

I guess it is still unclear, so let me say once again: Philip's branch
is a nice feature, relevant also to this issue, but it can only be an
opt-in feature.  Therefore, we need another solution to be the
main/default one, which replaces the current messing with
auto-mode-alist and major-mode-remap-defaults.  That other solution
could be based on the patch you posted.

I hope my views on this are now clear enough.

> That's what my patch aims to do, to be the replacement for the 
> capabilities we currently have, but in a more "ecological" way. And add 
> a user option, like I think you requested.

Agreed.  So I'm asking again: what is the next step?  Should we start
a new discussion about replacing (on master) the current
implementation with a command based on your patch?  One thing that I
think is missing in your patch is a way to go back to use the non-TS
modes (where they are available).  But maybe people don't think we
should have that?  Another thing that seems to be missing is a command
to enable just one TS-based mode, not all of them.

Re: An anonymous IRC user's opinion

[Dmitry Gutov]

On 22/11/2024 08:44, Eli Zaretskii wrote:

>> If my patch covers all that we already support (or will cover after
>> minor updates), and removes certain problems, then we could agree to
>> install it, couldn't we?
> 
> Is this what you think is the answer to what I asked N emails ago,
> viz.:

Thanks, now I see where the miscommunication started.

>>>>>>> I'm fine with that idea, but it'd seem like a change in paradigm.
>>>>>>
>>>>>> Yes, indeed.  So I think it has to be an optional feature, and we
>>>>>> should offer more "direct" ways for expressing such preferences.
>>>>>
>>>>> Such as a user option called treesit-enable-modes?
>>>>
>>>> Something like that, yes.  Because no better idea was presented.
>>>
>>> Take a look at the patch, then?
>>
>> I did.  What's the next step?
> 
> To which your response was:
> 
>> It would be nice to understand the minimum requirements to replace the
>> current approach.
> 
> But now you seem to say that the next step is to consider installing
> your patch?  Or did I again misunderstand?

By "change in paradigm" I meant the "autosuggest" branch. Either of the 
approaches would be a change, but my proposal seems closer to the 
current capabilities and the way of setting up things.

Note that I personally would be fine with either change, or both together.

> I guess it is still unclear, so let me say once again: Philip's branch
> is a nice feature, relevant also to this issue, but it can only be an
> opt-in feature.  Therefore, we need another solution to be the
> main/default one, which replaces the current messing with
> auto-mode-alist and major-mode-remap-defaults.  That other solution
> could be based on the patch you posted.
> 
> I hope my views on this are now clear enough.

Yes, thank you.

>> That's what my patch aims to do, to be the replacement for the
>> capabilities we currently have, but in a more "ecological" way. And add
>> a user option, like I think you requested.
> 
> Agreed.  So I'm asking again: what is the next step?  Should we start
> a new discussion about replacing (on master) the current
> implementation with a command based on your patch?

Sure.

Not a command, though - a user option. The command is 'M-x 
customize-variable', at least in the current version. Though I suppose 
that's also up for discussion.

> One thing that I
> think is missing in your patch is a way to go back to use the non-TS
> modes (where they are available).

I think it does that already - but only for new buffers. That could be 
implemented without too much trouble, now or in a later revision.

> But maybe people don't think we
> should have that?

Not sure which would be more natural. But if we implement switching for 
existing buffers when when treesit-enable-modes is customized to t, I 
suppose the reverse could also be expected.

> Another thing that seems to be missing is a command
> to enable just one TS-based mode, not all of them.

How about if that's done like:

   (setopt treesit-enable-modes '(c-ts-mode))

Or maybe 'M-x treesit-add-enabled-mode' can be added too.

Re: Turning on/off tree-sitter modes (was: An anonymous IRC user's opinion)

[Eli Zaretskii]

[I've started a new thread about this.]

> Date: Fri, 22 Nov 2024 17:08:52 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> That's what my patch aims to do, to be the replacement for the
> >> capabilities we currently have, but in a more "ecological" way. And add
> >> a user option, like I think you requested.
> > 
> > Agreed.  So I'm asking again: what is the next step?  Should we start
> > a new discussion about replacing (on master) the current
> > implementation with a command based on your patch?
> 
> Sure.
> 
> Not a command, though - a user option. The command is 'M-x 
> customize-variable', at least in the current version. Though I suppose 
> that's also up for discussion.
> 
> > One thing that I
> > think is missing in your patch is a way to go back to use the non-TS
> > modes (where they are available).
> 
> I think it does that already - but only for new buffers. That could be 
> implemented without too much trouble, now or in a later revision.
> 
> > But maybe people don't think we
> > should have that?
> 
> Not sure which would be more natural. But if we implement switching for 
> existing buffers when when treesit-enable-modes is customized to t, I 
> suppose the reverse could also be expected.
> 
> > Another thing that seems to be missing is a command
> > to enable just one TS-based mode, not all of them.
> 
> How about if that's done like:
> 
>    (setopt treesit-enable-modes '(c-ts-mode))
> 
> Or maybe 'M-x treesit-add-enabled-mode' can be added too.

I think a command is better.

Here are the issues that are currently not handled by your patch,
which perhaps require modifications and additions (but should probably
be discussed first):

  . we need the ability to turn on and off selected TS-based modes,
    and do it easily
  . we should include in this feature handling of all the TS-based
    modes in core (right now, I don't see python-ts-mode,
    ruby-ts-mode, and csharp-ts-mode, at least)
  . we should decide how to handle TS-based modes whose non-TS
    counterparts are available as 3rd-party packages
  . we should decide whether we want to modify auto-mode-alist or use
    major-mode remapping for all the TS-based modes

Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 23/11/2024 15:24, Eli Zaretskii wrote:
> [I've started a new thread about this.]

Nice.

>>> Another thing that seems to be missing is a command
>>> to enable just one TS-based mode, not all of them.
>>
>> How about if that's done like:
>>
>>     (setopt treesit-enable-modes '(c-ts-mode))
>>
>> Or maybe 'M-x treesit-add-enabled-mode' can be added too.
> 
> I think a command is better.

Okay. It can read the mode name with completion, and then call

   (setopt treesit-enable-modes (cons new-mode treesit-enable-modes))

> Here are the issues that are currently not handled by your patch,
> which perhaps require modifications and additions (but should probably
> be discussed first):
> 
>    . we need the ability to turn on and off selected TS-based modes,
>      and do it easily

Note that we don't have such capability currently.

I guess we could add 'treesit-remove-enabled-mode', implemented almost 
exactly like the above.

Both commands would be pure wrappers on top of the user option, so they 
don't seem to require any advance considerations. Somebody can add those 
later, or any variations on them.

>    . we should include in this feature handling of all the TS-based
>      modes in core (right now, I don't see python-ts-mode,
>      ruby-ts-mode, and csharp-ts-mode, at least)

Sure. The patch was basically abbreviated for easier reading.

>    . we should decide how to handle TS-based modes whose non-TS
>      counterparts are available as 3rd-party packages

I think we shouldn't do anything about those - they will continue to use 
the current policy for 3rd party major modes: installing a package adds 
an 'add-to-list' form to autoloads, which runs during 
package-initialize. To disable such a form, the user uninstalls a package.

>    . we should decide whether we want to modify auto-mode-alist or use
>      major-mode remapping for all the TS-based modes

I see no reason to depart from the current approach - except I've 
switched from major-mode-remap-defaults to major-mode-remap-alist (where 
the former is used) because the latter corresponds to user preferences, 
and it seems like that's the subject of our switcher.

This could also be discussed, but seems more of an orthogonal issue.

Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> Date: Sat, 23 Nov 2024 18:26:21 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >    . we need the ability to turn on and off selected TS-based modes,
> >      and do it easily
> 
> Note that we don't have such capability currently.

We have, sort-of: loading the mode "turns it on" (with known caveats
and disadvantages).  In any case, I think we should have this, even if
we don't have it now.  It should be part of this improvement.

> Both commands would be pure wrappers on top of the user option, so they 
> don't seem to require any advance considerations. Somebody can add those 
> later, or any variations on them.

We could indeed make them wrappers, but changing the user option is
not really clean.  If nothing else, users will see that the option was
"modified outside Custom", which could be confusing.  But if we
conclude that this is the best way, we could avoid this unpleasant
effect as well (AFAIR, it is based on some special property of the
option's symbol).

> >    . we should decide how to handle TS-based modes whose non-TS
> >      counterparts are available as 3rd-party packages
> 
> I think we shouldn't do anything about those - they will continue to use 
> the current policy for 3rd party major modes: installing a package adds 
> an 'add-to-list' form to autoloads, which runs during 
> package-initialize. To disable such a form, the user uninstalls a package.

Maybe.  I'd be interested to hear what others think.

> >    . we should decide whether we want to modify auto-mode-alist or use
> >      major-mode remapping for all the TS-based modes
> 
> I see no reason to depart from the current approach - except I've 
> switched from major-mode-remap-defaults to major-mode-remap-alist (where 
> the former is used) because the latter corresponds to user preferences, 
> and it seems like that's the subject of our switcher.
> 
> This could also be discussed, but seems more of an orthogonal issue.

Not really orthogonal, since I think Stefan was against changing
auto-mode-alist, because it doesn't handle mode cookies and file-local
variables.

Re: Turning on/off tree-sitter modes

[Juri Linkov]

>>> How about if that's done like:
>>>
>>>     (setopt treesit-enable-modes '(c-ts-mode))
>>>
>>> Or maybe 'M-x treesit-add-enabled-mode' can be added too.
>> I think a command is better.
>
> Okay. It can read the mode name with completion, and then call
>
>   (setopt treesit-enable-modes (cons new-mode treesit-enable-modes))

Recently Philip rightly noticed that 'major-mode-remap-alist'
would be sufficient.  And indeed, such a command could be implemented
just as

  (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
    (setopt major-mode-remap-alist
            (cons (cons non-ts-mode ts-mode)
                  major-mode-remap-alist)))

Or the idea was to simplify this by using only ts-mode here
while maintaining a huge database of non-ts → ts mappings
in an internal variable?  (that will eventually grow
into something like 'eglot-server-programs')

Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  johan.myreen@gmail.com,  emacs-devel@gnu.org
> Recently Philip rightly noticed that 'major-mode-remap-alist'
> would be sufficient.  And indeed, such a command could be implemented
> just as
> 
>   (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>     (setopt major-mode-remap-alist
>             (cons (cons non-ts-mode ts-mode)
>                   major-mode-remap-alist)))

But is it okay to have a command modify a user option?  Do we have
examples of this anywhere else?

Re: Turning on/off tree-sitter modes

[Juri Linkov]

>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>> would be sufficient.  And indeed, such a command could be implemented
>> just as
>> 
>>   (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>     (setopt major-mode-remap-alist
>>             (cons (cons non-ts-mode ts-mode)
>>                   major-mode-remap-alist)))
>
> But is it okay to have a command modify a user option?  Do we have
> examples of this anywhere else?

Then it could modify the variable 'major-mode-remap-defaults'.
And 'major-mode-remap-alist' will take precedence over it
when customized.

Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 23/11/2024 21:23, Juri Linkov wrote:
>>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>>> would be sufficient.  And indeed, such a command could be implemented
>>> just as
>>>
>>>    (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>>      (setopt major-mode-remap-alist
>>>              (cons (cons non-ts-mode ts-mode)
>>>                    major-mode-remap-alist)))
>> But is it okay to have a command modify a user option?  Do we have
>> examples of this anywhere else?
> Then it could modify the variable 'major-mode-remap-defaults'.
> And 'major-mode-remap-alist' will take precedence over it
> when customized.

I don't have a strong opinion, but it seems like if a variable is 
modified by explicit command from the user, major-mode-remap-alist seems 
more appropriate than major-mode-remap-defaults (which would be about 
some global defaults).

Not 100% sure though - because that plan would delete the vast majority 
of the uses of the latter from the core (except for TeX's mappings, it 
seems).

Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 23/11/2024 19:51, Juri Linkov wrote:
> Recently Philip rightly noticed that 'major-mode-remap-alist'
> would be sufficient.  And indeed, such a command could be implemented
> just as
> 
>    (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>      (setopt major-mode-remap-alist
>              (cons (cons non-ts-mode ts-mode)
>                    major-mode-remap-alist)))

A few problems with that:

- Where does the second argument come from? Do we read the first 
argument from the user as well?
- Some modes can use major-mode-remap-alist, and some (such as 
go-ts-mode) don't have "original" modes to hook up to. For those cases, 
the command would have to read the regexps from the user, and it's #1 
thing we apparently want to avoid.

> Or the idea was to simplify this by using only ts-mode here
> while maintaining a huge database of non-ts → ts mappings
> in an internal variable?  (that will eventually grow
> into something like 'eglot-server-programs')

If we want to have an option like treesit-enable-modes (allowing the 
user to turn on all built-in ts modes), it doesn't seem like we could do 
that without maintaining this database in some form. Only for built-in 
modes, though.

Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 23/11/2024 18:36, Eli Zaretskii wrote:
>> Date: Sat, 23 Nov 2024 18:26:21 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>     . we need the ability to turn on and off selected TS-based modes,
>>>       and do it easily
>>
>> Note that we don't have such capability currently.
> 
> We have, sort-of: loading the mode "turns it on" (with known caveats
> and disadvantages).  In any case, I think we should have this, even if
> we don't have it now.  It should be part of this improvement.

No capability to turn it off, I mean. Anyway, not so hard, except for 
your question regarding having a command change user option. I don't 
know if it's a problem.

>> Both commands would be pure wrappers on top of the user option, so they
>> don't seem to require any advance considerations. Somebody can add those
>> later, or any variations on them.
> 
> We could indeed make them wrappers, but changing the user option is
> not really clean.  If nothing else, users will see that the option was
> "modified outside Custom", which could be confusing.  But if we
> conclude that this is the best way, we could avoid this unpleasant
> effect as well (AFAIR, it is based on some special property of the
> option's symbol).

The indication could be helpful too - mostly in cases when the user 
opens Customize and sees an unexpected value. But we could avoid it like 
you say, saving the change as if the Customize buffer was used. Whatever 
is decided - I don't think the implementation will be a blocker.

>> I see no reason to depart from the current approach - except I've
>> switched from major-mode-remap-defaults to major-mode-remap-alist (where
>> the former is used) because the latter corresponds to user preferences,
>> and it seems like that's the subject of our switcher.
>>
>> This could also be discussed, but seems more of an orthogonal issue.
> 
> Not really orthogonal, since I think Stefan was against changing
> auto-mode-alist, because it doesn't handle mode cookies and file-local
> variables.

Orthogonal in the sense that that choice (whether we want to change that 
thing or not) doesn't affect our design here much. If we wanted to 
switch back to using auto-mode-alist uniformly - which I wouldn't 
recommend personally - the new addition wouldn't have to change much. So 
it's not something we have to revisit right now.

Commands that change user options? [was: Turning on/off tree-sitter modes]

[Drew Adams]

> From: Eli Zaretskii Sent: Saturday, November 23, 2024 10:51 AM
> 
> But is it okay to have a command modify a user option?
> Do we have examples of this anywhere else?


Changing the Subject/thread.  (I know and care nothing
about tree-sitter modes, so far.)
___

IMHO, it's not a problem to have a command that changes
the value of a user option.  That can even be the main,
or even the only, point of a command.  The command's doc
string should say that it does that, of course.  That's
important.

A user using a command to change an option value is no
different from a user using the Customize UI to do so.
A command is just a different UI.

I've never agreed with the idea that Emacs must not allow
a command to set/change a user option - providing its doc
says clearly that that's its job (or part of its job).

It's typical for a minor mode toggle command to do that,
for instance.  And before we had minor modes (or at least
before we used them much) we had commands that toggled
user options.  There should be nothing shocking about this.
___

FWIW:

Vanilla isearch.el goes out of its way in a few places to
have additional variables that are defvars, and to allow
commands to change those vars instead of corresponding
user options, because of the (misguided, IMO) belief that
commands shouldn't ever change option values.  Or to give
it the benefit of the doubt, because it assumes that any
such changes shouldn't persist beyond the current search.

In isearch+.el I've tried to get along with (accommodate)
the vanilla Isearch way of handling such states (vars).

To do that (i.e., to allow some commands to toggle user
options, but not to impose that behavior) I've even added
an option, `isearchp-toggle-option-flag', which if non-nil
lets Isearch toggling commands affect option values.  And 
a nonvanilla command, `isearchp-toggle-option-toggle',
toggles that option!

That option applies only to the standard Isearch commands
`isearch-toggle-invisible' and `isearch-toggle-case-fold'.
In vanilla Emacs, those toggle non-option vars.  (But the
first toggles non-option `isearch-invisible' between the
two values of option `search-invisible'...)

To me, it's often useful to be able to toggle something
like case-folding and have that effect persist beyond a
single search.  It's also useful to have it _not_ persist
beyond a single search - both behaviors are useful.

My version of `isearch-toggle-case-fold' says this in
its doc string:

  Toggle case sensitivity on or off during incremental searching.

  If `isearchp-toggle-option-flag' is non-nil then toggle the value of
  option `isearchp-case-fold'.  If it is nil then toggle the behavior
  only temporarily, so that the option value is unchanged for subsequent
  searches.

  A prefix argument flips the sense of the last paragraph, so that the
  option is updated only if `isearchp-toggle-option-flag' is nil instead
  of non-nil.

Similarly, for `isearch-toggle-invisible'.  

I also have toggling commands for nonvanilla options and
non-option vars that I provide (prefix `isearchp-').  The
doc strings of such commands say whether they toggle an
option or an internal variable.  (It's only in order to
play nice with those two vanilla variables that I provide
`isearchp-toggle-option-flag' and its toggle command.)
___

Really, IMO the simplest thing to do is allow a command
to toggle - or otherwise change - the value of an option
or a non-option, as long as its doc says what it does.

But I've said all of this before - long ago.  Hasn't
convinced anyone in charge, so far.  But I'm glad to see
you pose the question now, Eli.  Maybe it's time to
loosen up on this?

I don't want Emacs to trounce a user's chosen value for
a user option any more than anyone else.  Such settings
are the province of users.  But I consider commands to
be UI's, and some can be UI's that affect options.  All
a command needs to do is let users know what it does.
___

Is there some downside to allowing a command to change
an option value (toggle or another kind of change)?
Only this minor one, that I'm aware of:

I have a function in my `kill-emacs-query-functions'
value called `customize-unsaved'.  If there are any
options whose values I've changed and not saved then
it opens Customize to show me them.  I appreciate such
notification, but I rarely want to save any changes.
(A typical change is toggling some minor mode.)

Re: Turning on/off tree-sitter modes

[Juri Linkov]

>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>> would be sufficient.  And indeed, such a command could be implemented
>> just as
>>    (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>      (setopt major-mode-remap-alist
>>              (cons (cons non-ts-mode ts-mode)
>>                    major-mode-remap-alist)))
>
> A few problems with that:
>
> - Where does the second argument come from? Do we read the first argument
>  from the user as well?

The answer depends on the purpose of the 'treesit-add-enabled-mode'
command that I still don't understand.  Is it supposed to be used
in user configs as

  (treesit-add-enabled-mode 'ruby-mode 'ruby-ts-mode)

to be another way to do the same as

  (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))

Or maybe we want to simplify this setting.  Then we need
not a command, but a new option 'treesit-enable-modes':

  (add-to-list 'treesit-enable-modes 'ruby-ts-mode)

> - Some modes can use major-mode-remap-alist, and some (such as go-ts-mode)
>   don't have "original" modes to hook up to. For those cases, the command
>   would have to read the regexps from the user, and it's #1 thing we
>  apparently want to avoid.
>
>> Or the idea was to simplify this by using only ts-mode here
>> while maintaining a huge database of non-ts → ts mappings
>> in an internal variable?  (that will eventually grow
>> into something like 'eglot-server-programs')
>
> If we want to have an option like treesit-enable-modes (allowing the user
> to turn on all built-in ts modes), it doesn't seem like we could do that
> without maintaining this database in some form. Only for built-in modes,
> though.

Actually, there is already such a database in files.el:
the default value of 'auto-mode-alist' is the database
of file associations.

So for ts-modes that don't have a corresponding non-ts mode in core
we need to add their file associations to 'auto-mode-alist'.
However, not directly, but via a non-ts mode.  So, for example,
'auto-mode-alist' should contain '("\\.go\\'" . go-mode)',
then 'major-mode-remap-defaults' should contain a mapping
from 'go-mode' to 'go-ts-mode'.

This will help to remove the requirement to load a ts-mode file
to change file associations, that currently causes problems
such as:

0. emacs -Q
1. C-h f go- TAB

that pops up the warnings buffer with:

⛔ Warning (treesit): Cannot activate tree-sitter, because language grammar for go is unavailable (not-found)
⛔ Warning (treesit): Cannot activate tree-sitter, because language grammar for gomod is unavailable (not-found)

>> Then it could modify the variable 'major-mode-remap-defaults'.
>> And 'major-mode-remap-alist' will take precedence over it
>> when customized.
>
> I don't have a strong opinion, but it seems like if a variable is modified
> by explicit command from the user, major-mode-remap-alist seems more
> appropriate than major-mode-remap-defaults (which would be about some
> global defaults).
>
> Not 100% sure though - because that plan would delete the vast majority of
> the uses of the latter from the core (except for TeX's mappings, it seems).

Agreed, 'major-mode-remap-defaults' could be removed when loading a ts-mode file
will not modify file associations anymore.

Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  johan.myreen@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 24 Nov 2024 09:29:30 +0200
> 
> > - Where does the second argument come from? Do we read the first argument
> >  from the user as well?
> 
> The answer depends on the purpose of the 'treesit-add-enabled-mode'
> command that I still don't understand.  Is it supposed to be used
> in user configs as
> 
>   (treesit-add-enabled-mode 'ruby-mode 'ruby-ts-mode)
> 
> to be another way to do the same as
> 
>   (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
> 
> Or maybe we want to simplify this setting.  Then we need
> not a command, but a new option 'treesit-enable-modes':
> 
>   (add-to-list 'treesit-enable-modes 'ruby-ts-mode)

When you suggest such ways of implementing user preferences, please
always consider two factors: (a) the complexity from the users' POV,
and (b) the way to undo the preference.

Using alists or lists for customization requires that users understand
the basics of lists in Emacs, and have good command of the relevant
primitives.  As the experience of default-frame-alist suggests, that
is not a trivial thing to master (IMO, default-frame-alist survives
only because most users don't customize it directly, but via
higher-level APIs like set-frame-font etc.).

Undoing the preferences is also not easy when lists/alists are used,
because there could be more than one element in the list, and it's
easy to forget to remove all of them.

> > If we want to have an option like treesit-enable-modes (allowing the user
> > to turn on all built-in ts modes), it doesn't seem like we could do that
> > without maintaining this database in some form. Only for built-in modes,
> > though.
> 
> Actually, there is already such a database in files.el:
> the default value of 'auto-mode-alist' is the database
> of file associations.

What we have in files.el is incomplete.  Some modes modify
auto-mode-alist and some have autoload cookies which do that.

> So for ts-modes that don't have a corresponding non-ts mode in core
> we need to add their file associations to 'auto-mode-alist'.
> However, not directly, but via a non-ts mode.  So, for example,
> 'auto-mode-alist' should contain '("\\.go\\'" . go-mode)',
> then 'major-mode-remap-defaults' should contain a mapping
> from 'go-mode' to 'go-ts-mode'.

This is something we need to agree to first.  Keep in mind that for
Alan Mackenzie this was the proverbial straw that broke the camel's
back, so maybe there are others who think that way.

> This will help to remove the requirement to load a ts-mode file
> to change file associations, that currently causes problems
> such as:

Removing the effect of loading the package should be the main outcome
of whatever we decide to do here, yes.

> > Not 100% sure though - because that plan would delete the vast majority of
> > the uses of the latter from the core (except for TeX's mappings, it seems).
> 
> Agreed, 'major-mode-remap-defaults' could be removed when loading a ts-mode file
> will not modify file associations anymore.

I don't think we can or should remove it, because it's useful for the
cases like the TeX/LaTeX mode (for which we set it up now by default).
I do agree that modes should probably not modify
major-mode-remap-defaults, but I'm not so sure about the commands we
are discussing here -- I see no problem for them to modify that alist,
since that will leave the last word to the users, via
major-mode-remap-alist.

Re: Turning on/off tree-sitter modes

[Stephen Berman]

On Sat, 23 Nov 2024 20:50:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  johan.myreen@gmail.com,  emacs-devel@gnu.org
>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>> would be sufficient.  And indeed, such a command could be implemented
>> just as
>> 
>>   (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>     (setopt major-mode-remap-alist
>>             (cons (cons non-ts-mode ts-mode)
>>                   major-mode-remap-alist)))
>
> But is it okay to have a command modify a user option?  Do we have
> examples of this anywhere else?

One example (admittedly having a much narrower scope than the
tree-sitter case) is `todo-top-priorities-overrides' in todo-mode.el.
Here's its doc string:

  List of rules specifying number of top priority items to show.
  These rules override ‘todo-top-priorities’ on invocations of
  M-x todo-filter-top-priorities and
  M-x todo-filter-top-priorities-multifile.  Each rule is a list
  of the form (FILE NUM ALIST), where FILE is a member of
  ‘todo-files’, NUM is a number specifying the default number of
  top priority items for each category in that file, and ALIST,
  when non-nil, consists of conses of a category name in FILE and a
  number specifying the default number of top priority items in
  that category, which overrides NUM.
  
  This variable should be set interactively by
  M-x todo-set-top-priorities-in-file or
  M-x todo-set-top-priorities-in-category.

Steve Berman

Re: Turning on/off tree-sitter modes

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:
>>>    . we should decide how to handle TS-based modes whose non-TS
>>>      counterparts are available as 3rd-party packages

>> I think we shouldn't do anything about those - they will continue to use 
>> the current policy for 3rd party major modes: installing a package adds 
>> an 'add-to-list' form to autoloads, which runs during 
>> package-initialize. To disable such a form, the user uninstalls a package.

> Maybe.  I'd be interested to hear what others think.

Speaking purely for myself, and as a user, my expectation wrt. 3rd party
packages, would be what Dmitry outlines.

Re: Turning on/off tree-sitter modes

[Stefan Monnier]

>>>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>>>> would be sufficient.  And indeed, such a command could be implemented
>>>> just as
>>>>
>>>>    (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>>>      (setopt major-mode-remap-alist
>>>>              (cons (cons non-ts-mode ts-mode)
>>>>                    major-mode-remap-alist)))
>>> But is it okay to have a command modify a user option?

Yes, it's very much appropriate.

>>> Do we have examples of this anywhere else?

This happens for example in the Custom UI. 🙂
It also happens in `package--save-selected-packages`.
And if you search for `customize-mark-as-set` you'll find other
examples, most notably all global minor modes.

It usually requires checking `called-interactively` to distinguish the
case where it's "modified outside customize", which really is about
making sure that the same change won't happen behind Custom's back next
time we start Emacs (thus interfering with Custom's way to
save&restore the settings).

> Not 100% sure though - because that plan would delete the vast majority of
> the uses of the latter from the core (except for TeX's mappings, it seems).

That sounds good to me.

All the modifications of `major-mode-remap-defaults` that happen
when we *load* a package should be removed as soon as possible.

We could keep such modifications a bit longer by moving them to the
major mode's initialization function, which should be much less
problematic, but fundamentally they should also go the way of the dodo.

The only cases where setting `major-mode-remap-defaults` makes sense,
IMO, is for cases like TeX where we have a major mode that's builtin as
well as one that's not, so the var can be set according to whether the
user installed the external package or not.


        Stefan

Re: Turning on/off tree-sitter modes

[Juri Linkov]

>> The answer depends on the purpose of the 'treesit-add-enabled-mode'
>> command that I still don't understand.  Is it supposed to be used
>> in user configs as
>> 
>>   (treesit-add-enabled-mode 'ruby-mode 'ruby-ts-mode)
>> 
>> to be another way to do the same as
>> 
>>   (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
>> 
>> Or maybe we want to simplify this setting.  Then we need
>> not a command, but a new option 'treesit-enable-modes':
>> 
>>   (add-to-list 'treesit-enable-modes 'ruby-ts-mode)
>
> When you suggest such ways of implementing user preferences, please
> always consider two factors: (a) the complexity from the users' POV,
> and (b) the way to undo the preference.
>
> Using alists or lists for customization requires that users understand
> the basics of lists in Emacs, and have good command of the relevant
> primitives.  As the experience of default-frame-alist suggests, that
> is not a trivial thing to master (IMO, default-frame-alist survives
> only because most users don't customize it directly, but via
> higher-level APIs like set-frame-font etc.).
>
> Undoing the preferences is also not easy when lists/alists are used,
> because there could be more than one element in the list, and it's
> easy to forget to remove all of them.

The Custom UI helps to avoid such problems with the buttons
to add/remove list elements like

  major-mode-remap-alist:
  INS DEL Key: js-mode
          Value: js-ts-mode
  INS DEL Key: ruby-mode
          Value: ruby-ts-mode

>> > Not 100% sure though - because that plan would delete the vast majority of
>> > the uses of the latter from the core (except for TeX's mappings, it seems).
>> 
>> Agreed, 'major-mode-remap-defaults' could be removed when loading a ts-mode file
>> will not modify file associations anymore.
>
> I don't think we can or should remove it, because it's useful for the
> cases like the TeX/LaTeX mode (for which we set it up now by default).

Agreed, 'major-mode-remap-defaults' should stay to handle rare cases.

Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dmitry@gutov.dev,  johan.myreen@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 24 Nov 2024 19:29:44 +0200
> 
> > Using alists or lists for customization requires that users understand
> > the basics of lists in Emacs, and have good command of the relevant
> > primitives.  As the experience of default-frame-alist suggests, that
> > is not a trivial thing to master (IMO, default-frame-alist survives
> > only because most users don't customize it directly, but via
> > higher-level APIs like set-frame-font etc.).
> >
> > Undoing the preferences is also not easy when lists/alists are used,
> > because there could be more than one element in the list, and it's
> > easy to forget to remove all of them.
> 
> The Custom UI helps to avoid such problems with the buttons
> to add/remove list elements like

We should also think about customizations directly in init files, not
via Custom.

>   major-mode-remap-alist:
>   INS DEL Key: js-mode
>           Value: js-ts-mode
>   INS DEL Key: ruby-mode
>           Value: ruby-ts-mode

In addition, I personally find this UI quite perplexing, and kinda
doubt users who use it will understand what "Key" and "value" mean in
this case.

Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 24/11/2024 20:56, Eli Zaretskii wrote:
>>    major-mode-remap-alist:
>>    INS DEL Key: js-mode
>>            Value: js-ts-mode
>>    INS DEL Key: ruby-mode
>>            Value: ruby-ts-mode
> In addition, I personally find this UI quite perplexing, and kinda
> doubt users who use it will understand what "Key" and "value" mean in
> this case.

We could add more detailed annotations to those customization fields, so 
it could look more like this, for example:

   Major Mode Remap Alist:
   Repeat:
   INS DEL Cons-cell:
               Mode to map from: js-mode
               Function to call instead: js-ts-mode
   ...

Re: Turning on/off tree-sitter modes

[Juri Linkov]

>>>    major-mode-remap-alist:
>>>    INS DEL Key: js-mode
>>>            Value: js-ts-mode
>>>    INS DEL Key: ruby-mode
>>>            Value: ruby-ts-mode
>> In addition, I personally find this UI quite perplexing, and kinda
>> doubt users who use it will understand what "Key" and "value" mean in
>> this case.
>
> We could add more detailed annotations to those customization fields, so it
> could look more like this, for example:
>
>   Major Mode Remap Alist:
>   Repeat:
>   INS DEL Cons-cell:
>               Mode to map from: js-mode
>               Function to call instead: js-ts-mode
>   ...

Also it's possible to add the keyword :options

  :options '((js-mode (function :value js-ts-mode))
             (ruby-mode (function :value ruby-ts-mode)))

that will allow the users just to click on the checkbox
to enable a ts-mode.

Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> Date: Mon, 25 Nov 2024 02:44:52 +0200
> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 24/11/2024 20:56, Eli Zaretskii wrote:
> >>    major-mode-remap-alist:
> >>    INS DEL Key: js-mode
> >>            Value: js-ts-mode
> >>    INS DEL Key: ruby-mode
> >>            Value: ruby-ts-mode
> > In addition, I personally find this UI quite perplexing, and kinda
> > doubt users who use it will understand what "Key" and "value" mean in
> > this case.
> 
> We could add more detailed annotations to those customization fields, so 
> it could look more like this, for example:
> 
>    Major Mode Remap Alist:
>    Repeat:
>    INS DEL Cons-cell:
>                Mode to map from: js-mode
>                Function to call instead: js-ts-mode

I think this would be a big step in the right direction.

Bonus points for replacing "Repeat" and "Cons-cell" with something
more user-friendly, like "Set of remappings" and "Remap", for example.