Re: save-excursion again

[Uday S Reddy <u.s.reddy@cs.bham.ac.uk>]

Stefan Monnier writes:

> 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).

On the other hand, it seems to be very common in my experience.

In VM, the code is generally playing around with multiple buffers:
there is a Folder buffer (where the mail is stored), a Presentation
buffer (where it is displayed), a Summary buffer, and possibly one or
more process buffers (for talking to mail servers) and tons of
temporary buffers that are used for MIME encoding/decoding and other
processing.  Whenever, we switch to a different buffer, we almost
always want to come back to the old place, as if nothing had happened.
Further more, the code is modular.  It doesn't really know where it is
running, only what it needs to do.  So, the save-excursion/set-buffer
pattern is not only the correct thing to do, but also the *safest*
thing to do.  Changing it can break the code in quite subtle ways
which can be difficult to track down.

When I first got involved with VM, there were a host of problems that
were called "jumping cursor" issues.  You do something and the cursor
ends up at a different place.  If you then delete a message, you end
up deleting the wrong message.  Fixing these problems always involved
adding plenty of save-excursion's so that the cursor doesn't move
while work was going on.

In fact, I would have rather liked a compiler that asked, do you
really want to do set-buffer without a save-excursion first?  That is,
set-buffer without save-excursion is dangerous, because it might lead
to the "jumping cursor" problem.

So, I am a bit surprised that anybody should think of save-excursion
as being a bad idea to be avoided.  I am still trying to understand
this.

> 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.

I will assume you are joking.  But, why bother with any of this at
all?  What is wrong with the original code in the first place? 

I guess this might have been discussed in the previous rounds of
discussions, but I really couldn't find the answer.

Cheers,
Uday