[Top][All Lists]

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

Re: `save-excursion' defeated by `set-buffer'

From: David Kastrup
Subject: Re: `save-excursion' defeated by `set-buffer'
Date: Sat, 12 Mar 2011 11:42:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Sat, 12 Mar 2011 10:34:45 +0100
>> >   Warning: `save-excursion' will not preserve point in the other buffer
>> >   set by `set-buffer'
>> Is there a particular reason that nobody is interested in letting the
>> warning be about the case that is supposed to be problematic
> Huh?  That's what I tried to express in the above text.  Isn't that
> _precisely_ the problematic case, when the other buffer is not the
> current and the body of save-excursion moves point and/or mark there?

No, it isn't.  The likelilood that somebody uses `set-buffer' when he
expects it not to change the current buffer is not exactly large.

> If that's not the problematic case, please cough up why not, rather
> than asking rhetorical questions.
>> The problem seems more like
>> Warning: `save-excursion' will preserve point and mark in the current
>>          buffer even if set-buffer does not actually change buffers.
> Your "warning" describes what `save-excursion' is supposed to do, at
> least according to the ELisp manual:
>        The `save-excursion' special form saves the identity of the current
>        buffer and the values of point and the mark in it, evaluates BODY,
>        and finally restores the buffer and its saved values of point and
>        the mark.
> So how could warning about the normal operation be TRT?

Very funny.  Of course the warning will be about a situation where every
function works according to its specifications.  Otherwise, it would be
reason for either a bug fix or an error message rather than a warning.

Anyway, I suggest you get yourself up to speed by reading a few messages
from Stefan Monnier about his rationale for introducing this warning.

David Kastrup

reply via email to

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