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

["Drew Adams" <drew.adams@oracle.com>]

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

No, you are just stating the obvious.

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

Not at all true.  Doesn't follow at all.

And you don't seem to realize yet that `save-excursion' has no effect on point
in any buffer other than the original one that it makes current again when it's
done.

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

Your "principle" has nothing to do with the compiler warning or `save-excursion'
or `set-buffer'.  It is simply the idea that there is no sense including things
in scope that you do not need to include in scope.

I might advise someone not to put one giant `let' at the beginning of his
function, suggesting that he instead use multiple `let's, each with limited
scope and a limited set of variables.  IOW, shrink-fit the scopes to what really
needs scoping in each case.

But that does not call for a warning or imply any danger.  Yes, even if doing
things such a messy way would in the long run likely lead to maintenance
problems and introduce errors.  No need for _alarm_, still.  And no need to
confuse people who are trying to understand `save-excursion' by mixing in such a
mention of scope.

Whether to use `save-excursion' with `set-buffer' has to do with whether you
want to restore which buffer was current and its point and mark, after doing
something in some buffer - possibly point movements and possibly the same
buffer.  Nothing more.

Compiler advice not to use some particular occurrence of `save-excursion' with
`set-buffer' should point to a real or a likely problem.

If all the compiler really means to say each time you use these two functions
together is "Have you made the `save-excursion' scope as tight as possible?",
then it's wasting its time and the user's.  In that case it might as well be
reminding us "Have a nice day" or "Don't forget to brush your teeth".

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

Whose retrospect?  Do you hear RMS saying he made a mistake?

You and I each have our own right to judge, of course, regardless of what RMS
might think now, in retrospect.  But you and I disagree.

> It would have been far better

Far better?

> to have separate primitives for save-current-buffer and 
> save-point-and-mark.

That was already proposed by Stephen T.  And Stefan disagreed that it was even a
good idea, let alone a "far better" idea.

Myself, I don't have a position on it - haven't really thought about it.  But
YAGNI as long as `save-excursion' is available.

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

There is no reason to use it to do only what `save-current-buffer' does.  There
_is_ a reason to use it to do what _it_ does, which is to also restore the
current buffer's point and mark.

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

I am, but you are not!  You just made it pretty clear that you are against using
`save-excursion' with `set-buffer' at all!

> then it seems that your disagreement is about 
> whether the compiler should help people in getting their 
> save-excursion's right.

The compiler does not at all help people get their `save-excursion's right.  And
neither does your proposed change to the manual (on emacs-devel@gnu.org).

The way to help people get their `save-excursion's right, i.e., to avoid the
"problems" that Stefan has referred to, is to document `save-excursion' well and
fix any relevant mistakes in the Emacs source code.

And `save-excursion' is already documented well.  But that doesn't guarantee
that some people won't neglect to read the doc or won't misread it.

You've hinted a few times now that you might not realize that `save-excursion'
does not restore point or mark for any buffer other than the original one.  And
a couple of times now you seem to have missed or forgotten that it also restores
which buffer was current (yes, I see that you disagree below).

And if even _you_ could miss such things from reading what is a clear
explanation then no, there are no guarantees against THE DANGER.

Still, as you admitted, in practice most uses have been sane.  We can thus
generally give users the benefit of the doubt that they can understand the doc
string and figure out when and how to use the function.

> You are not disagreeing that the compiler is being helpful. 

Oh yes I am!  It is not only not being helpful by issuing such warnings; it is
being downright harmful.  I've given several reasons/examples already.

> You seem to be saying that the compiler has no business 
> in doing such things. 

What are "such things"?  Unless it can do something well, helping more than
hurting, then it has no business doing _anything_.  Advising about scope extent
seems to fall into that category, at least now.  Anyway, I don't see you
fighting to have the compiler analyze whether your code could benefit from
tighter `let' scoping.

And the compiler has no business giving the impression that using
`save-excursion' with `set-buffer' is a no-no.

And it certainly has no business scaring people without conveying any info about
the purported DANGER.

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

It's relevant to any case where you want to restore which buffer is current AND
its point and mark.  That's the use case that you seem to be missing/ignoring.
It seems to be the elephant in the room.

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

`save-current-buffer' does not restore point and mark.  If you want to restore
them as well as which buffer is current, then use `save-excursion'.  That's what
it's for. QED.