[Top][All Lists]

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

Re: save-excursion and the mark

From: Daniel Colascione
Subject: Re: save-excursion and the mark
Date: Fri, 17 Apr 2015 18:02:23 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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