unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-18 11:21 Marshall, Simon
  2006-07-19  9:56 ` martin rudalics
  0 siblings, 1 reply; 17+ messages in thread
From: Marshall, Simon @ 2006-07-18 11:21 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

Hi Martin, I occasionally get this (taken from *Messages*):

mouse-autoselect-window-start: Wrong type argument: numberp, nil

I just caught it with debug-on-error, though I'm not sure quite how to read
it as it looks like 2 errors have occurred.  The way I read it, we are in
the process of switching to the *Backtrace* window when the error
(presumably) happened again:

Debugger entered--Lisp error: (wrong-type-argument numberp nil)
  window-at(nil nil #<frame test2/CONTRACT.in 0xd1a200>)
  mouse-autoselect-window-start()
  handle-select-window((select-window (#<window 47 on *Backtrace*>)))
  call-interactively(handle-select-window)

But it is kind-of what I guessed, that the error is thrown by window-at
because mouse-position returns nil for X and Y.

I can fairly easily reproduce this with emacs -Q if I move from the selected
first frame to a second frame and then off that second frame quickly when
(a) the second frame has split windows, (b) the second frame's selected
window (ie, when the second frame is selected) and its point is covered by
the first frame.

The amount of time spent in the second frame does not seem to depend on
mouse-autoselect-window.  Maybe it has more to do with whether Emacs gets
the chance to get some info out of X before the mouse has moved off the
second frame.  I use Solaris CDE on a PC running Exceed, which may
complicate/slow things.

Maybe the only fix is to be tolerant of nil for X and Y from mouse-position.

Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-19 11:14 Marshall, Simon
  0 siblings, 0 replies; 17+ messages in thread
From: Marshall, Simon @ 2006-07-19 11:14 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

>  > The amount of time spent in the second frame does not seem to depend on
>  > mouse-autoselect-window.
> 
> I suppose you tell that from using an autoselect timeout in 
> your window
> manager that differs from `mouse-autoselect-window'.

FWIW, I probably wasn't clear - I meant the amount of time spent in the
second frame _to trigger the bug_ does not seem to depend on
mouse-autoselect-window, ie, its not anything to do with the autoselect
window functionality itself.

>  > Maybe the only fix is to be tolerant of nil for X and Y from
mouse-position.
> 
> The only thing I can offer is to wrap this in a `condition-case' and
> have `handle-select-window' do it's usual stuff when
> `mouse-autoselect-window-start' fails.

Thanks, I'll let you know if I see any other problems.  Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-17 16:18 Marshall, Simon
  2006-07-17 17:59 ` martin rudalics
  2006-07-18 13:37 ` Richard Stallman
  0 siblings, 2 replies; 17+ messages in thread
From: Marshall, Simon @ 2006-07-17 16:18 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

> In `mouse-autoselect-window-start' please replace
> 
>    (run-at-time t delay 'mouse-autoselect-window-select))
> 
> by
> 
>    (run-at-time delay delay 'mouse-autoselect-window-select))

Duh, I noticed that but didn't realise it was the cause.

> There is one reference, namely
> 
>    "Check mouse quiescence in timer-driven window selection."
> 
> Is
> 
>    "Check mouse quiescence in delayed autoselection of windows."
> 
> better?

Yes, that's what I meant, though "delayed window autoselection" might be
cleaner.

I guess rms might want to cast his eyes over the doc strings anyway.  I
would be puzzled by the min value of 0.1s for mouse-autoselect-window - it's
arbitrary.  Is it really necessary to impose any limit?

Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-17 14:07 Marshall, Simon
  2006-07-17 15:52 ` martin rudalics
  0 siblings, 1 reply; 17+ messages in thread
From: Marshall, Simon @ 2006-07-17 14:07 UTC (permalink / raw)
  Cc: 'cyd@stupidchicken.com', 'rms@gnu.org',
	'emacs-devel@gnu.org'

> OK, I moved everything back to mouse.el and added a 
> customizable variable `mouse-autoselect-quiescent'.  Using a 
> number as value for that variable checks whether movement was 
> restricted to that many chars around the last position.  This 
> leaves future users a number of choices.

Thanks.  I've only just had a chance to start playing with it, I'll let you
know if there's any problem with it.

I do see switches happening before mouse-autoselect-window has elapsed, but
I haven't figured out why.  It looks as if the timer is just triggered
early.

I would remove references to "timer" in the doc string of
mouse-autoselect-quiescent, since it refers to an implementation detail not
a feature.  That terminology is not used by mouse-autoselect-window.

Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-06 11:43 Marshall, Simon
  2006-07-07  9:35 ` martin rudalics
  0 siblings, 1 reply; 17+ messages in thread
From: Marshall, Simon @ 2006-07-06 11:43 UTC (permalink / raw)
  Cc: 'cyd@stupidchicken.com', 'rms@gnu.org',
	'emacs-devel@gnu.org'

> Please try the attached patch - it's based on Stefan's 
> suggestion to use `handle-select-window'.  martin.

Hi Martin, thanks, I can play with the lisp now.

One problem I see with this implementation is that it also waits for twice
the delay.  The reason can be seen in the sequence of events when the mouse
is moved to a new window:

- handle-select-window calls autoselect-window-start.

- autoselect-window-start sets autoselect-window-position to
(mouse-position).  However, this position appears to be the position
*before* the mouse movement.

- autoselect-window-start starts a timer to run autoselect-window-select
after the specified delay.

- when autoselect-window-select runs after the first timeout, it checks to
see if autoselect-window-position is equal to (mouse-position), which cannot
be true even if the mouse has not moved again.  So, window selection does
not occur, and it just sets autoselect-window-position to (mouse-position).

- when autoselect-window-select runs after the second timeout, and the mouse
has not moved, autoselect-window-position is equal to (mouse-position) and
window selection occurs.

To be honest, I'd be quite happy with the feature if it did not try to
detect for a quiescent mouse as it would still be a big improvement.  In
that case I guess the implementation would not need to use (mouse-position)
and the above problem would not occur.

If it could be made to work, it would be a bonus (though perhaps should be
an additional option, i.e., delay or delay with quiescence).  Of course, one
simple hack/workaround would be to use (/ mouse-autoselect-window 2.0) for
the timer delay, though I'd be interested to see why mouse-position returns
what it does.

Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]
@ 2006-07-04 16:17 Marshall, Simon
  2006-07-05  8:26 ` martin rudalics
  2006-07-05 12:19 ` martin rudalics
  0 siblings, 2 replies; 17+ messages in thread
From: Marshall, Simon @ 2006-07-04 16:17 UTC (permalink / raw)
  Cc: 'cyd@stupidchicken.com', 'emacs-devel@gnu.org'

> The attached patch is a first approximation.  I've been able 
> to test this on Windows 98 only, hence I would be glad to 
> hear if this works in a general context too - simply 
> customize the variable `mouse-autoselect-window'.

Hi Martin, thanks, when it works it certainly is an improvement.  A few
comments though, with a Solaris 8 build with LUCID toolbars.

- A value of nil for mouse-autoselect-window doesn't seem to stop it
selecting!  I think the xterm.c check should be for
!NILP(mouse_autoselect_window) now.

- When I tried to see how the lisp functions mouse-autoselect-window-cancel,
mouse-autoselect-window-start and mouse-autoselect-window-select were called
(by adding message forms to them), I got an instant abort() when
handle_one_xevent() called mouse_autoselect_window_function (bound to
mouse-autoselect-window-start) and something called an Feval():

  [5] abort(), line 464 in "emacs.c"
  [6] Feval(form = 1619100224), line 2127 in "eval.c"
  [7] Fprogn(args = -1598899992), line 434 in "eval.c"
  [8] funcall_lambda(fun = -1598900616, nargs = 2, arg_vector = 0xffbec1f8),
line 3084 in "eval.c"
  [9] Ffuncall(nargs = 3, args = 0xffbec1f4), line 2959 in "eval.c"
  [10] call2(fn = 544825944, arg1 = -2138684416, arg2 = -2138684416), line
2711 in "eval.c"
=>[11] handle_one_xevent(dpyinfo = 0x83ae00, eventp = 0xffbec8a0, finish =
0xffbec894, hold_quit = 0xffbed970), line 6591 in "xterm.c"

In fact, setting mouse-autoselect-window to a number, doing ESC C-x on the
defun of mouse-autoselect-window-cancel or mouse-autoselect-window-start,
and moving the mouse is enough to trigger this abort even with one window.

- I think the uncertainty over the actual delay is more than a little odd.
It is more than frustrating to have to wait perhaps twice the amount of time
(in fact the doc string says the amount of time is any multiple of
mouse-autoselect-window).  Perhaps the problem is that
mouse_autoselect_window_function is run even if the window has not changed?
(Currently it is run if mouse_autoselect_window is a number, regardless of
whether the window has changed or not.)  If it were only to run if the
window has changed, perhaps mouse-autoselect-window-start can set
mouse-autoselect-window-position to (mouse-position)?

Unfortunately, it's a little difficult for me to play around with the lisp
code - I can only avoid an abort by make/make recompile/make each time.

If you can work out how to make it stable I can help test etc.  Simon.

^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2006-08-28  5:57 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-18 11:21 [simon.marshall@misys.com: mouse-autoselect-window needs a de lay] Marshall, Simon
2006-07-19  9:56 ` martin rudalics
2006-07-19 11:00   ` Kim F. Storm
2006-07-19 12:35     ` martin rudalics
  -- strict thread matches above, loose matches on Subject: below --
2006-07-19 11:14 Marshall, Simon
2006-07-17 16:18 Marshall, Simon
2006-07-17 17:59 ` martin rudalics
2006-07-18 13:37 ` Richard Stallman
2006-07-19 10:05   ` martin rudalics
2006-08-28  5:57   ` martin rudalics
2006-07-17 14:07 Marshall, Simon
2006-07-17 15:52 ` martin rudalics
2006-07-06 11:43 Marshall, Simon
2006-07-07  9:35 ` martin rudalics
2006-07-04 16:17 Marshall, Simon
2006-07-05  8:26 ` martin rudalics
2006-07-05 12:19 ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).