Please remove compat-preserve-defaults

I just stumbled over the preserve defaults section.

https://github.com/phikal/compat.el/blob/56da4cdb18f71724bcf504c9702998a94f381de9/compat.el#L134-L179

Can you please please restrict the scope of this package and remove this? I thought I had convinced you that the advices are not the best idea. Now you start to overwrite settings which fall firmly into the scope of the init.el or the customize interface. This is another intrusive setting which does not fit here. Compat.el as I see it is a package which is meant for package maintainers. This means compat.el should only come with function and macro backports and nothing else. We had the same discussion regarding the font locking and other additions, which are unnecessary from that perspective. Could you please define the goals of the project more precisely? I know you mean it well, but adding more and more orthogonal changes is not good. It is better to restrict the scope and make things predictable. Less is more, seriously. If I pull in compat.el as a package maintainer, it does not feel good that at the same time I am potentially interfering with customization options, even if it happens only potentially since compat-preserve-defaults is nil.

This idea was discussed and approved on emacs-devel (see this message and responses), and just to clarify the point for anyone else reading the thread, this update the default values of some variables iff they aren't otherwise modified. I am uncertain from your message if this was clear or not.

Could you please define the goals of the project more precisely?

There is no such thing as of now, at least explicitly, but I would say that the primary intention is to provide package maintainers targeting older releases of Emacs functions and macros defined in newer versions (as you were already aware), but I would claim that the the secondary, but in my eyes very valuable, purpose is the ability to propagate upstream changes like these directly to the users. The scope should be limited to variables that are considered important, where the importance of a variable can be discussed on a case-to-case basis.

Oh, am I really the only one opposing this? As I see it propagating upstream variable changes has nothing to do with backwards compatibility. I mean propagating changes which are necessary for the rest of compat.el to function may be acceptable but propagating unrelated changes does not feel right. As a package author I come here to use the backports not to impose changes on to the users, even if these changes have an opt-out mechanism and even if the changes only happen when the user didn't adjust the setting. I really don't understand the scope you are defining here. From my experience it is good to give a scope (ideally well defined and narrow) to a project, but I've already argued about this. It seems to me that your goal is different, you somehow want to back port as much as possible, irrelevant of it is a change which matters to packages or which matters to users - it feels like a lucky bag. To be honest, personally I am not fond of adding such a package to my dependency lists.

Daniel Mendler @.***> writes:

Oh, am I really the only one opposing this?

I have not heard any one else complain, though this is most likely due to nobody really interested in the development of compat.el right now.

As I see it propagating upstream variable changes has nothing to do with backwards compatibility. I mean propagating changes which are necessary for the rest of compat.el to function may be acceptable but propagating unrelated changes does not feel right.

FWIW I agree that it doesn't "feel" right, which is why even though this was planned since even before the first line of code was written, I had only added this recently, as it seems like the only vehicle by which updates like these can be done.

As a package author I come here to use the backports not to impose changes on to the users, even if these changes have an opt-out mechanism and even if the changes only happen when the user didn't adjust the setting.

I would agree, if this were something like changing a variable like mouse-wheel-scroll-amount', but the specific variables and values appear sensible to me (I can see thatpackage-archives' might be more controversial, but at least the IRC defaults are currently broken since the migration to Libera).

I really don't understand the scope you are defining here. From my experience it is good to give a scope (ideally well defined and narrow) to a project, but I've already argued about this. It seems to me that your goal is different, you somehow want to back port as much as possible, irrelevant of it is a change which matters to packages or which matters to users - it feels like a lucky bag.

No, not as much as possible. Just considering variables, there are many options that have changed but adding them to compat would be intrusive and wrong. Again, `package-archives' and ERC/rcirc are exceptions, not the rule.

To be honest, personally I am not fond of adding such a package to my dependency lists.

I am sad to hear this, but I understand it considering your preferences.

-- Philip Kaludercic

FWIW I agree that it doesn't "feel" right, which is why even though this was planned since even before the first line of code was written, I had only added this recently, as it seems like the only vehicle by which updates like these can be done.

I suggest you create a separate library specifically for that purpose. You could even create a modern better defaults package, but there are already a few of that kind.

I would agree, if this were something like changing a variable like mouse-wheel-scroll-amount', but the specific variables and values appear sensible to me (I can see thatpackage-archives' might be more controversial, but at least the IRC defaults are currently broken since the migration to Libera).

Once again - this is not the right place to "fix" this. And yes, the NonGNU ELPA addition is harmful and controversial. First it is harmful because it will suddenly allow to install/upgrade packages which could not be upgraded before on an old installation. These are unforeseen and unexpected side effects. Second I am not happy that you are pushing this like that. NonGNU ELPA is fine and I support it. But I strongly disagree pushing it like that. I know that you are opinionated and want to see MELPA gone. I hope you moderated your opinion with regards to that a little.

My main message is this - a compatibility library is not a place to be opinionated and intrusive! This applies to settings, this applies to advices and so on. I am being consistent here, while you somehow selectively make your choices. The package is supposed to stay out of the way and only do this one small thing it is supposed to do, this is providing functions and macros which have been added in newer Emacs versions. This is what will make the library useful for the primary audience, package authors who want to stay close to upstream but at the same time stay backward compatible. All the other additions (settings, advices, font locking, unnecessary bloat, slow loading time) will hurt these primary use cases.

I am sad to hear this, but I understand it considering your preferences.

The problem is this - your package will be unavoidable. You know that I support the package and the idea and I would like to use it. But please think about this again - this package is not the right place to be opinionated, since this package will be imposed automatically on users. I had thought that I managed to convey this message the last time. Please also ask Stefan Monnier about this.

Daniel Mendler @.***> writes:

FWIW I agree that it doesn't "feel" right, which is why even though this was planned since even before the first line of code was written, I had only added this recently, as it seems like the only vehicle by which updates like these can be done.

I suggest you create a separate library specifically for that purpose. You could even create a modern better defaults package, but there are already a few of that kind.

There would be no real point in this, at least for only two changes (the package archive, IRC). The explicit point of these modifications is to update a value that the user might not know has changed in a future version.

I would agree, if this were something like changing a variable like mouse-wheel-scroll-amount', but the specific variables and values appear sensible to me (I can see thatpackage-archives' might be more controversial, but at least the IRC defaults are currently broken since the migration to Libera).

Once again - this is not the right place to "fix" this. And yes, the NonGNU ELPA addition is harmful and controversial. First it is harmful because it will suddenly allow to install/upgrade packages which could not be upgraded before on an old installation. These are unforeseen and unexpected side effects.

I know, this is the reason I hesitated for so long to add the functionality. I am conscious of the down-sides, but believe that the advantages outweigh them.

Second I am not happy that you are pushing this like that. NonGNU ELPA is fine and I support it. But I strongly disagree pushing it like that. I know that you are opinionated and want to see MELPA gone. I hope you moderated your opinion with regards to that a little.

The motivation here is to provide more packages for people who didn't add any secondary package repositories, if they decided to use MELPA then nothing would change.

My main message is this - a compatibility library is not a place to be opinionated and intrusive! This applies to settings, this applies to advices and so on. I am being consistent here, while you somehow selectively make your choices. The package is supposed to stay out of the way and only do this one small thing it is supposed to do, this is providing functions and macros which have been added in newer Emacs versions. This is what will make the library useful for the primary audience, package authors who want to stay close to upstream but at the same time stay backward compatible. All the other additions (settings, advices, font locking, unnecessary bloat, slow loading time) will hurt these primary use cases.

The initial plan was to provide transparent compatibility, but that intention has since been abandoned (which might also mean that the auto-require should be removed). The current stance is to provide functional compatibility, and use compat as a vehicle to update variables relevant to the GNU project and Emacs. From my perspective, this position is currently consistently implemented.

I am sad to hear this, but I understand it considering your preferences.

The problem is this - your package will be unavoidable. You know that I support the package and the idea and I would like to use it. But please think about this again - this package is not the right place to be opinionated, since this package will be imposed automatically on users. I had thought that I managed to convey this message the last time. Please also ask Stefan Monnier about this.

How about this: Setting the default value of compat-preserve-defaults to t, so that pre-configurations and system administrators can decided to enable it, or users if they even know about it. When there are more users and developers, the issue can be brought up again?

-- Philip Kaludercic

The motivation here is to provide more packages for people who didn't add any secondary package repositories, if they decided to use MELPA then nothing would change.

You ignored my argument why this is bad. My argument has nothing to do with MELPA.

I am conscious of the down-sides, but believe that the advantages outweigh them.

I disagree. Please ask other package developers about this.

The initial plan was to provide transparent compatibility, but that intention has since been abandoned (which might also mean that the auto-require should be removed).

Removing the auto require may also be a good idea. It doesn't hurt if I (require 'compat). I think it is still okay to use functions without namespace, but no advices and no settings. For functions which had changes in their arguments compat-* functions can be provided. This sounds like my preferred plan even, it is the simplest and most modest approach. But then you should also get rid of these settings...

The initial plan was to provide transparent compatibility, but that intention has since been abandoned (which might also mean that the auto-require should be removed). The current stance is to provide functional compatibility, and use compat as a vehicle to update variables relevant to the GNU project and Emacs. From my perspective, this position is currently consistently implemented.

As you write yourself, these goals are not coherent. Therefore you have to specify both incoherent goals separately.

"The current stance is to provide"...

..."functional compatibility"
..."and use compat as a vehicle to update variables relevant to the GNU project and Emacs"

I don't call this a "consistent position". I don't understand why you insist on going with the variable upgrade. It is a bad idea, as simple as that. Of course you could go with a flag which disables this by default but this doesn't turn this into a good idea. This is a general misconception which I've seen around Emacs often.

Daniel Mendler @.***> writes:

The motivation here is to provide more packages for people who didn't add any secondary package repositories, if they decided to use MELPA then nothing would change.

You ignored my argument why this is bad. My argument has nothing to do with MELPA.

^^ Likewise, I was just explaining why NonGNU ELPA appeared worth adding.

I am conscious of the down-sides, but believe that the advantages outweigh them.

I disagree. Please ask other package developers about this.

There really isn't anyone else to ask right now.

The initial plan was to provide transparent compatibility, but that intention has since been abandoned (which might also mean that the auto-require should be removed).

Removing the auto require may also be a good idea. It doesn't hurt if I (require 'compat). I think it is still okay to use functions without namespace, but no advices and no settings. For functions which had changes in their arguments compat-* functions can be provided. This sounds like my preferred plan even, it is the simplest and most modest approach. But then you should also get rid of these settings...

There is just one issue, core packages cannot (currently) depend on ELPA packages. So if there is interest to use compat for project/xref/eldoc/..., this would have to be discussed upstream first.

The initial plan was to provide transparent compatibility, but that intention has since been abandoned (which might also mean that the auto-require should be removed). The current stance is to provide functional compatibility, and use compat as a vehicle to update variables relevant to the GNU project and Emacs. From my perspective, this position is currently consistently implemented.

As you write yourself, these goals are not coherent. Therefore you have to specify both incoherent goals separately.

"The current stance is to provide"...

..."functional compatibility"

..."and use compat as a vehicle to update variables relevant to the GNU project and Emacs"

I don't call this a "consistent position". I don't understand why you insist on going with the variable upgrade. It is a bad idea, as simple as that. Of course you could go with a flag which disables this by default but this doesn't turn this into a good idea.

Why should having two goals be incoherent?

This is a general misconception which I've seen around Emacs often.

I am not sure what you are referring to?

-- Philip Kaludercic

Also, I would prefer if we could continue this discussion on the mailing list. Having two places where issues are discussed will make things harder to maintain, so the issue tracker will be closed (but the mirror will be kept for pull requests).

emacs-compat / compat

Please remove compat-preserve-defaults #6