[Top][All Lists]

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

Re: save-excursion again

From: Stefan Monnier
Subject: Re: save-excursion again
Date: Fri, 18 Jun 2010 09:51:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> I am just catching up belatedly with this issue of save-excursion getting
> defeated by set-buffer.  Here is my understanding.  Please let me know if
> I am missing anything.  If I have a piece of code like this that runs
> in a buffer A:

>      (save-excursion
>         (set-buffer B)
>         ....X....
>      )

> then:

> - if the code X has no possibility of getting back to the buffer A and
> moving point, then save-excursion can be replaced by save-current-buffer
> (and the byte compiler gives you a brownie point).


> - if the code X has a possibility of getting back to the buffer A and moving
> around, then save-excursion should stay (despite getting smacked by the byte
> compiler).

It's actually slightly more subtle than that, because it depends on what
you want to happen when you "get back to A and move around": it depends
on whether or not you want the movement in A to be undone when you exit
this code.

If you do want to undo this movement, then indeed your `save-excursion'
and your `set-buffer' are fundamentally unrelated (they just happen to
be next to each other by chance) and the byte-compiler warning is in
error.  This is very rare in my experience (contrary to the case where
the correct code is (with-current-buffer B (save-excursion ....)), which
tho not common, has happened a few times).

> So, every time we want to please the byte compiler, we need to
> prove a little theorem to the effect that the code X doesn't enter the
> buffer A?  (No doubt some of these theorems will be obvious.)

Indeed.  The problem being that the precise semantics of such
a construction is pretty subtle, so the byte-compiler can't do the proof
for you.  In some cases the proof is easy (e.g. there's no movement at
all in that piece of code), but often it's very difficult (tho my
experience might be made worse since I usually make such changes to code
with which I'm not familiar).  My approach is to basically replace all
such code with just `with-current-buffer', then let users find the
counter examples.


reply via email to

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