window-point oddity

window-point oddity

[Harald Hanche-Olsen]

Something odd has happened to my current running emacs:

Whenever I split a window with C-x 2, I cannot move point in the new
window. Or more precisely, whenever I select the new window then the
cursor jumps to the same position it has in the original window. If I
move it away, by any method whatever (arrow key, mouseclick, elisp
executed from the minibuffer), it jumps back to its original position.
There is always a delay before the point jumps. The delay is of
variable length, but never more than a second.

Unfortunately, I am unable to reproduce this if I start up a different
emacs instance. Hence my question: Could I accidentally have activated
some feature that has this (rather annoying) side effect, or is it
more likely that I have come across an obscure bug? (It goes without
saying that if I figure out how to reproduce it, I will report a bug.)

- Harald

Re: window-point oddity

[Dan Davison]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> Something odd has happened to my current running emacs:
>
> Whenever I split a window with C-x 2, I cannot move point in the new
> window. Or more precisely, whenever I select the new window then the
> cursor jumps to the same position it has in the original window. If I
> move it away, by any method whatever (arrow key, mouseclick, elisp
> executed from the minibuffer), it jumps back to its original position.
> There is always a delay before the point jumps. The delay is of
> variable length, but never more than a second.

Hi Harald,

Are you running recent gnus? If so, does it help to set
gnus-article-update-lapsed-header to a larger value? If it is this bug,
then it has been fixed in current gnus.

Dan

>
> Unfortunately, I am unable to reproduce this if I start up a different
> emacs instance. Hence my question: Could I accidentally have activated
> some feature that has this (rather annoying) side effect, or is it
> more likely that I have come across an obscure bug? (It goes without
> saying that if I figure out how to reproduce it, I will report a bug.)
>
> - Harald

Re: window-point oddity

[Harald Hanche-Olsen]

[Dan Davison <dandavison7@gmail.com> (2011-02-02 23:22:37 UTC)]

> Are you running recent gnus?

Don't know, I compiled emacs from trunk less than a week ago, but
don't track gnus separately. I.e., I use the gnus that comes with the
emacs source.

> If so, does it help to set gnus-article-update-lapsed-header to a
> larger value? If it is this bug, then it has been fixed in current
> gnus.

Didn't make a difference. Neither, in response to another suggestion,
have I run any gdb sessions in this emacs. I am satisfied for now to
know that this is indeed anomalous behaviour, apparently no known code
does anything like it deliberately, yet it's not totally unheard of.

I'll experiment a bit to see if I can manage to repeat it reliably and
post a bug report if I do.

- Harald

Re: window-point oddity

[Harald Hanche-Olsen]

[Harald Hanche-Olsen <hanche@math.ntnu.no> (2011-02-03 06:29:06 UTC)]

> [Dan Davison <dandavison7@gmail.com> (2011-02-02 23:22:37 UTC)]
> 
> > Are you running recent gnus?
> > If so, does it help to set gnus-article-update-lapsed-header to a
> > larger value? If it is this bug, then it has been fixed in current
> > gnus.
> 
> Didn't make a difference.

I take it back. It helps if I set it to a larger value in .emacs.
(It's too late once gnus has been run.) Otherwise, I can reproduce the
problem merely by starting gnus, so this is the bug you mentioned. How
often is the current gnus merged into emacs trunk?

- Harald

Re: window-point oddity

[Michael Welsh Duggan]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> Something odd has happened to my current running emacs:
>
> Whenever I split a window with C-x 2, I cannot move point in the new
> window. Or more precisely, whenever I select the new window then the
> cursor jumps to the same position it has in the original window. If I
> move it away, by any method whatever (arrow key, mouseclick, elisp
> executed from the minibuffer), it jumps back to its original position.
> There is always a delay before the point jumps. The delay is of
> variable length, but never more than a second.
>
> Unfortunately, I am unable to reproduce this if I start up a different
> emacs instance. Hence my question: Could I accidentally have activated
> some feature that has this (rather annoying) side effect, or is it
> more likely that I have come across an obscure bug? (It goes without
> saying that if I figure out how to reproduce it, I will report a bug.)

I saw something like that happen not too long ago during a badly messed
up M-x gdb session.  Killing the *gud* buffer fixed the problem.  If you
weren't running gdb, of course, this would be moot.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: window-point oddity

[Stefan Monnier]

> Unfortunately, I am unable to reproduce this if I start up a different
> emacs instance. Hence my question: Could I accidentally have activated
> some feature that has this (rather annoying) side effect, or is it
> more likely that I have come across an obscure bug? (It goes without
> saying that if I figure out how to reproduce it, I will report a bug.)

You probably activated some code that ended up triggering this
anomalous behavior.  But without more info, it's difficult to guess what
that might be.


        Stefan

Re: window-point oddity

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

 > You probably activated some code that ended up triggering this
 > anomalous behavior.  But without more info, it's difficult to guess what
 > that might be.

With a one-window frame showing a buffer containing at least one
character do M-x foo with the following function:

(defun foo ()
   (interactive)
   (let ((window (split-window)))
     (set-window-point window (point-max)))
   (set-window-point (selected-window) (point-min))
   (save-window-excursion
     (set-window-buffer
      (selected-window) (get-buffer-create "*foo*"))))

It moves the cursor in _both_ windows to `point-max' while it should
remain at `point-min' in the upper window.  This is due to the recent
inhibit point swapping "fix" which fails when the selected window does
not change.  A fix like the attached works here and should be installed
on Emacs 23 before the release.

martin

[-- Attachment #2: window.c.diff --]
[-- Type: text/plain, Size: 461 bytes --]

*** c:/window-old.c	2011-02-08 08:47:28.000000000 +0100
--- c:/window-new.c	2011-02-08 08:48:40.234375000 +0100
***************
*** 3517,3523 ****
        record_buffer (w->buffer);
      }
  
!   if (EQ (window, selected_window))
      return window;
  
    sf = SELECTED_FRAME ();
--- 3517,3523 ----
        record_buffer (w->buffer);
      }
  
!   if (EQ (window, selected_window) && !inhibit_point_swap)
      return window;
  
    sf = SELECTED_FRAME ();

Re: window-point oddity

[Stefan Monnier]

> It moves the cursor in _both_ windows to `point-max' while it should
> remain at `point-min' in the upper window.  This is due to the recent
> inhibit point swapping "fix" which fails when the selected window does
> not change.  A fix like the attached works here and should be installed
> on Emacs 23 before the release.

Please install your patch.
And thanks for tracking this down.


        Stefan

Re: window-point oddity

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> It moves the cursor in _both_ windows to `point-max' while it should
>> remain at `point-min' in the upper window.  This is due to the recent
>> inhibit point swapping "fix" which fails when the selected window does
>> not change.  A fix like the attached works here and should be installed
>> on Emacs 23 before the release.
>
> Please install your patch.
> And thanks for tracking this down.

I've just installed it on the branch.