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

[Drew Adams]

So this thread seems to have petered out. I was hoping for some better
understanding.

I would like to see a clear, logical presentation of what your position is,
Stefan. It's not obvious to me what this is all about.

What David said in the thread made sense to me. I'm willing to learn that you
have a good point, Stefan, but so far I don't understand it.

The Elisp manual still (23.1.91) says, e.g., "you should normally use
`set-buffer' within a `save-current-buffer' or `save-excursion'". And it has
model examples that use (save-excursion... (set-buffer...)...), including where
we explain about changing the current buffer.

See nodes `Cleanups', `Creating Buffer-Local', `Current Buffer', and `Clickable
Text'. And there are other nodes that use `switch-to-buffer' within a
`save-excursion' (which would seem to be a similar issue).

Node `Excursions', which provides the doc for `save-excursion', has no example
using `set-buffer', but neither does it say anything that contradicts the use of
`set-buffer' with `save-excursion'.

The explanation in that node is just what I've always understood wrt
`save-excursion'. It makes it clear that only point and mark of the current
buffer are saved and restored, along with the identity of the current buffer. So
I really don't see what the problem is.

`set-buffer' changes only the buffer. `save-excursion' saves and restores only
the identity of the current buffer and its point and mark - nothing more. What
else is there to know about their use together?

What is the real issue? How does `set-buffer' "defeat" `save-excursion' _in
general_? (This is a general warning.)

Sure, if someone doesn't understand what `save-excursion' does, and mistakenly
thinks, e.g., that it restores point and mark in more than just the original
buffer, then the programmer's intention is likely to be defeated.

But that's not a general problem of using the two together; that's just
misunderstanding what they do. If that's the only "problem" we are warning
programmers about, then I think the warning is misguided.

If that's not what this warning is about, then what is? If your way of looking
at this (which is not yet clear to me) is somehow better, then how about a clear
argument? I, for one, am willing to learn, but so far this warning and your
defense of it have at best only confused me instead of enlightening me.

And if the warning is truly useful, then it should say more clearly what the
problem is that it is warning about. If you can't say that in a message, then
have the message point to an explanation in the manual.