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

[Uday Reddy]

On 3/13/2011 6:25 PM, Drew Adams wrote:

> > save-excursion should be placed *as close as possible* to the point
> > movements that it is trying to revert.
>
> Agreed.  I don't think anyone disputes that.

Oh, good.  We are getting somewhere.

Now, let us take the next step.  Every save-excursion/set-buffer 
combination is a remote save-excursion.  It is trying to protect point 
movements that are far away in code, so far away in fact that it is 
extremely hard to find them.

So, by objecting to the compiler warning, you are indeed disputing the 
principle.

> But you seem to think that `save-excursion' should never have been defined to
> remember which buffer is current and restore that.  `save-excursion' is _not_
> only about point movement.  It is not designed only to save point and mark in
> the current buffer.  It is _designed_ to also restore that buffer, making it
> current again.

In retrospect, it seems that that design was a mistake.  It would have 
been far better to have separate primitives for save-current-buffer and 
save-point-and-mark.  Now that we have save-current-buffer available, 
there is no reason to use save-excursion to restore the current buffer. 
 If you know of such reasons, please tell me.

> > Another way to think about the problem is, for every
> > save-excursion in the code:
> > - are you clear which point movements it is trying to revert,
> > - is it placed as close as possible to those point movements?
>
> Again, no disagreement.
>
> Though `save-excursion' is not only about point movement.  And even wrt point
> movement it really doesn't matter which movements a `save-excursion' is "trying
> to revert".  It is trying to revert them all (in its body) - and it does.
>
> Your real point here, I think, is again that it helps understanding and
> modularity to keep the scope of a `save-excursion' as tight as possible.
> Everyone agrees AFAIK.

If you are agreeing, then it seems that your disagreement is about 
whether the compiler should help people in getting their 
save-excursion's right.  You are not disagreeing that the compiler is 
being helpful.  You seem to be saying that the compiler has no business 
in doing such things.  Is that what this dispute really about?

And, no, I haven't "missed" that save-excursion restores the current 
buffer.  But save-current-buffer restores it just as well, and so that 
aspect of save-excursion doesn't seem relevant.  If you want to argue 
that there are cases where save-excursion is a better choice than 
save-current-buffer, then by all means let us discuss that!

Cheers,
Uday