Re: An anonymous IRC user's opinion

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

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