Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Lars Ingebrigtsen]

stefankangas@gmail.com (Stefan Kangas) writes:

> branch: master
> commit 0161c9df6edc02db6bd8871b00df522dd0699157
> Author: Stefan Kangas <stefan@marxist.se>
> Commit: Stefan Kangas <stefan@marxist.se>
>
>     Load all generic-x.el modes unconditionally

This seems to lead to:

Not registering prefix "in" from generic-x.  Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode")
Not registering prefix "re" from generic-x.  Affects: ("reg-generic-mode" "resolve-conf-generic-mode")

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 09 Feb 2021 18:16:04 +0100
> Cc: Stefan Kangas <stefan@marxist.se>
> 
> stefankangas@gmail.com (Stefan Kangas) writes:
> 
> > branch: master
> > commit 0161c9df6edc02db6bd8871b00df522dd0699157
> > Author: Stefan Kangas <stefan@marxist.se>
> > Commit: Stefan Kangas <stefan@marxist.se>
> >
> >     Load all generic-x.el modes unconditionally
> 
> This seems to lead to:
> 
> Not registering prefix "in" from generic-x.  Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode")
> Not registering prefix "re" from generic-x.  Affects: ("reg-generic-mode" "resolve-conf-generic-mode")

And I don't think I even like the idea of that change.  Why force on
the user all the gazillion of modes in generic-x?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> This seems to lead to:
>
> Not registering prefix "in" from generic-x.  Affects: ("inf-generic-mode"
> "ini-generic-mode" "ini-generic-mode-find-file-hook"
> "inetd-conf-generic-mode")
> Not registering prefix "re" from generic-x.  Affects: ("reg-generic-mode"
> "resolve-conf-generic-mode")

These aren't serious problems.
The underlying problem of course is more serious: `generic-x` doesn't
follow our usual prefix namespacing policy.


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Tue, 09 Feb 2021 18:16:04 +0100
>> Cc: Stefan Kangas <stefan@marxist.se>
>>
>> stefankangas@gmail.com (Stefan Kangas) writes:
>>
>> > branch: master
>> > commit 0161c9df6edc02db6bd8871b00df522dd0699157
>> > Author: Stefan Kangas <stefan@marxist.se>
>> > Commit: Stefan Kangas <stefan@marxist.se>
>> >
>> >     Load all generic-x.el modes unconditionally
>>
>> This seems to lead to:
>>
>> Not registering prefix "in" from generic-x.  Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode")
>> Not registering prefix "re" from generic-x.  Affects: ("reg-generic-mode" "resolve-conf-generic-mode")
>
> And I don't think I even like the idea of that change.  Why force on
> the user all the gazillion of modes in generic-x?

(Only users who require generic-x.)

It was discussed before,[1] but I'm happy to revert the change if it is
not wanted.

Footnotes:
[1]  https://lists.gnu.org/r/emacs-devel/2021-01/msg01403.html

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 9 Feb 2021 13:45:50 -0600
> Cc: emacs-devel@gnu.org
> 
> > And I don't think I even like the idea of that change.  Why force on
> > the user all the gazillion of modes in generic-x?
> 
> (Only users who require generic-x.)
> 
> It was discussed before,[1] but I'm happy to revert the change if it is
> not wanted.

I don't see a discussion, just an opinion that some variable should go
away.  Can't we remove it without activating all the modes?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see a discussion, just an opinion that some variable should go
> away.

Fair enough.  But there were also no opinions to the contrary, including
on the proposed patch.

> Can't we remove it without activating all the modes?

What would you propose?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 9 Feb 2021 14:47:53 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > Can't we remove it without activating all the modes?
> 
> What would you propose?

I don't know.  How did you intend to handle the backward compatibility
issues?  There are probably gobs of users out there who require
generic-x at startup.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't know.  How did you intend to handle the backward compatibility
> issues?

The plan is what you see: to announce it in NEWS.

The other option I see is to revert the change.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> I don't see a discussion, just an opinion that some variable should go
> away.  Can't we remove it without activating all the modes?
[...]
> How did you intend to handle the backward compatibility issues?

I'm not sure which kinds of backward compatibility issues you're
thinking of.

AFAIK none of the functions defined in `generic-x` overlap with other
packages, so there shouldn't be any conflict or
backward incompatibility.

What am I missing?


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefan@marxist.se>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Tue, 09 Feb 2021 17:00:13 -0500
> 
> > I don't see a discussion, just an opinion that some variable should go
> > away.  Can't we remove it without activating all the modes?
> [...]
> > How did you intend to handle the backward compatibility issues?
> 
> I'm not sure which kinds of backward compatibility issues you're
> thinking of.
> 
> AFAIK none of the functions defined in `generic-x` overlap with other
> packages, so there shouldn't be any conflict or
> backward incompatibility.
> 
> What am I missing?

What do we tell all those (myself included) who require generic-x in
their init files?

And while at that: why did you think that variable was ugly and had to
go?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

>> > I don't see a discussion, just an opinion that some variable should go
>> > away.  Can't we remove it without activating all the modes?
>> [...]
>> > How did you intend to handle the backward compatibility issues?
>> 
>> I'm not sure which kinds of backward compatibility issues you're
>> thinking of.
>> 
>> AFAIK none of the functions defined in `generic-x` overlap with other
>> packages, so there shouldn't be any conflict or
>> backward incompatibility.
>> 
>> What am I missing?
>
> What do we tell all those (myself included) who require generic-x in
> their init files?

I don't know what they need to be told.
Can you clarify what broke or risks breaking because of the change?

> And while at that: why did you think that variable was ugly and had
> to go?

Because a file that defines different sets of functions depending on
some configuration variable tends to be problematic (I can't remember
the exact issue that prompted my suggestion but it was related to that
IIRC).


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefan@marxist.se,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 09:00:07 -0500
> 
> > What do we tell all those (myself included) who require generic-x in
> > their init files?
> 
> I don't know what they need to be told.
> Can you clarify what broke or risks breaking because of the change?

I thought it was clear: suddenly those users will have a gazillion
modes defined they never intended to use or load or even know about.

> > And while at that: why did you think that variable was ugly and had
> > to go?
> 
> Because a file that defines different sets of functions depending on
> some configuration variable tends to be problematic (I can't remember
> the exact issue that prompted my suggestion but it was related to that
> IIRC).

I'm sorry, I don't really see any problem with that.  We have lived
with that problem for many years.  So I tend to think the cure is
worse than the disease.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > What do we tell all those (myself included) who require generic-x in
>> > their init files?
>>
>> I don't know what they need to be told.
>> Can you clarify what broke or risks breaking because of the change?
>
> I thought it was clear: suddenly those users will have a gazillion
> modes defined they never intended to use or load or even know about.

Could we perhaps take another step back here and ask: why is that a
problem?

To my mind, I only run the risk of getting some unexpected syntax
highlighting (which would actually be welcome in my use).

If the generic modes themselves are worse than having no syntax
highlighting, they should either be fixed or removed.

What am I missing?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

>> I don't know what they need to be told.
>> Can you clarify what broke or risks breaking because of the change?
> I thought it was clear: suddenly those users will have a gazillion
> modes defined they never intended to use or load or even know about.

I don't see the harm in that.  When you start Emacs you have a gazillion
modes predefined most of which you never intended to use.
What's different here?

> I'm sorry, I don't really see any problem with that.  We have lived
> with that problem for many years.  So I tend to think the cure is
> worse than the disease.

I can't judge because I can't see the disease yet.


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

>>> > What do we tell all those (myself included) who require generic-x in
>>> > their init files?
>>> I don't know what they need to be told.
>>> Can you clarify what broke or risks breaking because of the change?
>> I thought it was clear: suddenly those users will have a gazillion
>> modes defined they never intended to use or load or even know about.
> Could we perhaps take another step back here and ask: why is that a
> problem?
> To my mind, I only run the risk of getting some unexpected syntax
> highlighting (which would actually be welcome in my use).

Ah... maybe we should keep the `generic-extras-enable-list` but make it
affect only the changes to `auto-mode-alist`.  So all modes always get
defined (like now) but they're not all automatically activated in
some files.


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 10 Feb 2021 10:44:35 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > I thought it was clear: suddenly those users will have a gazillion
> > modes defined they never intended to use or load or even know about.
> 
> Could we perhaps take another step back here and ask: why is that a
> problem?

generic-x is unusual, in that it defines a very large number of
modes.  It's like a large collection of small files, each one of which
defines a separate mode.  So it included a mechanism to pretend only
some of the file was loaded.

> To my mind, I only run the risk of getting some unexpected syntax
> highlighting (which would actually be welcome in my use).
> 
> If the generic modes themselves are worse than having no syntax
> highlighting, they should either be fixed or removed.
> 
> What am I missing?

Users might not want some file suddenly turn on a mode the user didn't
intend to use.  I don't understand what else there is to explain here,
really.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefan@marxist.se,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 11:50:30 -0500
> 
> >> I don't know what they need to be told.
> >> Can you clarify what broke or risks breaking because of the change?
> > I thought it was clear: suddenly those users will have a gazillion
> > modes defined they never intended to use or load or even know about.
> 
> I don't see the harm in that.  When you start Emacs you have a gazillion
> modes predefined most of which you never intended to use.

No, I don't.  Not a gazillion.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 12:07:48 -0500
> 
> Ah... maybe we should keep the `generic-extras-enable-list` but make it
> affect only the changes to `auto-mode-alist`.  So all modes always get
> defined (like now) but they're not all automatically activated in
> some files.

That'd be a definite improvement on what we have now.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> Users might not want some file suddenly turn on a mode the user didn't
> intend to use.  I don't understand what else there is to explain here,
> really.

I thought you were talking about modes being defined, for which I don't
see any harm.  But indeed, the changes to `auto-mode-alist` imply
a change in behavior which could I guess be annoying (especially since
those modes are quite primitive).

My problem was with conditionally defining the modes, not with
conditionally activating them.  So if we restore the config var but make
it apply only to the `auto-mode-alist` changes, then I think we'll all
be happy.

Stefan K, could you do that?


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Matt Armstrong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Users might not want some file suddenly turn on a mode the user didn't
>> intend to use.  I don't understand what else there is to explain here,
>> really.
>
> I thought you were talking about modes being defined, for which I don't
> see any harm.  But indeed, the changes to `auto-mode-alist` imply
> a change in behavior which could I guess be annoying (especially since
> those modes are quite primitive).
>
> My problem was with conditionally defining the modes, not with
> conditionally activating them.  So if we restore the config var but make
> it apply only to the `auto-mode-alist` changes, then I think we'll all
> be happy.
>
> Stefan K, could you do that?

Separately (almost), when looking at this I noticed that files.el
installs a mode for .Xdefaults in auto-mode-alist, and so does
generic-x.el. I wonder how many modes in generic-x.el are redundant with
modes elsewhere in Emacs. Perhaps it is just the one.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Matt Armstrong <matt@rfc20.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  Stefan Kangas
>  <stefan@marxist.se>,  emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 10:29:27 -0800
> 
> Separately (almost), when looking at this I noticed that files.el
> installs a mode for .Xdefaults in auto-mode-alist, and so does
> generic-x.el. I wonder how many modes in generic-x.el are redundant with
> modes elsewhere in Emacs. Perhaps it is just the one.

A mode for Windows batch files is another one, AFAIR.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: stefan@marxist.se,  larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Wed, 10 Feb 2021 11:50:30 -0500
>> 
>> >> I don't know what they need to be told.
>> >> Can you clarify what broke or risks breaking because of the change?
>> > I thought it was clear: suddenly those users will have a gazillion
>> > modes defined they never intended to use or load or even know about.
>> 
>> I don't see the harm in that.  When you start Emacs you have a gazillion
>> modes predefined most of which you never intended to use.
>
> No, I don't.  Not a gazillion.

I actually counted them. In an emacs -Q, auto-mode-alist has 100
distinct modes, and generic-mode-x.el provides 35 modes (but not all are
"activated" on all platforms).

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Separately (almost), when looking at this I noticed that files.el
>> installs a mode for .Xdefaults in auto-mode-alist, and so does
>> generic-x.el. I wonder how many modes in generic-x.el are redundant with
>> modes elsewhere in Emacs. Perhaps it is just the one.
>
> A mode for Windows batch files is another one, AFAIR.

That seems to have changed:

(define-obsolete-function-alias 'bat-generic-mode #'bat-mode "24.4")

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Matt Armstrong <matt@rfc20.org> writes:

> Separately (almost), when looking at this I noticed that files.el
> installs a mode for .Xdefaults in auto-mode-alist, and so does
> generic-x.el.

We should decide which is the best one and remove the other one.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Users might not want some file suddenly turn on a mode the user didn't
>> intend to use.  I don't understand what else there is to explain here,
>> really.
>
> I thought you were talking about modes being defined, for which I don't
> see any harm.  But indeed, the changes to `auto-mode-alist` imply
> a change in behavior which could I guess be annoying (especially since
> those modes are quite primitive).

I admit that I still don't see the benefit of not just activating all
these modes.  Why would the user not want to use these modes?

They may not be very impressive, but surely they are better than
nothing.  If they are not better than nothing, they should probably
better be removed.

What am I missing?

> My problem was with conditionally defining the modes, not with
> conditionally activating them.  So if we restore the config var but make
> it apply only to the `auto-mode-alist` changes, then I think we'll all
> be happy.
>
> Stefan K, could you do that?

I'm actually more inclined to revert the previous commit.

But I'm again wondering: why not just ask users that don't want one or
more of these modes to remove them from auto-mode-alist?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Feb 2021 08:22:55 -0600
> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org
> 
> Matt Armstrong <matt@rfc20.org> writes:
> 
> > Separately (almost), when looking at this I noticed that files.el
> > installs a mode for .Xdefaults in auto-mode-alist, and so does
> > generic-x.el.
> 
> We should decide which is the best one and remove the other one.

Please: "obsolete", not "remove".

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> They may not be very impressive, but surely they are better than
> nothing.  If they are not better than nothing, they should probably
> better be removed.
> What am I missing?

I see two risks, really:

1- some of the regexps used may overlap with some pre-existing entries
   on the default `auto-mode-alist`.  I don't know that it's the case,
   but I think there are enough regexps in `generic-x` and on
   `auto-mode-alist` to make such an overlap possible if not likely.

2- They're only added to `auto-mode-alist` when `generic-x` is loaded,
   which may be too late: they may end up hiding entries added by
   user-installed ELPA packages or by some other part of the user's
   init file.

So, maybe a better solution is to make sure the entries are added to the
*end* of `auto-mode-alist`, which should make them harmless enough.


        Stefan


PS: FWIW, in my case it would make them largely ineffective since I have:

    (setq auto-mode-alist (append auto-mode-alist '(("\\.[^/.]+\\'" ignore t))))

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Please: "obsolete", not "remove".

Sorry, yes.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 1- some of the regexps used may overlap with some pre-existing entries
>    on the default `auto-mode-alist`.  I don't know that it's the case,
>    but I think there are enough regexps in `generic-x` and on
>    `auto-mode-alist` to make such an overlap possible if not likely.

Right, that is indeed a real problem.

(OTOH, I think we should identify and eliminate any such conflicts.)

> 2- They're only added to `auto-mode-alist` when `generic-x` is loaded,
>    which may be too late: they may end up hiding entries added by
>    user-installed ELPA packages or by some other part of the user's
>    init file.

Right again.  I can see that this could be an issue.

> So, maybe a better solution is to make sure the entries are added to the
> *end* of `auto-mode-alist`, which should make them harmless enough.

That sounds good to me: we would then use them only as a last resort.

Is it true that any `auto-mode-alist' entries by third-party packages
installed by package.el are autoloaded before the user can require
generic-x from their init file?  Or did I misunderstand the package
loading mechanism?

If it is true, I think that the above mostly solves the conflict with
third-party packages, even in the case when it is added to
`auto-mode-alist' using `add-to-list' instead of `push'.

And would the above solution be acceptable to you, Eli?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Feb 2021 11:02:23 -0600
> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org
> 
> > So, maybe a better solution is to make sure the entries are added to the
> > *end* of `auto-mode-alist`, which should make them harmless enough.
> 
> That sounds good to me: we would then use them only as a last resort.
> 
> Is it true that any `auto-mode-alist' entries by third-party packages
> installed by package.el are autoloaded before the user can require
> generic-x from their init file?  Or did I misunderstand the package
> loading mechanism?
> 
> If it is true, I think that the above mostly solves the conflict with
> third-party packages, even in the case when it is added to
> `auto-mode-alist' using `add-to-list' instead of `push'.
> 
> And would the above solution be acceptable to you, Eli?

The "above" being that generic-x will add to the end of
auto-mode-alist?  That's better than nothing, although it is still a
backward-incompatible change.  You assume that having some font-lock
cannot hurt, but that isn't necessarily what users will think, because
someone might _want_ to have certain files edited in Fundamental mode,
and adding font-lock could therefore be an unexpected annoyance.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> And would the above solution be acceptable to you, Eli?
>
> The "above" being that generic-x will add to the end of
> auto-mode-alist?

Yes.

> You assume that having some font-lock cannot hurt, but that isn't
> necessarily what users will think, because someone might _want_ to
> have certain files edited in Fundamental mode, and adding font-lock
> could therefore be an unexpected annoyance.

Surely anyone who doesn't want font-lock should be expected to just turn
it off?  They could M-x fundamental-mode, M-x font-lock-mode, or just
remove the entry from auto-mode-alist.  They could even `push' a new
element to it saying to use fundamental-mode instead.

Or they should just not have required generic-x to begin with, since its
express purpose is to add font-locking to various assorted files.

I'm also not sure we should ask what some users "might" want, because
that seems to me too broad.  I think that for any idea, you can always
find those one or two users who really like or dislike it.  Isn't it
therefore more productive to ask what *most* current and new users are
likely to want, and try to model our defaults based on that (while of
course doing our best to respect existing use patterns)?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Feb 2021 12:00:08 -0600
> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, emacs-devel@gnu.org
> 
> I'm also not sure we should ask what some users "might" want, because
> that seems to me too broad.  I think that for any idea, you can always
> find those one or two users who really like or dislike it.  Isn't it
> therefore more productive to ask what *most* current and new users are
> likely to want, and try to model our defaults based on that (while of
> course doing our best to respect existing use patterns)?

For new features, certainly.  But we are talking about changing
existing features that users had years to get used to.  The judgment
calls are different in that case, and so is the importance of what
others might dislike.

And no, I don't consider telling users to turn off font-lock a
legitimate solution.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> And no, I don't consider telling users to turn off font-lock a
> legitimate solution.

You suggested that some people might want to edit using
fundamental-mode.  IMHO asking them to then turn on fundamental-mode is
an adequate solution to that problem.

Stefan M pointed out the problem of conflicts in `auto-mode-alist'.
I think this is a real problem, but one that would be mostly addressed
by his proposal for generic-x.el to put its modes last in
auto-mode-alist.

Do you find that solution acceptable or do you prefer that we revert the
original commit?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Feb 2021 15:28:20 -0600
> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And no, I don't consider telling users to turn off font-lock a
> > legitimate solution.
> 
> You suggested that some people might want to edit using
> fundamental-mode.  IMHO asking them to then turn on fundamental-mode is
> an adequate solution to that problem.
> 
> Stefan M pointed out the problem of conflicts in `auto-mode-alist'.
> I think this is a real problem, but one that would be mostly addressed
> by his proposal for generic-x.el to put its modes last in
> auto-mode-alist.
> 
> Do you find that solution acceptable or do you prefer that we revert the
> original commit?

My preference is to not add to auto-mode-alist at all if the user
didn't say-so.  But if you prefer reverting the changeset, I don't
mind that, either.  I still don't quite understand why Stefan thought
this variable was so ugly that it had to go.  (More generally,
aesthetics issues very seldom if ever justify backward-incompatible
changes, IMO.)

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> My preference is to not add to auto-mode-alist at all if the user
> didn't say-so.  But if you prefer reverting the changeset, I don't
> mind that, either.  I still don't quite understand why Stefan thought
> this variable was so ugly that it had to go.  (More generally,
> aesthetics issues very seldom if ever justify backward-incompatible
> changes, IMO.)

The problem was not with the variable, it was with defining functions
conditionally.  I didn't think about the `auto-mode-alist` part, mostly
because it doesn't appear syntactically in the code (it's "hidden" in
one of the args to `define-generic-mode`).
The variable was just the poor messenger ;-)


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefan@marxist.se>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 12 Feb 2021 08:43:34 -0500
> 
> The problem was not with the variable, it was with defining functions
> conditionally.

And why is that so bad?

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

>> The problem was not with the variable, it was with defining functions
>> conditionally.
> And why is that so bad?

Nothing terrible.  The question for me was rather "what's the benefit?".
But among the disadvantages, the most obvious one is that you can't rely on
(require 'generic-x) to define your function.


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefan@marxist.se,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 12 Feb 2021 09:46:14 -0500
> 
> >> The problem was not with the variable, it was with defining functions
> >> conditionally.
> > And why is that so bad?
> 
> Nothing terrible.  The question for me was rather "what's the benefit?".
> But among the disadvantages, the most obvious one is that you can't rely on
> (require 'generic-x) to define your function.

Yes, but the docs of the package explicitly documents this, so this is
intended behavior.  Like I said, the package is a bit unusual; but
being unusual doesn't mean it's bad.  It gets the job done.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

>> Nothing terrible.  The question for me was rather "what's the benefit?".
>> But among the disadvantages, the most obvious one is that you can't rely on
>> (require 'generic-x) to define your function.
> Yes, but the docs of the package explicitly documents this, so this is
> intended behavior.  Like I said, the package is a bit unusual; but
> being unusual doesn't mean it's bad.  It gets the job done.

I think unusual is bad unless there's some clear benefit.

Having control over which modes are auto-activated via `auto-mode-alist`
is good, so it's a part we can keep.

Having control over which functions are defined doesn't seem to offer
any benefit, so I'd rather get rid of this unusual aspect.


        Stefan

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefan@marxist.se,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 12 Feb 2021 10:23:39 -0500
> 
> >> Nothing terrible.  The question for me was rather "what's the benefit?".
> >> But among the disadvantages, the most obvious one is that you can't rely on
> >> (require 'generic-x) to define your function.
> > Yes, but the docs of the package explicitly documents this, so this is
> > intended behavior.  Like I said, the package is a bit unusual; but
> > being unusual doesn't mean it's bad.  It gets the job done.
> 
> I think unusual is bad unless there's some clear benefit.

This could be a valid argument 20+ years ago, when the package was
added to Emacs.  But that ship has sailed.

> Having control over which modes are auto-activated via `auto-mode-alist`
> is good, so it's a part we can keep.
> 
> Having control over which functions are defined doesn't seem to offer
> any benefit, so I'd rather get rid of this unusual aspect.

Didn't I say that I'm okay with the former?  It's fun to argue, I
know, but since we agree, do we have to continue?

I only mentioned reverting the whole changeset because I sensed Stefan
Kangas was leaning towards it.

Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally

[Stefan Monnier]

> Didn't I say that I'm okay with the former?  It's fun to argue, I
> know, but since we agree, do we have to continue?
>
> I only mentioned reverting the whole changeset because I sensed Stefan
> Kangas was leaning towards it.

Ah, OK, sorry, I misunderstood.
Then we're in violent agreement.


        Stefan