[Top][All Lists]

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

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

From: Uday Reddy
Subject: Re: `save-excursion' defeated by `set-buffer'
Date: Sun, 13 Mar 2011 20:48:12 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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!


reply via email to

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