emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] When deleting in bookmark menu, prompt for confirmation.


From: Eli Zaretskii
Subject: Re: [PATCH] When deleting in bookmark menu, prompt for confirmation.
Date: Mon, 03 May 2021 21:44:55 +0300

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Mon, 3 May 2021 11:28:12 -0700
> 
> Just a random musing: would there be any sense in adding a global option 
> like `prefer-conservative-defaults' to Emacs 28 and mentioning it in the 
> NEWS so that, come Emacs 29, developers could make modestly 
> backwards-incompatible changes like this while keeping the old behavior 
> for people with `prefer-conservative-defaults' set to t (which they 
> hopefully set upon the release of Emacs 28)?

That requires that those users know about that option and turn it on
the moment they install the new Emacs.  I'm not sure I understand why
we should assume such an option will be known.

> One downside I see right off the bat is that 
> `prefer-conservative-defaults' == t would roughly mean "keep Emacs like 
> it was in version 28", but a decade from now, someone might prefer Emacs 
> 38 and want conservative defaults starting then. I suppose 
> `prefer-conservative-defaults' could specify a preferred version, and 
> `defcustom' could allow for multiple default values defined by 
> particular version ranges.

You make it sound as if defaults never change in Emacs.  That is
definitely not true: we do change them, after we receive feedback from
users who opt in to the new behavior.

Also, a behavior can be incompatible only where existing features are
considered.  New features cannot by definition behave incompatibly,
because there's nothing to compare them to.  So compatible behavior
does not mean that Emacs 38 will be the same as Emacs 28: it will have
many new features and packages that 28 never had.

> Either of these solutions would increase the maintenance burden somewhat 
> for those variables (the second especially), but no one is *required* to 
> make backwards-incompatible changes, so I'd hope this is only done when 
> a developer truly believes that the new behavior is better, and is 
> worried that existing users won't want to change.

I don't think I agree with that assessment.  Incompatible behaviors
are also introduced because each one of us has personal preferences.
So "truly believes" is many times in the eyes of the beholder.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]