Re: save-excursion and the mark

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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


        Stefan