Re: save-excursion and the mark

[Magnar Sveen <magnars@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

> That wouldn't solve the problems with save-excursion.

You're calling save-excursion a "broken API", but it's in use everywhere -
it is a staple of emacs lisp - and has been working for years. So yeah,
offering an alternative for the 1% of cases where it isn't working as
intended would solve the problem. With no breakage.

I don't get the impression that you're taking seriously the millions of
lines of code that you don't have access to. That was written years ago.
That was copied from the emacs wiki. That people are relying on, but no
longer know how to change. It's not like you'll get a proper error message
when it breaks.

> If/when the many other cases come storming, I might reconsider those tradeoffs,
of course.

Are you seriously expecting users of Emacs to storm into emacs-devel in
anticipation of their code breaking prior to a release? Or are you talking
about rolling back a breaking change after the fact, creating issues for
new code relying on new behavior?

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.

- Magnar

On Wed, Apr 15, 2015 at 2:53 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > You are maintaining an API with many thousands of users. Don't break it.
>
> Maintaing broken APIs is all a matter of tradeoffs.  We happen to
> disagree on those tradeoffs here.  So far your case is the only one.
> If/when the many other cases come storming, I might reconsider those
> tradeoffs, of course.
>
> > If you must, deprecate it. Introduce save-point, and add "You probably
> > want to use save-point" to the docstring of save-excursion.
>
> That wouldn't solve the problems with save-excursion.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 2673 bytes --]