Re: An anonymous IRC user's opinion

[Eli Zaretskii <eliz@gnu.org>]

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