[Top][All Lists]

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

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

From: Drew Adams
Subject: RE: `save-excursion' defeated by `set-buffer'
Date: Tue, 5 Jan 2010 16:02:39 -0800

> >    (save-excursion
> >      ...
> >      (set-buffer ...)
> >      (goto-char ...)
> >      ...)
> >
> > The problem with that code is that point in current buffer 
> > will be moved depending on whether the buffer we switch to
> > is the same as the current buffer.
> And it will get restored in the current (original) buffer at 
> the end of the save-excursion.
> So it is not the save-excursion that is defeated by set-buffer, but
> rather the goto-char which may be defeated by save-excursion.


But I think it's not helpful to speak here of anything being "defeated" by
anything. The only thing defeated is the user's possible misconception of what
should happen.

Certainly, `set-buffer' does not undo or inhibit or interfere with the normal
behavior of `save-excursion'; it cannot be said to "defeat" `save-excursion' in
any way.

And the `goto-char' works fine. There is nothing wrong with it, regardless of
which buffer is the target of `set-buffer'. It's simply that `save-excursion'
restores some previous state.

But only after its body is finished. For the duration of the body,
`save-excursion' has no effect. What happens inside a `save-excursion' is not an
issue - `save-excursion' does not change the behavior of code inside it. And
aside from non-local exits (e.g. `throw'), its body has no effect on the
behavior of `save-excursion'. AFAIK.

What's at issue here is only user understanding about `save-excursion', AFAICT.
The problem is apparently that some users could forget or not know that
`save-excursion' restores point and mark in the original buffer (only), along
with restoring the current-buffer identity. 

So what? Some users forget or don't know that (setq a '(b)) doesn't necessarily
create new list structure each time it is evaluated. Some users - including any
of us - forget or don't know lots of things.

This is an education problem. Compiler warnings can sometimes help with
education, but only if they are (a) not too noisy, (b) accurate and precise, and
(c) understandable. I see this warning as not helping but, at best, confusing

If you think that byte-compile is clever enough to determine the places where it
really should warn (certainly not every use of `set-buffer' inside
`save-excursion'), then the message should refer the user to the explanation of
`save-excursion' in the manual. The manual can point out the issue raised here,
if it is indeed a common gotcha.

But I doubt that byte-compile is that clever now or that it even could be made
that clever. IMO the warning should simply be removed.

reply via email to

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