[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: mouse-autoselect-window needs a de lay]
From: |
martin rudalics |
Subject: |
Re: address@hidden: mouse-autoselect-window needs a de lay] |
Date: |
Wed, 05 Jul 2006 10:26:35 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Hi Simon, thanks for testing this.
> - 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.
Correct. It should have been done as in w32term.
> 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 don't get an abort but I'm 100% busy when edebugging this. Hardly an
improvement.
> - 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)?
That was my initial approach and it worked pretty well. But (re-)read
my previous observation with respect to this:
>> 1. Suppose I have two windows - SW is the selected one and UW the
>> unselected one. I move the mouse to the menubar as described in Simon's
>> original scenario. UW should not be selected here. However, I then
>> change my mind and move the mouse to UW. I suppose that UW should be
>> selected now - agreed? (It's important to clear this since the current
>> autoselect mechanism triggers iff the mouse moves from the selected
>> window to an unselected one.)
With other words, once I leave a window with the mouse and move to the
menubar, I won't autselect another window before I cross a window border
again. I was afraid that some people would find this counterintuitive.
> 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.
Probably, doing this in `handle-select-window' is more practical indeed.
(In case of doubt, Stefan's always right.) Anyway, I'll try to find a
more practicable solution. Thanks again for the report. martin.
- RE: address@hidden: mouse-autoselect-window needs a de lay], Marshall, Simon, 2006/07/04
- RE: address@hidden: mouse-autoselect-window needs a de lay], Marshall, Simon, 2006/07/06
- RE: address@hidden: mouse-autoselect-window needs a de lay], Marshall, Simon, 2006/07/17
- RE: address@hidden: mouse-autoselect-window needs a de lay], Marshall, Simon, 2006/07/17
- RE: address@hidden: mouse-autoselect-window needs a de lay], Marshall, Simon, 2006/07/18