Subject: bug#12079: 23.3; erroneous byte-compile-file warning

From: Winston <[email-masked]>
Date: Mon, 30 Jul 2012 00:42 EDT

I originally submitted (in part):
>>     (progn
>>       (save-excursion
>>         (set-buffer "foo")      ; I'd already created this
>>         (barf-if-buffer-read-only)
>>         )
>>       (current-buffer)
>>     )
>>     #<buffer *scratch*>
>>
>> 3) However, when I write that code to foo.el and run byte-compile-file
>>    on it, I get the following error:
>>
>>     Compiling file /home/wbe/foo.el at Sat Jul 28 09:07:28 2012
>>     Entering directory `/home/wbe/'
>> --> foo.el:1:1:Warning: `save-excursion' defeated by `set-buffer'
>>
>> It looks to me like the Warning message is untrue.

to which Glenn replied:
> In an example such as you show, you should use with-current-buffer
> instead of save-excursion+set-buffer.

OK.  Back when the code I was compiling was written, with-current-buffer
didn't exist.  After reading the description of with-current-buffer,
yes, it looks like it would be as good or better than save-excursion if
I feel like rewriting the code.

> I think this has been discussed several times on this list and/or
> emacs-devel.

I wouldn't know.  I'm not on that list.

> The compilation warning is because save-excursion is pointless in the
> code as shown.

I disagree.  When the body finishes, save-excursion changes back to the
buffer that was current when it was called.  Perhaps it's useless in a
trivial example like the one above, but "return to whatever the current
buffer is after making changes in some other buffer" can be useful in
subroutines.  Restoring the buffer is certainly not "pointless".

I think what you're trying to say is that using save-excursion instead
of with-current-buffer when the body begins with set-buffer is
"pointless" because save-excursion does nothing more than what
with-current-buffer would do.  That's a fair point, but that's NOT what
the warning message says.  The warning claims that save-excursion won't
work.

> Eg it doesn't preserve point in buffer foo (unless foo happened to be
> current beforehand).

Irrelevant.  You've agreed that save-excursion works exactly as the
documentation claims, restoring on exit the buffer, point, and mark as
of the time it was called, so the clear English meaning of the warning
is false -- no part of save-excursion's functionality was "defeated" by
calling set-buffer.

I recommend the current misleading warning be replaced with a suggestion
that using with-current-buffer would be more efficient, which is
apparently what was intended.
 -WBE