Re: An anonymous IRC user's opinion

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

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