save-current-buffer

save-current-buffer

[Andreas Politz]

Is this a bug, or am I missing something ?
Eval this in *scratch* buffer and you end up in the *Help* one.

(save-current-buffer
   (switch-to-buffer "*Help*"))


GNU Emacs 22.2.1


-ap

Re: save-current-buffer

[B. T. Raven]

Andreas Politz wrote:
> 
> 
> Is this a bug, or am I missing something ?
> Eval this in *scratch* buffer and you end up in the *Help* one.
> 
> (save-current-buffer
>   (switch-to-buffer "*Help*"))
> 
> 
> GNU Emacs 22.2.1
> 
> 
> -ap

That's what you would expect. If you don't have an Emacs generated 
read-only *Help* buffer open then you will create an editable one with 
that name. Why does it seem like a bug? Of course the file *Help* can't 
be saved because the file name is illegal.

Ed

Re: save-current-buffer

[Chris F.A. Johnson]

On 2008-10-18, B. T. Raven wrote:
> Andreas Politz wrote:
>> 
>> 
>> Is this a bug, or am I missing something ?
>> Eval this in *scratch* buffer and you end up in the *Help* one.
>> 
>> (save-current-buffer
>>   (switch-to-buffer "*Help*"))
>> 
>> 
>> GNU Emacs 22.2.1
>> 
>> 
>> -ap
>
> That's what you would expect. If you don't have an Emacs generated 
> read-only *Help* buffer open then you will create an editable one with 
> that name. Why does it seem like a bug? Of course the file *Help* can't 
> be saved because the file name is illegal.

   It is? That's news to me. In fact, I just created a buffer named
   *Help* and saved it.

-- 
   Chris F.A. Johnson, webmaster         <http://Woodbine-Gerrard.com>
   ===================================================================
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: save-current-buffer

[B. T. Raven]

Chris F.A. Johnson wrote:
> On 2008-10-18, B. T. Raven wrote:
>> Andreas Politz wrote:
>>>
>>> Is this a bug, or am I missing something ?
>>> Eval this in *scratch* buffer and you end up in the *Help* one.
>>>
>>> (save-current-buffer
>>>   (switch-to-buffer "*Help*"))
>>>
>>>
>>> GNU Emacs 22.2.1
>>>
>>>
>>> -ap
>> That's what you would expect. If you don't have an Emacs generated 
>> read-only *Help* buffer open then you will create an editable one with 
>> that name. Why does it seem like a bug? Of course the file *Help* can't 
>> be saved because the file name is illegal.
> 
>    It is? That's news to me. In fact, I just created a buffer named
>    *Help* and saved it.
> 

Using metacharacters in file names even in Gnu/Linux is deprecated. In 
MS OSes it's impossible, I think. At least it won't save *Help* on msw 
2000. I assumed (wrongly) that save-current-buffer saved the buffer to a 
file and that the argument could make some other buffer current first. 
If that were true then switch-to-buffer would be evaluated before 
save-current-buffer. Apparently the argument is instead an implied 
progn. What form this argument takes I don't know. Maybe a list.

Ed

Re: save-current-buffer

[Glauber Alex Dias Prado]

save-current-buffer is a special form in `C source code'.
(save-current-buffer &rest body)

Save the current buffer; execute body; restore the current buffer.
Executes body just like `progn'.

strange indeed,dunno why it works this way.

"B. T. Raven" <nihil@nihilo.net> writes:

> Andreas Politz wrote:
>>
>>
>> Is this a bug, or am I missing something ?
>> Eval this in *scratch* buffer and you end up in the *Help* one.
>>
>> (save-current-buffer
>>   (switch-to-buffer "*Help*"))
>>
>>
>> GNU Emacs 22.2.1
>>
>>
>> -ap
>
> That's what you would expect. If you don't have an Emacs generated
> read-only *Help* buffer open then you will create an editable one with
> that name. Why does it seem like a bug? Of course the file *Help*
> can't be saved because the file name is illegal.
>
> Ed

Re: save-current-buffer

[Andreas Politz]

Glauber Alex Dias Prado wrote:
> save-current-buffer is a special form in `C source code'.
> (save-current-buffer &rest body)
> 
> Save the current buffer; execute body; restore the current buffer.
> Executes body just like `progn'.
> 
> strange indeed,dunno why it works this way.
> 
> "B. T. Raven" <nihil@nihilo.net> writes:
> 
>> Andreas Politz wrote:
>>>
>>> Is this a bug, or am I missing something ?
>>> Eval this in *scratch* buffer and you end up in the *Help* one.
>>>
>>> (save-current-buffer
>>>   (switch-to-buffer "*Help*"))
>>>
>>>
>>> GNU Emacs 22.2.1
>>>
>>>
>>> -ap

What would make sense is if `current buffer' refers to whatever (current-buffer) returns,
and switch-to-buffer changes that.   ?

-ap

Re: save-current-buffer

[Nikolaj Schumacher]

Andreas Politz <politza@fh-trier.de> wrote:

> Is this a bug, or am I missing something ?
> Eval this in *scratch* buffer and you end up in the *Help* one.
>
> (save-current-buffer
>   (switch-to-buffer "*Help*"))

There is a subtle difference between the current-buffer and the window's
buffer.  Any buffer can be current without being displayed.  The
function for that is `set-buffer'.

`switch-to-buffer' changes both the current-buffer and the selected window's
buffer.

(progn
  (message "%s/%s" (current-buffer) (window-buffer (selected-window)))
  (save-current-buffer
    (switch-to-buffer "*Help*")
    (message "%s/%s" (current-buffer) (window-buffer (selected-window))))
  (message "%s/%s" (current-buffer) (window-buffer (selected-window))))

will output:

*scratch*/*scratch*
*Help*/*Help*
*scratch*/*Help*

As you can see, current-buffer is restored, but the window's
buffer is not.

Replacing `save-current-buffer' with `save-window-excursion'

gets you:

*scratch*/*scratch*
*Help*/*Help*
*scratch*/*scratch*


But generally, `switch-to-buffer' should only be used when the user
wants to see the new buffer.  Otherwise `set-buffer' is the better choice.



regards,
Nikolaj Schumacher

Re: save-current-buffer

[Andreas Politz]

Nikolaj Schumacher wrote:
> Andreas Politz <politza@fh-trier.de> wrote:
> 
>> Is this a bug, or am I missing something ?
>> Eval this in *scratch* buffer and you end up in the *Help* one.
>>
>> (save-current-buffer
>>   (switch-to-buffer "*Help*"))
> 
> There is a subtle difference between the current-buffer and the window's
> buffer.  Any buffer can be current without being displayed.  The
> function for that is `set-buffer'.
> 
> `switch-to-buffer' changes both the current-buffer and the selected window's
> buffer.
> 
> (progn
>   (message "%s/%s" (current-buffer) (window-buffer (selected-window)))
>   (save-current-buffer
>     (switch-to-buffer "*Help*")
>     (message "%s/%s" (current-buffer) (window-buffer (selected-window))))
>   (message "%s/%s" (current-buffer) (window-buffer (selected-window))))
> 
> will output:
> 
> *scratch*/*scratch*
> *Help*/*Help*
> *scratch*/*Help*
> 
> As you can see, current-buffer is restored, but the window's
> buffer is not.
> 
> Replacing `save-current-buffer' with `save-window-excursion'
> 
> gets you:
> 
> *scratch*/*scratch*
> *Help*/*Help*
> *scratch*/*scratch*
> 
> 
> But generally, `switch-to-buffer' should only be used when the user
> wants to see the new buffer.  Otherwise `set-buffer' is the better choice.
> 
> 
> 
> regards,
> Nikolaj Schumacher
> 
> 

I see. I assume after the form is evaluated, some event will set the current-buffer
to the one switch-to-buffer switched to.

The reason I was asking is some problem I had with the recentf package. It's
really a minor one, but I was just curious what to make of it and how things are working.
The idiom from above is used in one of it's functions.

(require 'recentf)
(run-with-timer 0 nil 'recentf-open-files)

Now pressing 'q' gives a read-only error, though it is
bound to recentf-cancel-dialog. Pressing it twice works fine.

-ap

Re: save-current-buffer

[Nikolaj Schumacher]

Andreas Politz <politza@fh-trier.de> wrote:

> I see. I assume after the form is evaluated, some event will set the
> current-buffer to the one switch-to-buffer switched to.

I assume it's the other way round:  When calling a command the current
buffer is set according to the selected window.  But the results are the
same.

> (require 'recentf)
> (run-with-timer 0 nil 'recentf-open-files)
>
> Now pressing 'q' gives a read-only error, though it is
> bound to recentf-cancel-dialog. Pressing it twice works fine.

I'll wager that this is an Emacs bug.

From the Emacs TODO file:

** Compute the list of active keymaps *after* reading the first event.


I hope that I just saved you some headaches... Good thing you were
talking to me.  I reported this bug. :)

regards,
Nikolaj Schumacher