Emacs 22.1 spit window mouse resize

Emacs 22.1 spit window mouse resize

[Bob Babcock]

Emacs 22.1 on Windows 2000, -q option to not load my .emacs.
If I split the window with split-window-vertically and try to move the 
split point with the mouse, I can only move it up if the focus is in the 
lower half of the window.  Once I touch the split line with the mouse, 
focus moves to the upper half and resizing works in either direction.
.

Re: Emacs 22.1 spit window mouse resize

[martin rudalics]

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

Could you please try the attached patch.


[-- Attachment #2: mouse.patch --]
[-- Type: text/plain, Size: 593 bytes --]

*** mouse.el.~1.315.~	Mon Apr  2 07:45:08 2007
--- mouse.el	Wed Jun  6 17:45:40 2007
***************
*** 498,504 ****
  			   (and (not should-enlarge-minibuffer)
  				(> growth 0)
  				mode-line-p
! 				(/= top (nth 1 (window-edges)))))
  		   (set-window-configuration wconfig)))))))))
  
  (defun mouse-drag-mode-line (start-event)
--- 498,504 ----
  			   (and (not should-enlarge-minibuffer)
  				(> growth 0)
  				mode-line-p
! 				(/= top (nth 1 (window-edges start-event-window)))))
  		   (set-window-configuration wconfig)))))))))
  
  (defun mouse-drag-mode-line (start-event)


[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: Emacs 22.1 spit window mouse resize

[Bob Babcock]

martin rudalics <rudalics@gmx.at> wrote in
news:mailman.1648.1181145235.32220.bug-gnu-emacs@gnu.org: 

> Could you please try the attached patch.
> 
> Attachment decoded: untitled-2.txt
> --------------040800040006070503080008
> *** mouse.el.~1.315.~     Mon Apr  2 07:45:08 2007
> --- mouse.el     Wed Jun  6 17:45:40 2007
> ***************
> *** 498,504 ****
>                     (and (not should-enlarge-minibuffer)
>                       (> growth 0)
>                       mode-line-p
> !                     (/= top (nth 1 (window-edges)))))
>                (set-window-configuration wconfig)))))))))
>   
>   (defun mouse-drag-mode-line (start-event)
> --- 498,504 ----
>                     (and (not should-enlarge-minibuffer)
>                       (> growth 0)
>                       mode-line-p
> !                     (/= top (nth 1 (window-edges
> start-event-window))))) 
>                (set-window-configuration wconfig)))))))))
>   
>   (defun mouse-drag-mode-line (start-event)
> 
> 
> Attachment decoded: mouse.patch

Yes, this fixes the problem of not being able to move the divider down when 
the focus is in the lower half of the window.  Thanks.

It's still true that the focus moves to the upper half when I release the 
mouse button.  Is this supposed to happen?  (In emacs 21.3, the focus 
shifts when I press the mouse button.)  Around the end of January, someone 
posted a complaint about this focus behavior.  I posted a me-too message, 
and RMS sent me a mouse.el patch.  After a couple iterations, it had the 
same problem as the current release version and I didn't hear any further.  
Probably my last email about it got lost in the vast sea of spam we all 
face these days.
.

Re: Emacs 22.1 spit window mouse resize

[martin rudalics]

 > It's still true that the focus moves to the upper half when I release the
 > mouse button.  Is this supposed to happen?  (In emacs 21.3, the focus
 > shifts when I press the mouse button.)

Do you think the 21.3 behavior is better?

 > Around the end of January, someone
 > posted a complaint about this focus behavior.  I posted a me-too message,
 > and RMS sent me a mouse.el patch.  After a couple iterations, it had the
 > same problem as the current release version and I didn't hear any further.
 > Probably my last email about it got lost in the vast sea of spam we all
 > face these days.

Does the problem go away if you do

(global-set-key [mode-line drag-mouse-1] 'ignore)

Re: Emacs 22.1 spit window mouse resize

[Bob Babcock]

martin rudalics <rudalics@gmx.at> wrote in
news:mailman.1705.1181206608.32220.bug-gnu-emacs@gnu.org: 

> > It's still true that the focus moves to the upper half when I
> > release the mouse button.  Is this supposed to happen?  (In emacs
> > 21.3, the focus shifts when I press the mouse button.)
> 
> Do you think the 21.3 behavior is better?

If the focus is going to shift, it doesn't really matter whether it happens 
on the press or the release.  (But delaying it until the release means you 
can look at whether the mode line moved and use that info to decide what to 
do with the focus.  I assume that's what the new mouse.el does.)

> Does the problem go away if you do
> 
> (global-set-key [mode-line drag-mouse-1] 'ignore)

Yes, that does seem to fix it (only in emacs 22.1, not in 21.3).  Thanks 
again.
.

Re: Emacs 22.1 spit window mouse resize

[Richard Stallman]

     > It's still true that the focus moves to the upper half when I release the
     > mouse button.  Is this supposed to happen?  (In emacs 21.3, the focus
     > shifts when I press the mouse button.)

    Do you think the 21.3 behavior is better?

I think that dragging the mode line up or down
should not change the selected window.  If it does select a window,
that's a bug.

I tried to fix this bug, using mouse-drag-move-window-top
to avoid the need to temporarily select a window inside
mouse-drag-mode-line-1.  Why does it select a window?

Re: Emacs 22.1 spit window mouse resize

[Bob Babcock]

Is there any negative side effect to the previous suggestion to use
(global-set-key [mode-line drag-mouse-1] 'ignore)
?  I don't see any problem in limited testing, but I need to do some work 
on my .emacs before I can put the new version into production.
.

Re: Emacs 22.1 spit window mouse resize

[martin rudalics]

 > I think that dragging the mode line up or down
 > should not change the selected window.  If it does select a window,
 > that's a bug.
 >
 > I tried to fix this bug, using mouse-drag-move-window-top
 > to avoid the need to temporarily select a window inside
 > mouse-drag-mode-line-1.  Why does it select a window?

Because of

(global-set-key [mode-line drag-mouse-1] 'mouse-select-window)

Is there any need for this barely sensical binding?


In this context:

1. Has the drag-mouse-1 concept where I can drag an object _without_
keeping the button depressed been abandoned for modelines and dividers?
Is there a reasonable way to implement it?  Clicking button-1 again to
stop the drag would simply have to do _nothing_.  But this would
apparently conflict with

;; Binding mouse-1 to mouse-select-window when on mode-, header-, or
;; vertical-line prevents Emacs from signaling an error when the mouse
;; button is released after dragging these lines, on non-toolkit
;; versions.
(global-set-key [mode-line mouse-1] 'mouse-select-window)


2. Is there any way to drag vertical dividers in a more convenient way
than to move the mouse cursor to a tiny area on the mode-line?  I could
conceive to move vertical dividers either by dragging a fringe (provided
it's there) or by dragging scroll bars "horizontally" (thus trying to
distinguish merely x- and merely y- increments).

I tried a slightly enhanced `mouse-drag-vertical-line' with the
following bindings

(global-set-key [right-fringe down-mouse-1] 'mouse-drag-right-fringe)
(global-set-key [left-fringe down-mouse-1] 'mouse-drag-left-fringe)

and it works well though it might conflict with `gdb-ui' bindings.

Re: Emacs 22.1 spit window mouse resize

[martin rudalics]

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

 > I think that dragging the mode line up or down
 > should not change the selected window.  If it does select a window,
 > that's a bug.
 >
 > I tried to fix this bug, using mouse-drag-move-window-top
 > to avoid the need to temporarily select a window inside
 > mouse-drag-mode-line-1.  Why does it select a window?

It selects the window above because in `mouse-drag-mode-line-1' the last
event before leaving the `track-mouse' form is a drag-mouse-1 event and
it's unread by the code.  Its subsequent execution causes, according to
the binding

(global-set-key [mode-line drag-mouse-1] 'mouse-select-window)

the selection of the window above.  Removing that binding still doesn't
work because this would cause the alternate binding

(global-set-key [mode-line mouse-1] 'mouse-select-window)

to become effective.  The attached patch should take care of this and
the other problem.  OK to install?

[-- Attachment #2: mouse.patch --]
[-- Type: text/plain, Size: 1999 bytes --]

*** mouse.el.~1.315.~	Mon Apr  2 07:45:08 2007
--- mouse.el	Sun Jun 17 14:53:46 2007
***************
*** 433,441 ****
  	  ;;   - there is a scroll-bar-movement event
  	  ;;     (same as mouse movement for our purposes)
  	  ;; quit if
! 	  ;;   - there is a keyboard event or some other unknown event
! 	  ;;     unknown event.
! 	  (cond ((integerp event)
  		 (setq done t))
  
  		((memq (car event) '(switch-frame select-window))
--- 433,440 ----
  	  ;;   - there is a scroll-bar-movement event
  	  ;;     (same as mouse movement for our purposes)
  	  ;; quit if
! 	  ;;   - there is a keyboard event or some other unknown event.
! 	  (cond ((not (consp event))
  		 (setq done t))
  
  		((memq (car event) '(switch-frame select-window))
***************
*** 443,449 ****
  
  		((not (memq (car event) '(mouse-movement scroll-bar-movement)))
  		 (when (consp event)
! 		   (push event unread-command-events))
  		 (setq done t))
  
  		((not (eq (car mouse) start-event-frame))
--- 442,452 ----
  
  		((not (memq (car event) '(mouse-movement scroll-bar-movement)))
  		 (when (consp event)
! 		   ;; Do not unread a drag-mouse-1 event since it will cause the
! 		   ;; selection of the window above when dragging the modeline
! 		   ;; above the selected window.
! 		   (unless (eq (car event) 'drag-mouse-1)
! 		     (push event unread-command-events)))
  		 (setq done t))
  
  		((not (eq (car mouse) start-event-frame))
***************
*** 498,504 ****
  			   (and (not should-enlarge-minibuffer)
  				(> growth 0)
  				mode-line-p
! 				(/= top (nth 1 (window-edges)))))
  		   (set-window-configuration wconfig)))))))))
  
  (defun mouse-drag-mode-line (start-event)
--- 501,510 ----
  			   (and (not should-enlarge-minibuffer)
  				(> growth 0)
  				mode-line-p
! 				(/= top
! 				    (nth 1 (window-edges
! 					    ;; Choose right window.
! 					    start-event-window)))))
  		   (set-window-configuration wconfig)))))))))
  
  (defun mouse-drag-mode-line (start-event)

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: Emacs 22.1 spit window mouse resize

[Bob Babcock]

martin rudalics <rudalics@gmx.at> wrote in
news:mailman.2286.1182087886.32220.bug-gnu-emacs@gnu.org: 

> It selects the window above because in `mouse-drag-mode-line-1' the
> last event before leaving the `track-mouse' form is a drag-mouse-1
> event and it's unread by the code.  Its subsequent execution causes,
> according to the binding
> 
> (global-set-key [mode-line drag-mouse-1] 'mouse-select-window)
> 
> the selection of the window above.  Removing that binding still
> doesn't work because this would cause the alternate binding
> 
> (global-set-key [mode-line mouse-1] 'mouse-select-window)
> 
> to become effective.  The attached patch should take care of this and
> the other problem.  OK to install?

I find that either this latest patch or unbinding [mode-line drag-mouse-1] 
works with Windows 2000.  (I already have the part of the last patch around 
line 501 that adds start-event-window.  I'm starting with -q so my .emacs 
doesn't get loaded, then loading the modified mouse.el.)
.