fit-window-to-buffer

fit-window-to-buffer

[Richard M. Stallman]

    The issue is that `fit-window-to-buffer', when called from
    `occur-hook', changes the current buffer. Puzzling. Not a problem now,

That is very strange.  I looked at the code for fit-window-to-buffer
and see nothing that should be able to change the current buffer.
It must be a bug in some C primitive used there.

If the Lisp debugger interferes with the phenomenon,
I suggest trying inserting debugging statements such as

  (setq foo4 (current-buffer)

in the code at various places.  If you put these in the right places
you should be able to narrow down where the clobberage occurs.

My suspicion is on the window-manipulating functions.  Perhaps
save-selected-window fails to restore the current buffer.

Later:

    And very weird. I traced the call, and the buffer changed on return of
    `save-selected-window'. Nothing that I could see seemed like a likely
    cause.

Oho, so it is there.  I have a suspicion about why.  I think
save-selected-window sets the current buffer to the buffer that is
displayed in the newly restored selected window.  If some other buffer
was current before the save-selected-window form, it will have the
effect of changing the current buffer.

Maybe the best solution is to explicitly save the current buffer
like this.  Does this fix the problem?


(defmacro save-selected-window (&rest body)
  "Execute BODY, then select the window that was selected before BODY.
Also restore the selected window of each frame as it was at the start
of this construct.
However, if a window has become dead, don't get an error,
just refrain from reselecting it.
Return the value of the last form in BODY."
  `(let ((save-selected-window-window (selected-window))
	 ;; It is necessary to save all of these, because calling
	 ;; select-window changes frame-selected-window for whatever
	 ;; frame that window is in.
	 (save-selected-window-alist
	  (mapcar (lambda (frame) (list frame (frame-selected-window frame)))
		  (frame-list))))
     (save-current-buffer
       (unwind-protect
	   (progn ,@body)
	 (dolist (elt save-selected-window-alist)
	   (and (frame-live-p (car elt))
		(window-live-p (cadr elt))
		(set-frame-selected-window (car elt) (cadr elt))))
	 (if (window-live-p save-selected-window-window)
	     (select-window save-selected-window-window))))))

Re: fit-window-to-buffer

[Juanma Barranquero]

On 6/24/05, Richard M. Stallman <rms@gnu.org> wrote:

> Maybe the best solution is to explicitly save the current buffer
> like this.  Does this fix the problem?

Yes, it does.

-- 
                    /L/e/k/t/u

with-current-buffer (was: fit-window-to-buffer)

[Juri Linkov]

There is a similar problem related to switching buffers using
`with-current-buffer' and co.  I can't say if it's a bug or not.
For example, `next-error' after finishing has the current 
buffer reported by (current-buffer) not the same as the buffer
where the point eventually lands.  This problem in `next-error'
can be narrowed to the following code:

(progn (get-buffer-create "a")
       (get-buffer-create "b")
       (get-buffer-create "c"))

(defun test ()
  (interactive)
  (set-buffer "a")
  (with-current-buffer "c"
    (pop-to-buffer "b"))
  (message "%s" (buffer-name (current-buffer))))

(test)

At the end, it print "a" as the current buffer name, but actually
this command makes the buffer "b" current.  Shouldn't it print "b"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: with-current-buffer (was: fit-window-to-buffer)

[Miles Bader]

On 6/27/05, Juri Linkov <juri@jurta.org> wrote:
>   (with-current-buffer "c"
>     (pop-to-buffer "b"))
>   (message "%s" (buffer-name (current-buffer))))
> 
> At the end, it print "a" as the current buffer name, but actually
> this command makes the buffer "b" current.  Shouldn't it print "b"?

I think this isn't a bug -- the `with-current-buffer' form of course
restores the current buffer to be "a" after the wrapped code is
finished; why would you expect differently?

As I understand it, what `pop-to-buffer' does is set the window-buffer
of the selected window, in _addition_ to setting the current buffer,
and the main emacs interaction loop always restores the current buffer
to be the window-buffer of the selected window when you look for the
next command.

So in your example, `pop-to-buffer' sets the current buffer and the
window-buffer-of-selected-widnow to be "b", then the
`with-current-buffer' form (correctly) restores the current buffer to
be "a" again, then you print your message [which says "current buffer
is a"], then the interaction loop goes to read a command, which sets
the current buffer based on the window state -- which is "b", because
of pop-to-buffer's effect.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: with-current-buffer (was: fit-window-to-buffer)

[Richard M. Stallman]

    (defun test ()
      (interactive)
      (set-buffer "a")
      (with-current-buffer "c"
	(pop-to-buffer "b"))
      (message "%s" (buffer-name (current-buffer))))

    (test)

    At the end, it print "a" as the current buffer name, but actually
    this command makes the buffer "b" current.  Shouldn't it print "b"?

with-current-buffer is supposed to restore the previous current buffer.
That is buffer a.

This command does not make buffer b current.  However, the main loop
does that, because b is the selected window's buffer.

The results are correct; I see no bug here.

Re: with-current-buffer

[Juri Linkov]

>>   (with-current-buffer "c"
>>     (pop-to-buffer "b"))
>>   (message "%s" (buffer-name (current-buffer))))
>> 
>> At the end, it print "a" as the current buffer name, but actually
>> this command makes the buffer "b" current.  Shouldn't it print "b"?
>
> I think this isn't a bug -- the `with-current-buffer' form of course
> restores the current buffer to be "a" after the wrapped code is
> finished; why would you expect differently?
>
> As I understand it, what `pop-to-buffer' does is set the window-buffer
> of the selected window, in _addition_ to setting the current buffer,
> and the main emacs interaction loop always restores the current buffer
> to be the window-buffer of the selected window when you look for the
> next command.
>
> So in your example, `pop-to-buffer' sets the current buffer and the
> window-buffer-of-selected-widnow to be "b", then the
> `with-current-buffer' form (correctly) restores the current buffer to
> be "a" again, then you print your message [which says "current buffer
> is a"], then the interaction loop goes to read a command, which sets
> the current buffer based on the window state -- which is "b", because
> of pop-to-buffer's effect.

What causes trouble here is the fact that Emacs changes the current
buffer behind the scenes (somewhere in the main loop), so at the end
of the function it is not known what the buffer will be current after
the function finishes.  But sometimes it is desirable to perform some
actions on that buffer (e.g. run hooks).

Maybe with-current-buffer should keep track of switching buffers
inside with-current-buffer, so it could anticipate what a buffer will
be set as current and don't restore the old buffer.

Or maybe `pop-to-buffer inside with-current-buffer' is not a suitable
programming construct (I mean mostly for the `next-error' command
where this problem occurred) and it's better to replace it with more
explicit buffer switching that will restore the old buffer only when
there were no `pop-to-buffer' calls.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: with-current-buffer

[Kevin Rodgers]

Juri Linkov wrote:
 > What causes trouble here is the fact that Emacs changes the current
 > buffer behind the scenes (somewhere in the main loop), so at the end
 > of the function it is not known what the buffer will be current after
 > the function finishes.  But sometimes it is desirable to perform some
 > actions on that buffer (e.g. run hooks).

But you also changed the selected window.  That is the cause of the
trouble.

 > Maybe with-current-buffer should keep track of switching buffers
 > inside with-current-buffer, so it could anticipate what a buffer will
 > be set as current and don't restore the old buffer.
 >
 > Or maybe `pop-to-buffer inside with-current-buffer' is not a suitable
 > programming construct (I mean mostly for the `next-error' command
 > where this problem occurred) and it's better to replace it with more
 > explicit buffer switching that will restore the old buffer only when
 > there were no `pop-to-buffer' calls.

In the old days we'd use save-window-excursion; now there is
save-selected-window.

Should there be a with-selected-window macro, analogous to
with-current-buffer?

-- 
Kevin Rodgers

Re: with-current-buffer

[Richard M. Stallman]

    What causes trouble here is the fact that Emacs changes the current
    buffer behind the scenes (somewhere in the main loop), so at the end
    of the function it is not known what the buffer will be current after
    the function finishes.  But sometimes it is desirable to perform some
    actions on that buffer (e.g. run hooks).

I don't understand what you mean by "trouble"--the scenario is not
clearly specified.  It is a basic feature that the main loop sets the
current buffer.  It is a basic feature that with-current-buffer
preserves the current buffer.

    Maybe with-current-buffer should keep track of switching buffers
    inside with-current-buffer, so it could anticipate what a buffer will
    be set as current and don't restore the old buffer.

Certainly not.  with-current-buffer must do its job reliably.

    Or maybe `pop-to-buffer inside with-current-buffer' is not a suitable
    programming construct (I mean mostly for the `next-error' command
    where this problem occurred) 

There is nothing wrong with it in principle, no reason why it should
in general be avoided.  It might not be the right thing for the
specific place you have in mind.

next-error-hook (was: with-current-buffer)

[Juri Linkov]

>     Or maybe `pop-to-buffer inside with-current-buffer' is not a suitable
>     programming construct (I mean mostly for the `next-error' command
>     where this problem occurred) 
>
> There is nothing wrong with it in principle, no reason why it should
> in general be avoided.  It might not be the right thing for the
> specific place you have in mind.

The place I have in mind is `next-error'.  Currently there is no
reliable way to perform some actions on the source file visited
by `next-error'.  Perhaps there is nothing wrong with constructs
used in `next-error', but what is missing only a hook which would
allow users to run hook functions on the visited source file.
So I propose the following patch:

Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.734
diff -c -r1.734 simple.el
*** lisp/simple.el	24 Jun 2005 21:11:58 -0000	1.734
--- lisp/simple.el	29 Jun 2005 01:49:27 -0000
***************
*** 110,115 ****
--- 110,120 ----
    :group 'next-error
    :version "22.1")
  
+ (defcustom next-error-hook nil
+   "*List of hook functions run by `next-error' after visiting source file."
+   :type 'hook
+   :group 'next-error)
+ 
  (defvar next-error-highlight-timer nil)
  
  (defvar next-error-overlay-arrow-position nil)
***************
*** 240,248 ****
  \\[next-error] in that buffer when it is the only one displayed
  in the current frame.
  
! Once \\[next-error] has chosen the buffer for error messages,
! it stays with that buffer until you use it in some other buffer which
! uses Compilation mode or Compilation Minor mode.
  
  See variables `compilation-parse-errors-function' and
  \`compilation-error-regexp-alist' for customization ideas."
--- 245,254 ----
  \\[next-error] in that buffer when it is the only one displayed
  in the current frame.
  
! Once \\[next-error] has chosen the buffer for error messages, it
! runs `next-error-hook' with `run-hooks', and stays with that buffer
! until you use it in some other buffer which uses Compilation mode
! or Compilation Minor mode.
  
  See variables `compilation-parse-errors-function' and
  \`compilation-error-regexp-alist' for customization ideas."
***************
*** 251,257 ****
    (when (setq next-error-last-buffer (next-error-find-buffer))
      ;; we know here that next-error-function is a valid symbol we can funcall
      (with-current-buffer next-error-last-buffer
!       (funcall next-error-function (prefix-numeric-value arg) reset))))
  
  (defalias 'goto-next-locus 'next-error)
  (defalias 'next-match 'next-error)
--- 257,264 ----
    (when (setq next-error-last-buffer (next-error-find-buffer))
      ;; we know here that next-error-function is a valid symbol we can funcall
      (with-current-buffer next-error-last-buffer
!       (funcall next-error-function (prefix-numeric-value arg) reset)
!       (run-hooks 'next-error-hook))))
  
  (defalias 'goto-next-locus 'next-error)
  (defalias 'next-match 'next-error)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: with-current-buffer

[Stefan Monnier]

> Should there be a with-selected-window macro, analogous to
> with-current-buffer?

Ever tried C-h f ?


        Stefan

Re: with-current-buffer

[Kevin Rodgers]

Stefan Monnier wrote:
>>Should there be a with-selected-window macro, analogous to
>>with-current-buffer?
> 
> Ever tried C-h f ?

Not in Emacs 22.

-- 
Kevin

with-current-buffer

[Emilio Lopes]

Start Emacs (latest CVS on GNU/Linux) with

   ./src/emacs --no-init-file --no-site-file

Display a buffer, let's say "FOO", with some content.  Move point to
its beginning.

Insert the following code in the "*scratch*" buffer:

   (with-current-buffer "FOO"
     (goto-char (point-max))
     (insert "bar"))

Now execute the code above in these two different situations:

   1- The buffer "FOO" is visible along with the "*scratch*" buffer.

   2- The buffer "FOO" is not visible.

In both cases the insertion is done at the right spot, but in case 1
point in buffer "FOO" is restored after the code is executed.

Is that intended behavior?

I expected the point to be moved permanently in both cases.

Re: with-current-buffer

[Stefan Monnier]

> In both cases the insertion is done at the right spot, but in case 1
> point in buffer "FOO" is restored after the code is executed.

> Is that intended behavior?

> I expected point to be moved permanently in both cases.

Which point?


        Stefan

Re: with-current-buffer

[Emilio Lopes]

Stefan Monnier writes:

>> In both cases the insertion is done at the right spot, but in case
>> 1 point in buffer "FOO" is restored after the code is executed.

>> Is that intended behavior?

>> I expected point to be moved permanently in both cases.

> Which point?

The point in buffer "FOO", of course.  I expected the point to stay at
point max after `with-current-buffer' exits.  In the case 1 explained
in the original message the code behaves as if it were wrapped with
`save-excursion'.

Can you reproduce it?

Re: with-current-buffer

[Luc Teirlinck]

Emilio Lopes wrote:

   Display a buffer, let's say "FOO", with some content.  Move point to
   its beginning.

   Insert the following code in the "*scratch*" buffer:

      (with-current-buffer "FOO"
	(goto-char (point-max))
	(insert "bar"))

   Now execute the code above in these two different situations:

      1- The buffer "FOO" is visible along with the "*scratch*" buffer.

      2- The buffer "FOO" is not visible.

   In both cases the insertion is done at the right spot, but in case 1
   point in buffer "FOO" is restored after the code is executed.

Point in the buffer is not restored in either case.  Just execute:
(with-current-buffer "FOO" (point)) immediately afterwards.  You will
see that point _in the buffer_ really is where you expect it to be.

But each window that displays the buffer has its own value of point.
That value would not be restored either, if you would change it.  But
your code never changes it.  You should use set-window-point, if that
is what you want to do,

   Is that intended behavior?

I definitely believe that it is intended.

Sincerely,

Luc.

Re: with-current-buffer

[Stefan Monnier]

>>> In both cases the insertion is done at the right spot, but in case
>>> 1 point in buffer "FOO" is restored after the code is executed.

>>> Is that intended behavior?

>>> I expected point to be moved permanently in both cases.

>> Which point?

> The point in buffer "FOO", of course.

If foo is displayed in a window, it has 2 points: its own and the one of
the window.

> I expected the point to stay at point max after `with-current-buffer' exits.

It does stay there.  Try

   (progn
     (with-current-buffer "FOO"
       (goto-char (point-max))
       (insert "bar"))
     (with-current-buffer "FOO"
       (point)))

> In the case 1 explained in the original message the code behaves as if it
> were wrapped with `save-excursion'.

No, it's just that the window's point gets copied to the buffer's point,
probably during redisplay.

> Can you reproduce it?

Of course,


        Stefan

Re: with-current-buffer

[Emilio Lopes]

Stefan Monnier writes:

> If foo is displayed in a window, it has 2 points: its own and the
> one of the window.

My first thought was to ask if this is a new feature.  It isn't.

It's just plain embarrassing that one can work more than ten years
with an editor without ever noting something as fundamental as this.

Thanks to you and Luc for enlightening me.

-- 
Emílio C. Lopes
Munich, Germany