Re: An anonymous IRC user's opinion

[Eli Zaretskii <eliz@gnu.org>]

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