window configuration bug

window configuration bug

[John H Palmieri]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.2 (alphaev5-dec-osf5.1, X toolkit)
 of 2002-04-03 on goedel1.math.washington.edu
configured using `configure  --prefix=/scratch/palmieri'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


I start Emacs with 'emacs -q'.  I define this function (by typing it
into the *scratch* buffer and hitting C-j):

(defun test ()
  (interactive)
  (let ((config (current-window-configuration)))
    (insert "hello")
    (set-window-configuration config)))

I type 'M-x test', and "hello" gets inserted into the buffer, with the
point after the "o".  Good.

I type 'C-x 2 M-x test', and "hello" gets inserted into the buffer,
with the point at the "h".  Bad: the documentation for
current-window-configuration says

   An exception is made for point in the current buffer:
   its value is -not- saved.

I interpret this to mean that the function set-window-configuration
should not alter the point.  It does, and that's a bug.

It's almost as if, even though the point in the current buffer is not
saved, the point in the other window (which contains the same buffer)
*is* saved, and this is messing up the position of the point.
However, the value of the variable split-window-keep-point appears to
be irrelevant: toggling this variable, hitting C-x 2, and running
'M-x test' still causes the misplaced point.  Hitting C-x 2 and
switching between the windows, (in case one of them is viewed as the
"current buffer" and the other is something else in which the point
deserves to be saved) still results in the misplaced point.

-- 
J. H. Palmieri
Dept of Mathematics, Box 354350    mailto:palmieri@math.washington.edu
University of Washington           http://www.math.washington.edu/~palmieri/
Seattle, WA 98195-4350

Re: window configuration bug

[Richard Stallman]

    It's almost as if, even though the point in the current buffer is not
    saved, the point in the other window (which contains the same buffer)
    *is* saved, and this is messing up the position of the point.

Yes, the position of point in other windows is supposed to be saved.
There is a special exception for point in the current buffer--that is not
supposed to be saved or restored.

It looks like the bug is that point in the current buffer IS being
restored.

Please try this patch:


*** window.c.~1.415.~	Sun May 26 14:30:50 2002
--- window.c	Thu May 30 11:58:23 2002
***************
*** 5105,5112 ****
  			       p->mark, w->buffer);
  
  		  /* As documented in Fcurrent_window_configuration, don't
! 		     save the location of point in the buffer which was current
! 		     when the window configuration was recorded.  */
  		  if (!EQ (p->buffer, new_current_buffer)
  		      && XBUFFER (p->buffer) == current_buffer)
  		    Fgoto_char (w->pointm);
--- 5105,5112 ----
  			       p->mark, w->buffer);
  
  		  /* As documented in Fcurrent_window_configuration, don't
! 		     restore the location of point in the buffer which was
! 		     current when the window configuration was recorded.  */
  		  if (!EQ (p->buffer, new_current_buffer)
  		      && XBUFFER (p->buffer) == current_buffer)
  		    Fgoto_char (w->pointm);
***************
*** 5144,5149 ****
--- 5144,5154 ----
  	 That swapping out has already been done,
  	 near the beginning of this function.  */
        selected_window = Qnil;
+       if (EQ (XWINDOW (data->current_window)->buffer, new_current_buffer))
+ 	set_marker_restricted (XWINDOW (data->current_window)->pointm,
+ 			       make_number (BUF_PT (XBUFFER (XWINDOW (data->current_window)->buffer))),
+ 			       XWINDOW (data->current_window)->buffer);
+ 		  
        Fselect_window (data->current_window);
        XBUFFER (XWINDOW (selected_window)->buffer)->last_selected_window
  	= selected_window;
***************
*** 5190,5199 ****
--- 5195,5206 ----
  	    ++n;
  	}
  
+ #if 0
        /* If more than one window shows the new and old current buffer,
  	 don't try to preserve point in that buffer.  */
        if (old_point > 0 && n > 1)
  	old_point = -1;
+ #endif
        
        adjust_glyphs (f);
  
***************
*** 5216,5226 ****
--- 5223,5235 ----
      {
        Fset_buffer (new_current_buffer);
  
+ #if 0
        /* If the buffer that is current now is the same
  	 that was current before setting the window configuration,
  	 don't alter its PT.  */
        if (old_point >= 0)
  	SET_PT (old_point);
+ #endif
      }
  
    /* Restore the minimum heights recorded in the configuration.  */

Re: window configuration bug

[John H Palmieri]

[I forgot to forward my reply to bug-gnu-emacs@gnu.org, in addition to
rms.]


Your patch fixes my problem, but introduces another one: 

(defun test ()
  (interactive)
  (let ((config (current-window-configuration)))
    (insert "hello")
    (set-window-configuration config)))

Hit 'C-x 2', then 'M-x test', and "hello" gets inserted, with the
point after the "o".  This is a fix of the bug I reported.

However, hit 'C-x 2 C-x o', so that I'm in the second window associated
to this buffer.  Move the point around and do 'M-x test': "hello" gets
inserted, but it gets inserted in the wrong place: not at the current
point, but instead at the point in the first buffer.  It appears that
the point is getting repositioned before the function is executed:
if I do 'M-x debug-on-entry test' in this situation, move the point
around and run 'M-x test', then as soon as the backtrace buffer
appears, the point has been moved.  In fact, if I do lots of things,
the point in the second buffer gets changed to the point in the first
buffer.  For example, if I type 'M-x debug-on-entry', then by the time
the prompt "Debug on entry (to function):" appears, the point has been
moved.

    
Richard Stallman <rms@gnu.org> writes:

> Yes, the position of point in other windows is supposed to be saved.
> There is a special exception for point in the current buffer--that is not
> supposed to be saved or restored.
>
> It looks like the bug is that point in the current buffer IS being
> restored.
>
> Please try this patch:
>
>
> *** window.c.~1.415.~	Sun May 26 14:30:50 2002
> --- window.c	Thu May 30 11:58:23 2002

-- 
J. H. Palmieri
Dept of Mathematics, Box 354350    mailto:palmieri@math.washington.edu
University of Washington           http://www.math.washington.edu/~palmieri/
Seattle, WA 98195-4350