On 04/15/2015 07:59 AM, Stefan Monnier wrote:
>>> That wouldn't solve the problems with save-excursion.
>> You're calling save-excursion a "broken API", but it's in use everywhere -
> 
> Yes, the save-point part of it is used everywhere and works well.
> The save-mark part of it was used pretty much nowhere and does not work well.
> 
>> it is a staple of emacs lisp - and has been working for years.
> 
> Still works.  Just ever so slightly differently.
> 
>> So yeah, offering an alternative for the 1% of cases where it isn't
>> working as intended would solve the problem. With no breakage.
> 
> As mentioned, there was breakage.
> 
>> It's not like you'll get a proper error message when it breaks.
> 
> I know, just like the previously existing breakage that got fixed by
> this change.
> 
>> Are you seriously expecting users of Emacs to storm into emacs-devel in
>> anticipation of their code breaking prior to a release?
> 
> There's already been very hot debates about this change, but actual
> examples of broken code have been really hard to come by, so despite the
> heat I've gotten, am getting, and will keep getting, I'll stick to my
> guns for now.
> 
>> Or are you talking about rolling back a breaking change after the fact,
> 
> That's clearly an option.  Doing so after 25.1 is released would be
> highly unlikely, but until 25.1 the change is tentative.
> 
>> creating issues for new code relying on new behavior?
> 
> Based on what I've seen of existing uses of save-excursion, I'm not
> worried about this.
> 
>> It was just the other day that I pointed out a package in Emacs that's
>> from 1999 to a friend.  It's not been changed since.  I used it as an
>> example of how stable Emacs is, and how it allows for a piece of
>> software to be done.  Really done.  This new attitude towards breaking
>> changes saddens me in that light.
> 
> Every Emacs release introduced incompatible changes.  Maybe more so
> under my maintainership, I don't know.
> 
> But the only thing that could change my opinion, I think, is more
> evidence that this change breaks a lot of code (and of course, such
> evidence is stronger when found in high-quality code, since I'm more
> willing to break bad code than good code).

FWIW, I agree that breaking strict compatibility in this particular
instance is the right thing to do.