New keybinding suggestion: C-x _ for `shrink-window'

New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

What about this new keybinding:

  C-x _ `shrink-window'

As we already have:

  C-x - `shrink-window-if-larger-than-buffer'
  C-x ^ `enlarge-window'

AFAIK C-x _ is currently free.  Perhaps it's because I'm a heavy user of
the ratpoison window-manager (which is very emacs-friendly), but I think
it's logical to expect a keybinding for the twin of `enlarge-window'.

What do you think?

PS: Sorry i wrongly posted this to <help-gnu-emacs@gnu.org> before.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

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

Bastien wrote:
> What about this new keybinding:
> 
>   C-x _ `shrink-window'
> 
> As we already have:
> 
>   C-x - `shrink-window-if-larger-than-buffer'
>   C-x ^ `enlarge-window'
> 
> AFAIK C-x _ is currently free.  Perhaps it's because I'm a heavy user of
> the ratpoison window-manager (which is very emacs-friendly), but I think
> it's logical to expect a keybinding for the twin of `enlarge-window'.
> 
> What do you think?
> 
> PS: Sorry i wrongly posted this to <help-gnu-emacs@gnu.org> before.


As I answered on that mailing list I think you might want try 
bw-interactive.el.

My suggestion is that this is added to Emacs instead. I have attached 
the file.

This file contains a minor mode:

   (define-minor-mode bw-window-resize-mode
     "Minor mode temporary used for resizing the selected window.

   Normally you start this temporary minor mode by typing
       C-x +

   This will start a temporary mode in the current buffer where
       +   means balance windows
       .   balance siblings
       f   shrink windows to fit buffers
       arrow keys: start interactive resizing.

   First arrow key pressed tells which border should be moved.
   Subsequent arrow keys moves that border.

   You should normally not call this function yourself. However if
   you do then ARG has the following meaning: nil it toggles the
   mode, -1 turns the mode off, 1 turns the mode on."
   ... )

Using this "C-x +" should be bound so that it starts this minor mode.

[-- Attachment #2: bw-interactive.el --]
[-- Type: text/plain, Size: 11756 bytes --]

;;; bw-interactive.el --- Functions for interactive resize of windows
;;
;; Description:
;; Author: Lennart Borgman <lennart dot borgman dot 073 at student at lu at se>
;; Maintainer:
;; Created: Wed Dec 07 15:35:09 2005
;; Version: 0.7
;; Last-Updated: Tue Jul 18 00:29:25 2006 (7200 +0200)
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This file contains functions for interactive resizing of Emacs
;; windows. To use it put it in your `load-path' and add the following
;; to your .emacs:
;;
;;     (require 'bw-interactive)
;;     (global-set-key [(control x) ?+] 'bw-start-resize-mode)
;;
;; Typing "C-x +" will now enter a temporary mode for resizing windows.
;; For more information see `bw-mode-resize'.
;;
;; These functions are the second part of my proposal for a new
;; `balance-windows' function for Emacs. These second part were not
;; accepted into Emacs 22, but you can use this module instead to get
;; the functionality. It requires Emacs 22 from 2006.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;; 2005-12-08 Changed to use `overriding-terminal-local-map'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;; Check if using new function from Emacs 22
(unless (fboundp 'bw-balance-sub) (require 'bw-base))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Window resizing minor mode
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun bw-balance-windows()
  "Call `balance-windows' and exit `bw-window-resize-mode'."
  (interactive)
  (balance-windows)
  (bw-exit-resize-mode))

(defun bw-balance-siblings()
  "Make current window siblings the same height or width."
  (interactive)
  (balance-windows (selected-window))
  (bw-exit-resize-mode))

(defun bw-shrink-windows-horizontally()
  "Shrink horizontally any window that could be shrinked to fit buffer."
  (interactive)
  (walk-windows 'shrink-window-if-larger-than-buffer)
  (bw-exit-resize-mode))

(defun bw-exit-resize-mode()
  "Exit bw window resize mode.
See `bw-window-resize-mode'."
  (interactive)(bw-window-resize-mode -1))

(defconst bw-keymap
  (let ((map (make-sparse-keymap "Window Resizing")))
    (define-key map [menu-bar bw]
      (cons "Resize" (make-sparse-keymap "second")))
    (define-key map [menu-bar bw shrink]
      '("Shrink to Buffers" . bw-shrink-windows-horizontally))
    (define-key map [menu-bar bw siblings]
      '("Balance Window Siblings" . bw-balance-siblings))
    (define-key map [menu-bar bw balance]
      '("Balance Windows" . bw-balance-windows))
    (define-key map [t]  'bw-exit-resize-mode)
    (define-key map [?+] 'bw-balance-windows)
    (define-key map [?.] 'bw-balance-siblings)
    (define-key map [?f] 'bw-shrink-windows-horizontally)
    (define-key map [(up)]    'bw-mode-resize-up)
    (define-key map [(down)]  'bw-mode-resize-down)
    (define-key map [(left)]  'bw-mode-resize-left)
    (define-key map [(right)] 'bw-mode-resize-right)
    map)
  "Keymap used by `bw-window-resize-mode'.")

(defvar bw-window-to-resize nil
  "Window selected for resizing.")
(defvar bw-window-to-resize-buffer nil
  "Buffer shown in `bw-window-to-resize'.")
(defvar bw-frame nil "Frame for resizing.")
(defun bw-window-resize-post-command()
  "Exit `bw-window-resize-mode' unless focus is in window to resize.
Added `post-command-hook' in `bw-window-resize-mode'."
  (if (and (not (active-minibuffer-window))
           (eq bw-window-to-resize (selected-window))
           (eq bw-window-to-resize-buffer (window-buffer (selected-window)))
           )
      t
    (bw-window-resize-mode -1)
    nil))



(defun bw-start-resize-mode()
  "Enter bw window resize mode.
See `bw-window-resize-mode'."
  (interactive)
  (if (= 1 (length (window-list)))
      (message "There is only one window on this frame, can't resize that")
    (message "Arrow keys: interactive resize, '+': balance windows, '.': balance siblings")
    (bw-window-resize-mode 1)))

(defvar bw-window-for-side-hor nil
  "Window used internally for resizing in horizontal direction.")
(defvar bw-window-for-side-ver nil
  "Window used internally for resizing in vertical direction.")
(defun bw-mode-resize-left()
  "Decrease or increase window size.

First time a key for vertical (horizontal) enlarging is hit it
moves the mouse cursor to the corresponding window border if that
is not the frame border.  Subsequent hits on such a key moves
that window border.

The name of the function tells which border to handle.

Note: This is modelled after how some GUI window managers do
similar resizing."
  (interactive)(bw-mode-resize -1 t))
(defun bw-mode-resize-right()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize 1  t))
(defun bw-mode-resize-up()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize -1 nil))
(defun bw-mode-resize-down()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize 1  nil))

(defun bw-window-beside(window side)
  "Return a window directly beside WINDOW at side SIDE.
That means one whose edge on SIDE is touching WINDOW.  SIDE
should be a number corresponding to positions in the values
returned by 'window-edges'."
  (let ((start-window window)
        (start-left   (nth 0 (window-edges window)))
        (start-top    (nth 1 (window-edges window)))
        (start-right  (nth 2 (window-edges window)))
        (start-bottom (nth 3 (window-edges window)))
	above-window)
    (setq window (previous-window window 0))
    (while (and (not above-window) (not (eq window start-window)))
      (let (
            (left   (nth 0 (window-edges window)))
            (top    (nth 1 (window-edges window)))
            (right  (nth 2 (window-edges window)))
            (bottom (nth 3 (window-edges window)))
            )
        (if (or (= side 0) (= side 2))
            (when (and (if (= side 0) (= right start-left) (= left start-right))
                       (or (and (<= top start-top)    (<= start-bottom bottom))
                           (and (<= start-top top)    (<= top start-bottom))
                           (and (<= start-top bottom) (<= bottom start-bottom))))
              (setq above-window window))
          (when (and (if (= side 1) (= bottom start-top) (= top start-bottom))
                     (or (and (<= left start-left)  (<= start-right right))
                         (and (<= start-left left)  (<= left start-right))
                         (and (<= start-left right) (<= right start-right))))
            (setq above-window window))))
      (setq window (previous-window window)))
    above-window))

(defun bw-mode-resize(arg horizontal)
  "Used by `bw-mode-resize-left' etc."
  (unless (= (* arg arg) 1)
    (error "ARG must be -1 or 1"))
  (let* ((bw-side (if horizontal 'bw-window-for-side-hor 'bw-window-for-side-ver))
         (preserve-before (eq arg 1))
         (dir (if horizontal 'hor 'ver))
         (moveable t)
         (bside (if horizontal
                    (if (< arg 0) 0 2)
                 (if (< arg 0) 1 3)))
         (window-beside (bw-window-beside (selected-window) bside))
         )
    (if (not (symbol-value bw-side))
        (progn
          (unless window-beside
            (setq moveable nil))
          (when (> arg 0) (setq window-beside (selected-window)))
          (when moveable (set bw-side window-beside)))
      (when bw-window-resize-mode
        (condition-case err
            (adjust-window-trailing-edge (symbol-value bw-side) arg horizontal)
          (error (message "%s" (error-message-string err)))
          )))
    (when (= 1 (length (window-list))) (bw-exit-resize-mode))
    (unless moveable (bw-exit-resize-mode))
    (when (and moveable
               bw-window-resize-mode)
      (bw-move-mouse-to-resized))))

(defun bw-move-mouse-to-resized()
  "Move mouse to the border beeing moved in interactive resize."
  (let* ((edges (window-edges))
         (L (nth 0 edges))
         (T (nth 1 edges))
         (R (nth 2 edges))
         (B (nth 3 edges))
         (x (/ (+ L R) 2))
         (y (/ (+ T B) 2)))
    (when bw-window-for-side-hor
      ;;(setq x (if (= bw-window-for-side-hor -1) (- L 1) (- R 1))))
      (setq x (if (eq (selected-window) bw-window-for-side-hor) (- R 1) (- L 1))))
    (when bw-window-for-side-ver
      ;;(setq y (if (= bw-window-for-side-ver -1) (- T 1) (- B 1))))
      (setq y (if (eq (selected-window) bw-window-for-side-ver) (- B 1) (- T 1))))
    (set-mouse-position (selected-frame) x y)))


(defvar bw-mode-line-old-bg nil)
;;(defvar bw-old-help-event-list nil)
(define-minor-mode bw-window-resize-mode
  "Minor mode temporary used for resizing the selected window.

Normally you start this temporary minor mode by typing
    C-x +

This will start a temporary mode in the current buffer where
    +   means balance windows
    .   balance siblings
    f   shrink windows to fit buffers
    arrow keys: start interactive resizing.

First arrow key pressed tells which border should be moved.
Subsequent arrow keys moves that border.

You should normally not call this function yourself. However if
you do then ARG has the following meaning: nil it toggles the
mode, -1 turns the mode off, 1 turns the mode on."
  :init-value nil
  :lighter " *WINDOW RESIZING*"
  ;;:keymap bw-keymap
  :group 'windows

  (setq bw-window-for-side-hor nil)
  (setq bw-window-for-side-ver nil)
  (if bw-window-resize-mode
      (progn
        (setq bw-keymap (let ((map (make-sparse-keymap)))
                          (set-keymap-parent map bw-keymap)
                          map))
        (dolist (key help-event-list)
          (define-key bw-keymap (vector key) nil))
        (setq bw-window-to-resize (selected-window))
        (setq bw-window-to-resize-buffer (window-buffer (selected-window)))
        (setq bw-frame (selected-frame))
        (add-hook 'post-command-hook 'bw-window-resize-post-command)
        (setq bw-keymap-alist (list (cons 'bw-keymap bw-keymap)))
        (setq overriding-terminal-local-map bw-keymap)
        (setq overriding-local-map-menu-flag t)
        (setq bw-mode-line-old-bg (face-attribute 'mode-line :background))
        (set-face-attribute 'mode-line bw-frame :background "#ff0000")
        ;;(describe-variable 'bw-keymap (get-buffer-create "*Help*"))
        )
    (setq overriding-terminal-local-map nil)
    (setq overriding-local-map-menu-flag nil)
    (setq bw-keymap (keymap-parent bw-keymap))
    (remove-hook 'post-command-hook 'bw-window-resize-post-command)
    (setq bw-window-to-resize nil)
    (setq bw-window-to-resize-buffer nil)
    (when (frame-live-p bw-frame)
      (set-face-attribute 'mode-line bw-frame :background bw-mode-line-old-bg))
    ))


(provide 'bw-interactive)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; bw-interactive.el ends here

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

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> What about this new keybinding:
>>
>>   C-x _ `shrink-window'
>
> As I answered on that mailing list I think you might want try
> bw-interactive.el.

Sorry, I missed it.

> My suggestion is that this is added to Emacs instead. I have attached
> the file.

My suggestion would be to have both: C-x _ as a new keybinding for
`shrink-window' (since we already have a key for `enlarge-window')
*and* bw-interactive.el, which sounds nice.  

IMHO it's better to stick to the possibility of balancing/resizing
windows (or shrinking/enlarging them) with just *one* keystroke.

A few comments on bw-interactive.el though.  Assume I start with a full
window and have C-x + bound to `bw-start-resize-mode':

- It seems that the first arrow keystroke says: "Hello, please start
  resizing with arrow keys!" but wait for another keystroke. I think
  the user might expect that the first arrow keystroke has a visible
  effect on window resizing already.

- C-x 2 C-x + <up> won't shrink the window if it's larger than the
  buffer;  but C-x 2 C-x + <down> <up> <up> will shrink the window
  even if it's *initially* larger than buffer.  I believe that the 
  first set of keystrokes should already shrink the window, or at 
  least send an error to the user.

Anyway, bw-interactive seems like it's already very useful to me, 
thanks for that.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Bastien wrote:
> My suggestion would be to have both: C-x _ as a new keybinding for
> `shrink-window' (since we already have a key for `enlarge-window')
> *and* bw-interactive.el, which sounds nice.  

It would be a bit strange, see below.

> IMHO it's better to stick to the possibility of balancing/resizing
> windows (or shrinking/enlarging them) with just *one* keystroke.

bw-interactive lets you do this quite easily, with just "C-x + +" (today 
it is on "C-x +").

> A few comments on bw-interactive.el though.  Assume I start with a full
> window and have C-x + bound to `bw-start-resize-mode':
> 
> - It seems that the first arrow keystroke says: "Hello, please start
>   resizing with arrow keys!" but wait for another keystroke. I think
>   the user might expect that the first arrow keystroke has a visible
>   effect on window resizing already.

I do not believe so, but starting the resizing and telling the user what 
is going on is a bit complicated. I tried to mimic the way this is done 
some OS window handlers. When you start resizing you get into a state 
where the window handler first needs to know which border to move. The 
mouse pointer is then moved to that border.

It is the same with bw-interactive, which also changes the color of the 
relevant windows mode line. The window handler however also changes the 
mouse pointer to reflect the state. Currently this is not possible in 
Emacs, but if bw-interactive is adopted I would suggest to add relevant 
mouse cursors for showing the state.

> - C-x 2 C-x + <up> won't shrink the window if it's larger than the
>   buffer;  but C-x 2 C-x + <down> <up> <up> will shrink the window
>   even if it's *initially* larger than buffer.  I believe that the 
>   first set of keystrokes should already shrink the window, or at 
>   least send an error to the user.

This is a slight misunderstanding, see above.

Maybe adding a message of some kind when exiting the minor mode for 
resizing would make thins more clear?

> Anyway, bw-interactive seems like it's already very useful to me, 
> thanks for that.

Thanks.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> My suggestion would be to have both: C-x _ as a new keybinding for
>> `shrink-window' (since we already have a key for `enlarge-window')
>> *and* bw-interactive.el, which sounds nice.  
>
> It would be a bit strange, see below.

Why?  Letting people have the usual keybindings like:

  C-x +  `balance-windows'
  C-x ^  `enlarge-window'
  C-x -  `shrink-window-if-larger-than-buffer'
 [C-x _  `shrink-window'] <= according to what I suggest

*and* letting them load bw-interactive.el if they want to resize windows
interactively looks fine to me.  It's simpler 1) not to rebind C-x + and
2) to have C-x + balancing the windows (instead of C-x + + which add one
keystroke.)

> bw-interactive lets you do this quite easily, with just "C-x + +" (today
> it is on "C-x +").

My point is precisely that C-x + is fine as it is.

>> A few comments on bw-interactive.el though.  Assume I start with a
>> full window and have C-x + bound to `bw-start-resize-mode':
>>
>> - It seems that the first arrow keystroke says: "Hello, please start
>>   resizing with arrow keys!" but wait for another keystroke. I think
>>   the user might expect that the first arrow keystroke has a visible
>>   effect on window resizing already.
>
> I do not believe so, but starting the resizing and telling the user what
> is going on is a bit complicated. 

I don't suggest that bw-interactive.el should tell the user what is
going on.  I suggest that `bw-start-resize-mode' start listening to the
next keystroke (as it does) and that the next keystroke take immediately
action.  Again, it's more intuitive to me that C-x + <up> increase the
vertical size of the window immediately.

> I tried to mimic the way this is done some OS window handlers.

Which one?  I'm using ratpoison.  C-t C-r does the job of your C-x +,
then C-f will enlarge the ratpoison-window immediately, no need to press
C-f twice.

> When you start resizing you get into a state where the window handler
> first needs to know which border to move. The mouse pointer is then
> moved to that border.

Isn't that simpler to move the border when you know which border to
move?  Maybe I'm too much thinking the ratpoison way here.  An example
of a WM implementing the behavior you suggest would be useful, because 
I honestly don't see why this has to be a two-step process.

>> - C-x 2 C-x + <up> won't shrink the window if it's larger than the
>>   buffer;  but C-x 2 C-x + <down> <up> <up> will shrink the window
>>   even if it's *initially* larger than buffer.  I believe that the
>> first set of keystrokes should already shrink the window, or at
>> least send an error to the user.
>
> This is a slight misunderstanding, see above.

Okay, understood.

> Maybe adding a message of some kind when exiting the minor mode for
> resizing would make thins more clear?

Yes, sure.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Bastien wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>>> My suggestion would be to have both: C-x _ as a new keybinding for
>>> `shrink-window' (since we already have a key for `enlarge-window')
>>> *and* bw-interactive.el, which sounds nice.  
>> It would be a bit strange, see below.
> 
> Why?  Letting people have the usual keybindings like:
> 
>   C-x +  `balance-windows'
>   C-x ^  `enlarge-window'

This is not well defined. There may be 4 different borders to move.

>   C-x -  `shrink-window-if-larger-than-buffer'

Same as above.

>  [C-x _  `shrink-window'] <= according to what I suggest

Same as above.

> *and* letting them load bw-interactive.el if they want to resize windows
> interactively looks fine to me.  It's simpler 1) not to rebind C-x + and
> 2) to have C-x + balancing the windows (instead of C-x + + which add one
> keystroke.)
> 
>> bw-interactive lets you do this quite easily, with just "C-x + +" (today
>> it is on "C-x +").
> 
> My point is precisely that C-x + is fine as it is.

And mine is that resizing windows should not occupy more human memory 
and key binding space if possible. "C-x + +" is nearly as easy as "C-x 
+" to type.

> I don't suggest that bw-interactive.el should tell the user what is
> going on.  I suggest that `bw-start-resize-mode' start listening to the
> next keystroke (as it does) and that the next keystroke take immediately
> action.  Again, it's more intuitive to me that C-x + <up> increase the
> vertical size of the window immediately.

See above. You have to decide which border to act on first.

>> I tried to mimic the way this is done some OS window handlers.
> 
> Which one?  I'm using ratpoison.  C-t C-r does the job of your C-x +,
> then C-f will enlarge the ratpoison-window immediately, no need to press
> C-f twice.

Eh, I am using w32. Do you mean that ratpoison interfere with Emacs key 
bindings?

>> When you start resizing you get into a state where the window handler
>> first needs to know which border to move. The mouse pointer is then
>> moved to that border.
> 
> Isn't that simpler to move the border when you know which border to
> move?  Maybe I'm too much thinking the ratpoison way here.  An example
> of a WM implementing the behavior you suggest would be useful, because 
> I honestly don't see why this has to be a two-step process.

I tried to explain above. Is it clear now? (Or have I perhaps missed 
something?)

>> Maybe adding a message of some kind when exiting the minor mode for
>> resizing would make thins more clear?
> 
> Yes, sure.

Thanks, I will add a message when exiting the minor mode then.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>>   C-x +  `balance-windows'
>>   C-x ^  `enlarge-window'
>
> This is not well defined. There may be 4 different borders to move.

It is well-defined: `enlarge-window' means implicitely enlarge-window
vertically (since enlarge-window-horizontally is a separate function).

And having four borders in a window doesn't mean you can always act on
this four borders.  Actually, in most of the cases, you can vertically
act on only one border, and horizontally act on only one border.  

This is why `enlarge-window' and `shrink-window' are well defined IMHO:
it's pretty rare to have a window with two movable vertical borders or
two movable horizontal borders.

>>   C-x -  `shrink-window-if-larger-than-buffer'
>
> Same as above.

Why?  Please show me an example when it doesn't behave as the user would
expect. 

>> My point is precisely that C-x + is fine as it is.
>
> And mine is that resizing windows should not occupy more human memory
> and key binding space if possible. "C-x + +" is nearly as easy as "C-x
> +" to type.

Don't get me wrong: I do think bw-interactive.el is useful when you need
to do complex resizing.  But we more often need to do simple resizing so
simply adjusting the window size with the native keybindings is fine.

And `C-x + +' uses more human memory than `C-x +', no?

>> Again, it's more intuitive to me that C-x + <up> increase the
>> vertical size of the window immediately.
>
> See above. You have to decide which border to act on first.

But can't you make the <left> arrow key be at the same time the decision
(resize from the left border) *and* the action (move left)? And drop the
action in case it has no sense in the current window configuration?  

>> Which one?  I'm using ratpoison.  C-t C-r does the job of your C-x +,
>> then C-f will enlarge the ratpoison-window immediately, no need to
>> press C-f twice.
>
> Eh, I am using w32. Do you mean that ratpoison interfere with Emacs key
> bindings?

No.  I mean that in ratpoison you have the same window configuration
than the one in Emacs, and resizing a window just takes one keystroke;
you don't need to decide what border to move first, then how to move it.

> I tried to explain above. Is it clear now? (Or have I perhaps missed
> something?)

Sorry but it's not clearer... any example would perhaps be useful.
Maybe I just miss something very obvious myself.

> Thanks, I will add a message when exiting the minor mode then.

Great, thanks.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Bastien wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>>>   C-x +  `balance-windows'
>>>   C-x ^  `enlarge-window'
>> This is not well defined. There may be 4 different borders to move.
> 
> It is well-defined: `enlarge-window' means implicitely enlarge-window
> vertically (since enlarge-window-horizontally is a separate function).
> 
> And having four borders in a window doesn't mean you can always act on
> this four borders.  Actually, in most of the cases, you can vertically
> act on only one border, and horizontally act on only one border.  
> 
> This is why `enlarge-window' and `shrink-window' are well defined IMHO:
> it's pretty rare to have a window with two movable vertical borders or
> two movable horizontal borders.

Yes, you are right in that the case where there is only one border to 
move is the most common. It makes sense to add code for that I think.

>>>   C-x -  `shrink-window-if-larger-than-buffer'
>> Same as above.
> 
> Why?  Please show me an example when it doesn't behave as the user would
> expect. 

When the bottom border and top border both could be moved.

>>> My point is precisely that C-x + is fine as it is.
>> And mine is that resizing windows should not occupy more human memory
>> and key binding space if possible. "C-x + +" is nearly as easy as "C-x
>> +" to type.
> 
> Don't get me wrong: I do think bw-interactive.el is useful when you need
> to do complex resizing.  But we more often need to do simple resizing so
> simply adjusting the window size with the native keybindings is fine.
> 
> And `C-x + +' uses more human memory than `C-x +', no?

I believe human memory comes in chunks of three bytes ... ;-)

>>> Again, it's more intuitive to me that C-x + <up> increase the
>>> vertical size of the window immediately.
>> See above. You have to decide which border to act on first.
> 
> But can't you make the <left> arrow key be at the same time the decision
> (resize from the left border) *and* the action (move left)?

Would not that mean that the border might be moved in the wrong direction.

> And drop the
> action in case it has no sense in the current window configuration?  

Currently any key that makes no sense exits the minor mode. But maybe it 
is better to make the arrow keys give some message if the action is not 
possible.


>> I tried to explain above. Is it clear now? (Or have I perhaps missed
>> something?)
> 
> Sorry but it's not clearer... any example would perhaps be useful.
> Maybe I just miss something very obvious myself.

I think I missed that the special case with just one border to move is 
the most common. Maybe that is where we miscommunicated?

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

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

The last message I sent explain what I wanted to change in 
bw-interactive.el. In this version I have done this and some other minor 
things (putting back the exiting event on the input queue like isearch 
does, better feedback).

Bastien, do you want to test?

[-- Attachment #2: bw-interactive.el --]
[-- Type: text/plain, Size: 13231 bytes --]

;;; bw-interactive.el --- Functions for interactive resize of windows
;;
;; Description:
;; Author: Lennart Borgman <lennart dot borgman dot 073 at student at lu at se>
;; Maintainer:
;; Created: Wed Dec 07 15:35:09 2005
;; Version: 0.7
;; Last-Updated: Mon Oct 29 01:02:57 2007 (3600 +0100)
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This file contains functions for interactive resizing of Emacs
;; windows. To use it put it in your `load-path' and add the following
;; to your .emacs:
;;
;;     (require 'bw-interactive)
;;     (global-set-key [(control x) ?+] 'bw-start-resize-mode)
;;
;; Typing "C-x +" will now enter a temporary mode for resizing windows.
;; For more information see `bw-mode-resize'.
;;
;; These functions are the second part of my proposal for a new
;; `balance-windows' function for Emacs. These second part were not
;; accepted into Emacs 22, but you can use this module instead to get
;; the functionality. It requires Emacs 22 from 2006.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;; 2005-12-08 Changed to use `overriding-terminal-local-map'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;; Check if using new function from Emacs 22
(unless (fboundp 'bw-balance-sub) (require 'bw-base))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Window resizing minor mode
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun bw-balance-windows()
  "Call `balance-windows' and exit `bw-window-resize-mode'."
  (interactive)
  (balance-windows)
  (bw-exit-resize-mode nil))

(defun bw-balance-siblings()
  "Make current window siblings the same height or width."
  (interactive)
  (balance-windows (selected-window))
  (bw-exit-resize-mode nil))

(defun bw-shrink-windows-horizontally()
  "Shrink horizontally any window that could be shrinked to fit buffer."
  (interactive)
  (walk-windows 'shrink-window-if-larger-than-buffer)
  (bw-exit-resize-mode nil))

(defun bw-exit-resize-other()
  "Exit `bw-window-resize-mode'."
  (interactive)
  (bw-exit-resize-mode t))

(defun bw-exit-resize-mode(put-back-last-event)
  (bw-window-resize-mode -1)
  ;; Fix-me: format this ...
  (message "Exited window resizing, last-command-event=%s" last-command-event)
  (when put-back-last-event
    ;; Add this to the input queue again:
    (isearch-unread last-command-event)))

(defconst bw-keymap
  (let ((map (make-sparse-keymap "Window Resizing")))
    (define-key map [menu-bar bw]
      (cons "Resize" (make-sparse-keymap "second")))
    (define-key map [menu-bar bw shrink]
      '("Shrink to Buffers" . bw-shrink-windows-horizontally))
    (define-key map [menu-bar bw siblings]
      '("Balance Window Siblings" . bw-balance-siblings))
    (define-key map [menu-bar bw balance]
      '("Balance Windows" . bw-balance-windows))
    (define-key map [t]  'bw-exit-resize-other)
    (define-key map [?+] 'bw-balance-windows)
    (define-key map [?.] 'bw-balance-siblings)
    (define-key map [?f] 'bw-shrink-windows-horizontally)
    (define-key map [(up)]    'bw-mode-resize-up)
    (define-key map [(down)]  'bw-mode-resize-down)
    (define-key map [(left)]  'bw-mode-resize-left)
    (define-key map [(right)] 'bw-mode-resize-right)
    map)
  "Keymap used by `bw-window-resize-mode'.")

(defvar bw-window-to-resize nil
  "Window selected for resizing.")
(defvar bw-window-to-resize-buffer nil
  "Buffer shown in `bw-window-to-resize'.")
(defvar bw-frame nil "Frame for resizing.")
(defun bw-window-resize-post-command()
  "Exit `bw-window-resize-mode' unless focus is in window to resize.
Added `post-command-hook' in `bw-window-resize-mode'."
  (if (and (not (active-minibuffer-window))
           (eq bw-window-to-resize (selected-window))
           (eq bw-window-to-resize-buffer (window-buffer (selected-window)))
           )
      t
    (bw-window-resize-mode -1)
    nil))



(defun bw-start-resize-mode()
  "Enter `bw-window-resize-mode'."
  (interactive)
  (if (= 1 (length (window-list)))
      (message "There is only one window on this frame, can't resize that")
    (bw-window-resize-mode 1)
    (let ((left   (bw-window-beside (selected-window) 0))
          (top    (bw-window-beside (selected-window) 1))
          (right  (bw-window-beside (selected-window) 2))
          (bottom (bw-window-beside (selected-window) 3))
          (poss 0))
      (when left   (setq poss (1+ poss)))
      (when top    (setq poss (1+ poss)))
      (when right  (setq poss (1+ poss)))
      (when bottom (setq poss (1+ poss)))
      (if (not (= 1 poss))
          (progn
            (set-face-attribute 'mode-line bw-frame :background "#ff0000")
            (message "Arrows: select border, +/. : balance windows/siblings, other: quit")
            )
        (when left   (bw-mode-resize -1 t))
        (when top    (bw-mode-resize -1 nil))
        (when right  (bw-mode-resize 1 t))
        (when bottom (bw-mode-resize 1 nil))
        (bw-start-resizing)))))

(defun bw-help-message()
  (message "Arrows: resize, +/. : balance windows/siblings, other: quit"))

(defun bw-start-resizing()
  (bw-help-message)
  (set-face-attribute 'mode-line bw-frame :background "#ffa500"))

(defvar bw-window-for-side-hor nil
  "Window used internally for resizing in horizontal direction.")
(defvar bw-window-for-side-ver nil
  "Window used internally for resizing in vertical direction.")
(defun bw-mode-resize-left()
  "Decrease or increase window size.

First time a key for vertical (horizontal) enlarging is hit it
moves the mouse cursor to the corresponding window border if that
is not the frame border.  Subsequent hits on such a key moves
that window border.

The name of the function tells which border to handle.

Note: This is modelled after how some GUI window managers do
similar resizing."
  (interactive)(bw-mode-resize -1 t))
(defun bw-mode-resize-right()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize 1  t))
(defun bw-mode-resize-up()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize -1 nil))
(defun bw-mode-resize-down()
  "See `bw-mode-resize-left'."
  (interactive)(bw-mode-resize 1  nil))

(defun bw-window-beside(window side)
  "Return a window directly beside WINDOW at side SIDE.
That means one whose edge on SIDE is touching WINDOW.  SIDE
should be a number corresponding to positions in the values
returned by 'window-edges'."
  (let ((start-window window)
        (start-left   (nth 0 (window-edges window)))
        (start-top    (nth 1 (window-edges window)))
        (start-right  (nth 2 (window-edges window)))
        (start-bottom (nth 3 (window-edges window)))
	above-window)
    (setq window (previous-window window 0))
    (while (and (not above-window) (not (eq window start-window)))
      (let (
            (left   (nth 0 (window-edges window)))
            (top    (nth 1 (window-edges window)))
            (right  (nth 2 (window-edges window)))
            (bottom (nth 3 (window-edges window)))
            )
        (if (or (= side 0) (= side 2))
            (when (and (if (= side 0) (= right start-left) (= left start-right))
                       (or (and (<= top start-top)    (<= start-bottom bottom))
                           (and (<= start-top top)    (<= top start-bottom))
                           (and (<= start-top bottom) (<= bottom start-bottom))))
              (setq above-window window))
          (when (and (if (= side 1) (= bottom start-top) (= top start-bottom))
                     (or (and (<= left start-left)  (<= start-right right))
                         (and (<= start-left left)  (<= left start-right))
                         (and (<= start-left right) (<= right start-right))))
            (setq above-window window))))
      (setq window (previous-window window)))
    above-window))

(defun bw-mode-resize(arg horizontal)
  "Used by `bw-mode-resize-left' etc."
  (unless (= (* arg arg) 1)
    (error "ARG must be -1 or 1"))
  (let* ((bw-side (if horizontal 'bw-window-for-side-hor 'bw-window-for-side-ver))
         (preserve-before (eq arg 1))
         (dir (if horizontal 'hor 'ver))
         (moveable t)
         (bside (if horizontal
                    (if (< arg 0) 0 2)
                 (if (< arg 0) 1 3)))
         (window-beside (bw-window-beside (selected-window) bside))
         )
    (if (not (symbol-value bw-side))
        (progn
          (unless window-beside
            (setq moveable nil))
          (when (> arg 0) (setq window-beside (selected-window)))
          (when moveable
            (bw-start-resizing)
            (set bw-side window-beside)))
      (when bw-window-resize-mode
        (condition-case err
            (adjust-window-trailing-edge (symbol-value bw-side) arg horizontal)
          (error (message "%s" (error-message-string err)))
          )))
    (when (= 1 (length (window-list))) (bw-exit-resize-mode nil))
    (unless moveable (bw-exit-resize-mode t))
    (when (and moveable
               bw-window-resize-mode)
      (bw-help-message)
      (bw-move-mouse-to-resized))))

(defun bw-move-mouse-to-resized()
  "Move mouse to the border beeing moved in interactive resize."
  (let* ((edges (window-edges))
         (L (nth 0 edges))
         (T (nth 1 edges))
         (R (nth 2 edges))
         (B (nth 3 edges))
         (x (/ (+ L R) 2))
         (y (/ (+ T B) 2)))
    (when bw-window-for-side-hor
      ;;(setq x (if (= bw-window-for-side-hor -1) (- L 1) (- R 1))))
      (setq x (if (eq (selected-window) bw-window-for-side-hor) (- R 1) (- L 1))))
    (when bw-window-for-side-ver
      ;;(setq y (if (= bw-window-for-side-ver -1) (- T 1) (- B 1))))
      (setq y (if (eq (selected-window) bw-window-for-side-ver) (- B 1) (- T 1))))
    (set-mouse-position (selected-frame) x y)))


(defvar bw-mode-line-old-bg nil)
;;(defvar bw-old-help-event-list nil)
(define-minor-mode bw-window-resize-mode
  "Minor mode temporary used for resizing the selected window.

Normally you start this temporary minor mode by typing
    C-x +

This will start a temporary mode in the current buffer where
    +   means balance windows
    .   balance siblings
    f   shrink windows to fit buffers
    arrow keys: resize by moving relevant window border
    Other keys exits this mode and will be added to the input queue.

If an arrow key could move borders on both sides (left/right or
top/bottom) then the first arrow key pressed tells which border
should be moved. Subsequent arrow keys moves that border.

You should normally not call this function yourself. However if
you do then ARG has the following meaning: nil it toggles the
mode, -1 turns the mode off, 1 turns the mode on."
  :init-value nil
  :lighter " *WINDOW RESIZING*"
  ;;:keymap bw-keymap
  :group 'windows

  (setq bw-window-for-side-hor nil)
  (setq bw-window-for-side-ver nil)
  (if bw-window-resize-mode
      (progn
        (setq bw-keymap (let ((map (make-sparse-keymap)))
                          (set-keymap-parent map bw-keymap)
                          map))
        (dolist (key help-event-list)
          (define-key bw-keymap (vector key) nil))
        (setq bw-window-to-resize (selected-window))
        (setq bw-window-to-resize-buffer (window-buffer (selected-window)))
        (setq bw-frame (selected-frame))
        (add-hook 'post-command-hook 'bw-window-resize-post-command)
        (setq bw-keymap-alist (list (cons 'bw-keymap bw-keymap)))
        (setq overriding-terminal-local-map bw-keymap)
        (setq overriding-local-map-menu-flag t)
        (setq bw-mode-line-old-bg (face-attribute 'mode-line :background))
        ;;(set-face-attribute 'mode-line bw-frame :background "#ff0000")
        ;;(describe-variable 'bw-keymap (get-buffer-create "*Help*"))
        )
    (setq overriding-terminal-local-map nil)
    (setq overriding-local-map-menu-flag nil)
    (setq bw-keymap (keymap-parent bw-keymap))
    (remove-hook 'post-command-hook 'bw-window-resize-post-command)
    (setq bw-window-to-resize nil)
    (setq bw-window-to-resize-buffer nil)
    (when (frame-live-p bw-frame)
      (set-face-attribute 'mode-line bw-frame :background bw-mode-line-old-bg))
    ))


(provide 'bw-interactive)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; bw-interactive.el ends here

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

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> The last message I sent explain what I wanted to change in
> bw-interactive.el. In this version I have done this and some other minor
> things (putting back the exiting event on the input queue like isearch
> does, better feedback).
>
> Bastien, do you want to test?

I did and it works like a charm. Thanks for your patience and the
changes.  Would be great if other people could send feedback too!

Best,

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    What about this new keybinding:

      C-x _ `shrink-window'

I don't think it is worth using up a key for that.
You can do this now with negative args to `enlarge-window',
and I think that is good enough for a command tha's not used
all that often.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     What about this new keybinding:
>
>       C-x _ `shrink-window'
>
> I don't think it is worth using up a key for that.
> You can do this now with negative args to `enlarge-window',
> and I think that is good enough for a command tha's not used
> all that often.

Sorry to insist on this, but Emacs has also these two keybindings:

  C-x {  shrink-window-horizontally
  C-x }  enlarge-window-horizontally

I find it weird to have a keybinding for `shrink-window-horizontally'
and not for `shrink-window', which is more fundamental.  Especially
because the default split (C-x 2) is horizontal, thus calling for 
vertical resizing.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> Sorry to insist on this, but Emacs has also these two keybindings:

>   C-x {  shrink-window-horizontally
>   C-x }  enlarge-window-horizontally

> I find it weird to have a keybinding for `shrink-window-horizontally'
> and not for `shrink-window', which is more fundamental.  Especially
> because the default split (C-x 2) is horizontal, thus calling for 
> vertical resizing.

Actually, I'd prefer to deprecate those bindings (along with C-x ^) and
replace them with a binding that allows the user to do:

   M-x window-resize RET

(which we'd of course bind to some key) and then

   ^ ^ ^ } } } } } { { { { } } ...
or
   left left left up up up up up up up

I usually don't know how by how many lines I want to expand/shrink a window,
so I typically end up doing

   C-x ^ C-x ^ C-x ^

which is *really* inconvenient.  So a modal interface would reduce the
number of necessary bindings to just 1, freeing the other keys for other
uses, and it would be a lot more convenient for my use cases (hopefully I'm
not the only one out there).


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

On 10/31/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I usually don't know how by how many lines I want to expand/shrink a window,
> so I typically end up doing
>
>    C-x ^ C-x ^ C-x ^
>
> which is *really* inconvenient.

I've been using this for years:

;; Function by Hirose Yuuji and Bob Wiener
(defun resize-window (&optional arg)
  "Resize window interactively."
  (interactive "p")
  (when (one-window-p) (error "Cannot resize sole window"))
  (unless arg (setq arg 1))
  (catch 'done
    (while t
      (message "h=heighten, s=shrink, w=widen, n=narrow (by %d);
1-9=unit, q=quit"
               arg)
      (ignore-errors
        (let ((c (read-char))
              (window-size-fixed nil))
          (cond ((= c ?h) (enlarge-window arg))
                ((= c ?s) (shrink-window arg))
                ((= c ?w) (enlarge-window-horizontally arg))
                ((= c ?n) (shrink-window-horizontally arg))
                ((= c ?\^G) (keyboard-quit))
                ((= c ?q) (throw 'done t))
                ((and (> c ?0) (<= c ?9)) (setq arg (- c ?0))))))))
  (message "Done."))

             Juanma

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/31/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> I usually don't know how by how many lines I want to expand/shrink a window,
>> so I typically end up doing
>>
>>    C-x ^ C-x ^ C-x ^
>>
>> which is *really* inconvenient.
>
> I've been using this for years:
>
> ;; Function by Hirose Yuuji and Bob Wiener
> (defun resize-window (&optional arg)

This is really *neat*.  Thanks!

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    ;; Function by Hirose Yuuji and Bob Wiener
    (defun resize-window (&optional arg)
      "Resize window interactively."
      ...
	      (cond ((= c ?h) (enlarge-window arg))
		    ((= c ?s) (shrink-window arg))
		    ((= c ?w) (enlarge-window-horizontally arg))
		    ((= c ?n) (shrink-window-horizontally arg))
		    ((= c ?\^G) (keyboard-quit))
		    ((= c ?q) (throw 'done t))
		    ((and (> c ?0) (<= c ?9)) (setq arg (- c ?0))))))))
      (message "Done."))

That seems basically good, but using other characters
such as arrow keys would be an improvement.
/ and \ could be good for vertical size changes
and [,] for horizontal; they don't need a shift key.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     ;; Function by Hirose Yuuji and Bob Wiener
>     (defun resize-window (&optional arg)
>       "Resize window interactively."
>       ...
> 	      (cond ((= c ?h) (enlarge-window arg))
> 		    ((= c ?s) (shrink-window arg))
> 		    ((= c ?w) (enlarge-window-horizontally arg))
> 		    ((= c ?n) (shrink-window-horizontally arg))
> 		    ((= c ?\^G) (keyboard-quit))
> 		    ((= c ?q) (throw 'done t))
> 		    ((and (> c ?0) (<= c ?9)) (setq arg (- c ?0))))))))
>       (message "Done."))
> 
> That seems basically good, but using other characters
> such as arrow keys would be an improvement.
> / and \ could be good for vertical size changes
> and [,] for horizontal; they don't need a shift key.


Why not go the whole way and let the user choose which window border to 
move? The code for it is in bw-interactive.el.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

On 11/1/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Why not go the whole way and let the user choose which window border to
> move?

You can always choose which window border to move by selecting the
right window, which is dead easy with windmove.el.

             Juanma

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 11/1/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> Why not go the whole way and let the user choose which window border to
>> move?
> 
> You can always choose which window border to move by selecting the
> right window, which is dead easy with windmove.el.


Maybe, but it seems impractical to me to have to learn a new scheme for 
that. Why not use something that is as similar as possible to what 
window managers do?

I know only the w32 window manager. That is what I have mimicked in 
bw-interactive.el (as close as possible).

I believe something functioning like that should be used. My main 
concern is that you should not have to learn and remember new details.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

On 11/1/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Maybe, but it seems impractical to me to have to learn a new scheme for
> that. Why not use something that is as similar as possible to what
> window managers do?

Which window manager? There are dozens, or hundreds.

> I know only the w32 window manager. That is what I have mimicked in
> bw-interactive.el (as close as possible).

Which would make bw-interactive specially suitable for Emacs users on
Windows, I suppose.

> My main
> concern is that you should not have to learn and remember new details.

For an Emacs package, consistency with the rest of Emacs is more
important that consistency with some window manager, I think.

All in all, I don't like or dislike bw-interactive.el. It seems like
too much complexity for *my specific needs* with respect to window
resizing; I don't think I would ever use it. But perhaps many users
would love it, I don't know. YMMV, etc.

             Juanma

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
>> I know only the w32 window manager. That is what I have mimicked in
>> bw-interactive.el (as close as possible).
> 
> Which would make bw-interactive specially suitable for Emacs users on
> Windows, I suppose.


If different styles are preferred that is easy to add, but I guess most 
wm would do something like:

loop:
1) Select border vertically or horizontally if not done, else
2) Move selected border

And do this for both horizontal and vertical resizing according to user 
input.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

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

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/1/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> Why not go the whole way and let the user choose which window border to
>> move?
>
> You can always choose which window border to move by selecting the
> right window, which is dead easy with windmove.el.

First ugly attempt of using windmove.el with resize-window.  [ldur] keys
should be replaced by arrow keys.  Not heavily tested yet.


[-- Attachment #2: resize-window.el --]
[-- Type: application/emacs-lisp, Size: 1520 bytes --]

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


-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

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

On 11/1/07, Richard Stallman <rms@gnu.org> wrote:

> That seems basically good, but using other characters
> such as arrow keys would be an improvement.

I'm not so sure. "n"arrow or "w"iden are independent of whether the
window is going to be sized by its left or right border, while "->" or
"<-" would depend on it. In other words, "n" and "w" are
window-centric, while the cursor keys would be border-centric.

> / and \ could be good for vertical size changes
> and [,] for horizontal; they don't need a shift key.

/ is S-7 and \ is AltGr-º in a Spanish keyboard...

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    I'm not so sure. "n"arrow or "w"iden are independent of whether the
    window is going to be sized by its left or right border, while "->" or
    "<-" would depend on it. In other words, "n" and "w" are
    window-centric, while the cursor keys would be border-centric.

It does not seem like a problem to me.

    > / and \ could be good for vertical size changes
    > and [,] for horizontal; they don't need a shift key.

    / is S-7 and \ is AltGr-º in a Spanish keyboard...

You can't please everybody.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stephen J. Turnbull]

Richard Stallman writes:

 > That seems basically good, but using other characters
 > such as arrow keys would be an improvement.
 > / and \ could be good for vertical size changes
 > and [,] for horizontal; they don't need a shift key.

On international keyboards you can be pretty sure that ascii letters
and decimal numerals won't need a shift key (unless the keyboard is in
ISO level 3 shift lock mode, in which case you are restricted to
numerals).  On all punctuation, except maybe period and comma, you
can't be sure.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>
>  > That seems basically good, but using other characters
>  > such as arrow keys would be an improvement.
>  > / and \ could be good for vertical size changes
>  > and [,] for horizontal; they don't need a shift key.
>
> On international keyboards you can be pretty sure that ascii letters
> and decimal numerals won't need a shift key

Some layouts have shifted digits.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stephen J. Turnbull]

Andreas Schwab writes:

 > Some layouts have shifted digits.

 > "And now for something completely different."

Your .sig generator deserves a raise for this!

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

     > That seems basically good, but using other characters
     > such as arrow keys would be an improvement.
     > / and \ could be good for vertical size changes
     > and [,] for horizontal; they don't need a shift key.

    On international keyboards you can be pretty sure that ascii letters
    and decimal numerals won't need a shift key (unless the keyboard is in
    ISO level 3 shift lock mode, in which case you are restricted to
    numerals).  On all punctuation, except maybe period and comma, you
    can't be sure.

Letters and numbers are not as good for this purpose than graphics
that have a clear symbolic meaning.  So we have a trade-off between
clear mnemonic choices and support for non-US keyboards.  I'm inclined
to choose the clear mnemonic choices, esp. since most keyboards
have arrow keys too.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> I usually don't know how by how many lines I want to expand/shrink a window,
> so I typically end up doing
> 
>    C-x ^ C-x ^ C-x ^
> 
> which is *really* inconvenient.  So a modal interface would reduce the
> number of necessary bindings to just 1, freeing the other keys for other
> uses, and it would be a lot more convenient for my use cases (hopefully I'm
> not the only one out there).

I agree. And a modal interface for this is of course exactly what 
bw-interactive.el is. Maybe you want to comment on the last version I sent?

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    Actually, I'd prefer to deprecate those bindings (along with C-x ^) and
    replace them with a binding that allows the user to do:

       M-x window-resize RET

    (which we'd of course bind to some key) and then

       ^ ^ ^ } } } } } { { { { } } ...
    or
       left left left up up up up up up up

I think that is worth trying.  To make it convenient we need
a key binding for window-resize.  How about C-x _?

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

>     Actually, I'd prefer to deprecate those bindings (along with
>     C-x ^) and replace them with a binding that allows the user to do:
>        M-x window-resize RET
>     (which we'd of course bind to some key) and then
>        ^ ^ ^ } } } } } { { { { } } ...
>     or  left left left up up up up up up up
>
> I think that is worth trying.  To make it convenient we need
> a key binding for window-resize.  How about C-x _?

FWIW - This is trivial to do with Do Re Mi. Function `doremi' lets you
increment or decrement anything repeatedly, using the arrow keys or a mouse
wheel (or both). It is made for this kind of thing.

In this case, we define two commands, `window-resize' and
`window-resize-horizontally', that use `doremi' to increment the height and
width, respectively. Left and right arrows are used for horizontal; up and
down arrows are used for vertical. Each command calls the other whenever the
arrow-key type changes (horizontal vs vertical). Only one of the commands
needs to be bound to a key - e.g. bind `window-resize' to `C-x _'.

Try it. You can get `doremi' here:
http://www.emacswiki.org/cgi-bin/wiki/doremi.el. Some doc is here:
http://www.emacswiki.org/cgi-bin/wiki/DoReMi. You can end either command by
hitting any key besides an arrow or the mouse wheel (e.g. `C-g').

These definitions are trivial, even if they might not appear trivial to
someone unfamiliar with `doremi' - they are typical. The first arg to
`doremi' is an incrementation (growth) function. The second arg is the
initial value. The third arg is the increment to pass to the growth
function. The growth function returns the new value, so that it can be
echoed to the user at each arrow key press.

(defun window-resize (&optional increment window)
  "Change height WINDOW incrementally.
INCREMENT is the size increment.
WINDOW is selected.  WINDOW defaults to the selected window."
  (interactive "p")
  (select-window (or window (selected-window)))
  (doremi (lambda (incr) (shrink-window incr) (window-height))
          (window-height) (- increment) t)
  (when (member (car unread-command-events)
                '(left right M-left M-right))
    (window-resize-horizontally increment window)))

(defun window-resize-horizontally (&optional increment window)
  "Change width of WINDOW incrementally.
INCREMENT is the size increment.
WINDOW is selected.  WINDOW defaults to the selected window."
  (interactive "p")
  (select-window (or window (selected-window)))
  (let ((doremi-up-key 'left)
        (doremi-boost-up-key 'M-left)
        (doremi-down-key 'right)
        (doremi-boost-down-key 'M-right))
    (doremi (lambda (incr) (shrink-window-horizontally incr)
                    (window-width))
            (window-width) nil t))
  (when (member (car unread-command-events)
                (list doremi-up-key doremi-down-key
                      doremi-boost-up-key doremi-boost-down-key))
    (window-resize increment window)))

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> > I think that is worth trying.  To make it convenient we need
> > a key binding for window-resize.  How about C-x _?

I just noticed that `C-x _' is what was suggested as the binding. I was
mistakenly thinking that `C-_' was proposed.

Please don't use `C-x _' for this. I've been using that for many years for
my `fit-frame' command.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > I think that is worth trying.  To make it convenient we need
>> > a key binding for window-resize.  How about C-x _?
>
> I just noticed that `C-x _' is what was suggested as the binding. I
> was mistakenly thinking that `C-_' was proposed.
>
> Please don't use `C-x _' for this. I've been using that for many years
> for my `fit-frame' command.

Huh?  What possible reason would there be to take your private personal
bindings into account when choosing the default out-of-the-box bindings
for Emacs?  It's not like you would be unable to override them if you
didn't like them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> >> > I think that is worth trying.  To make it convenient we need
> >> > a key binding for window-resize.  How about C-x _?
> >
> > I just noticed that `C-x _' is what was suggested as the binding. I
> > was mistakenly thinking that `C-_' was proposed.
> >
> > Please don't use `C-x _' for this. I've been using that for many years
> > for my `fit-frame' command.
>
> Huh?  What possible reason would there be to take your private personal
> bindings into account when choosing the default out-of-the-box bindings
> for Emacs?  It's not like you would be unable to override them if you
> didn't like them.

It's just a request. You are free to ignore it.

The fit-frame code has been around a long time, and I think a fair number of
people beyond myself might be used to that binding. The code is also
included in Aquamacs (but I don't know if that binding is). And Richard
expressed interest in adding the library to Emacs at one point - I believe
that a doc string change is all that he lacked.

None of those are reasons that compel anyone to not bind that key, but I
make the request anyway.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I think that is worth trying.  To make it convenient we need
>> a key binding for window-resize.  How about C-x _?
>
> FWIW - This is trivial to do with Do Re Mi. Function `doremi' lets you
> increment or decrement anything repeatedly, using the arrow keys or a
> mouse wheel (or both). It is made for this kind of thing.

I tested it and it worked okay.  But:

1. why using the <up> arrow key to increment the window vertical size?

2. It doesn't really take care of what border do you want to act on.

   The `resize-window' I proposed in this thread, while definitely ugly,
   moves the left border when you use the left key `l', the right border
   when you use the right key `r', etc.  It is the most usable solution
   I've tested so far.
   
-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> >> I think that is worth trying.  To make it convenient we need
> >> a key binding for window-resize.  How about C-x _?
> >
> > FWIW - This is trivial to do with Do Re Mi. Function `doremi' lets you
> > increment or decrement anything repeatedly, using the arrow keys or a
> > mouse wheel (or both). It is made for this kind of thing.
>
> I tested it and it worked okay.  But:
> 1. why using the <up> arrow key to increment the window vertical size?

You can use any key you want. By default, the `up' key increases a value,
and `down' decreases it.

In some cases, it is more logical (can seem more natural) to have `up'
decrease a value - for example, when it decreases frame height (it moves the
frame bottom up). In some cases, it is more logical to have `left' and
`right' increase/decrease a value - for example, to move a frame left/right
or to resize it horizontally.

When two dimensions are used, as for window or frame resizing or frame
positioning, it makes sense to have up/down do something vertical and
left/right do something horizontal.

In this case, if you prefer to use `up' to decrement instead of increment,
that might seem natural for a bottom window (the window bottom moves up) but
unnatural for a top or middle window. It can depend on whether you want to
think in terms of a particular window border moving (up/down) or the window
height/width increasing/decreasing. I chose `up' for increasing window
size - that makes sense for any window.

But again, choose whatever keys you like. To reverse the direction, replace
nil in the call to `doremi' by (- increment). To use `left'/`right', just
`let'-bind the key variables, as in the code I sent for
`window-resize-horizontally'.

(BTW, holding Meta down while you use the arrow keys or mouse wheel gives a
boost, multiplying the increment so change is quicker.)

> 2. It doesn't really take care of what border do you want to act on.

I don't know what you mean by "take care of what border". No, it simply
resizes the window, by calling `shrink-window(-horizontally)'. If that
function is not what you want, then use another that does what you want.

>    The `resize-window' I proposed in this thread, while definitely ugly,
>    moves the left border when you use the left key `l', the right border
>    when you use the right key `r', etc.  It is the most usable solution
>    I've tested so far.

Nothing wrong with that, if that's what you want.

My point was that Do Re Mi is completely general. You can use it to
increase/decrease anything incrementally (or use it to cycle among
enumeration values).

In this case, there was an existing incrementator, `shrink-window'
ready-to-hand. But Do Re Mi is just as easy to use if there is only an
absolute setting function instead of an incrementor. For example, you can
pass it a function that simply sets the window size, instead of incrementing
it - Do Re Mi will then take do the incrementing itself.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> But again, choose whatever keys you like. 

Thanks :)

>> 2. It doesn't really take care of what border do you want to act on.
>
> I don't know what you mean by "take care of what border". No, it simply
> resizes the window, by calling `shrink-window(-horizontally)'. If that
> function is not what you want, then use another that does what you want.

Take this window configuration:

|----------+----------+----------|
|          |          |          |
|          |          |          |
| Window 1 | Window 2 | Window 3 |
|          |          |          |
|          |          |          |
|----------+----------+----------|
           ^          ^
          (A)        (B)


Let's say the point is on the second Window.  When pressing the left
arrow key, you expect the border (A) will move to the left; pressing the
right arrow key makes you wait for the border (B) to move to the right.

This is what I mean by "taking care of what border to act upon", and
this is what does the version `resize-window' i proposed before.

>>    The `resize-window' I proposed in this thread, while definitely ugly,
>>    moves the left border when you use the left key `l', the right border
>>    when you use the right key `r', etc.  It is the most usable solution
>>    I've tested so far.
>
> Nothing wrong with that, if that's what you want.

Yes it is.  I was led to this by testing Lennart's bw-interactive.el,
which is also able to know what border to move.

> My point was that Do Re Mi is completely general. You can use it to
> increase/decrease anything incrementally (or use it to cycle among
> enumeration values).

This gave me the occasion to test doremi.el, and it's great.  I stumbled
on this in the emacswiki before -- the name intrigued me -- but I didn't
have time to play with it.  Done!

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    I tested it and it worked okay.  But:

    1. why using the <up> arrow key to increment the window vertical size?

"Up is more" is a common analogy.  Using it here could be a good idea
for simplicity's sake.  The most common case of changing window
sizes is with two windows.  So it is very convenient to be able
to specify "more" or "less" without saying which boundary.

There is more than one way to do that, I acknowledge.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> "Up is more" is a common analogy.  Using it here could be a good idea
> for simplicity's sake.  The most common case of changing window
> sizes is with two windows.  So it is very convenient to be able
> to specify "more" or "less" without saying which boundary.

Hmm, I'd think + and - would be the most natural here... ?

-miles
-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>> "Up is more" is a common analogy.  Using it here could be a good idea
>> for simplicity's sake.  The most common case of changing window
>> sizes is with two windows.  So it is very convenient to be able
>> to specify "more" or "less" without saying which boundary.
>
> Hmm, I'd think + and - would be the most natural here... ?

If we resize the window along two directions (horizontal vs. vertical)
then <up>/<down> or +/- (or whatever) is okay, because we just need a
way to increment/decrement the window size.

If we resize the window along *four* directions (corresponding to the
four window borders) then arrow keys should better keep their natural
meaning.  In this case, <up> should enlarge the window vertically by
pushing up its upper border, etc.

IMHO the primary question is not what bindings `window-resize' should
use, but whether it should be bi-directional or four-directional.

I think it should be four-directional, because it'd handle both
bi-directional cases and more complex stuff.  After all, we want
`window-resize' to do more than replacing C-x } C-x z z z z z ...

-- 
Bastien, going to Zzzz...

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Miles Bader]

Bastien <bzg@altern.org> writes:
> IMHO the primary question is not what bindings `window-resize' should
> use, but whether it should be bi-directional or four-directional.

Why does it need to choose one or the other?  It could have bindings for
both.

E.g. + and - for simple "increase/decrease size" (I guess it needs to
choose horizontal or vertical, but it could just use the "innermost"
window split) and arrow-keys for "nudge the window border in that
direction".

That sounds pretty useful to me.

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Miles Bader <miles@gnu.org> writes:

>> IMHO the primary question is not what bindings `window-resize' should
>> use, but whether it should be bi-directional or four-directional.
>
> Why does it need to choose one or the other?  It could have bindings
> for both.
>
> E.g. + and - for simple "increase/decrease size" (I guess it needs to
> choose horizontal or vertical, but it could just use the "innermost"
> window split) and arrow-keys for "nudge the window border in that
> direction".

FWIW, I think making both bi-directional and four-directional behaviors
available from `window-resize' will be somewhat confusing for the user.

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> If we resize the window along two directions (horizontal vs. vertical)
> then <up>/<down> or +/- (or whatever) is okay, because we just need a
> way to increment/decrement the window size.
>
> If we resize the window along *four* directions (corresponding to the
> four window borders)

That's 8 possibilities, BTW, since each border can move two directions.

> then arrow keys should better keep their natural
> meaning.  In this case, <up> should enlarge the window vertically by
> pushing up its upper border, etc.

Why necessarily pushing up its upper border?
`enlarge-window'/`shrink-window' don't behave like that. Why not be
consistent with what they do?

I'm not really arguing for one or the other. My point is that it is not
obvious which border movement is better, if the user justs asks to enlarge
the window.

> IMHO the primary question is not what bindings `window-resize' should
> use, but whether it should be bi-directional or four-directional.
>
> I think it should be four-directional, because it'd handle both
> bi-directional cases and more complex stuff.  After all, we want
> `window-resize' to do more than replacing C-x } C-x z z z z z ...

Assuming the window to resize is already chosen:

1. There is the choice of whether to increase or decrease the size, and the
choice of whether to do that horizontally or vertically - 4 possibilities.
FWIW, the Do Re Mi version uses the 4 arrows for those possibilities.

2. Alternatively, there can be a choice of which border to move and then
which way to move it (to increase the window size or decrease it). In this
case, there are 8 possibilities, not 4.

#1 doesn't specify which border gets moved. In the Do Re Mi version, that is
decided by `shrink-window'.

You could also opt for moving both borders in a given dimension (horizontal
or vertical), widening/narrowing or heightening/shortening equally in both
directions (left-right or up-down). Size change would then be in even
amounts, or else one border would be slightly privileged for odd amounts.

Or you could opt for something else. What is it that you want? What is this
thread really about?

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> Or you could opt for something else. What is it that you want? What is
> this thread really about?

Good question :)

1. I started to suggest using C-x _ for `shrink-window'.  We already
   have these keys: C-x {, C-x }, C-x ^ but C-x - is *not* the fourth
   logical element here; it's `shrink-window-if-larger-than-buffer'.

2. Lennart jumped in and pointed to bw-interactive.el, which does a 
   good job at resizing windows border-wise.

3. Richard added that C-x _ wasn't a good idea and that we could even
   consider drop the C-x { and C-x } keys if we have a better scheme for
   resizing windows.

4. Stefan suggested it might be a good idea to have something like a
   `resize-window' command that would spare us the hassle of repeating
   resizing commands too often.

5. Juanma sent a `resize-window' command he's been using "for years",
   suggesting that this could be improved by making it interact with
   windmove.el

6. I sent an updated (ugly) `resize-window' trying to use windmove.el to
   resize the windows borderwise.  This function does a similar job than
   bw-interactive.el, although it's a bit shorter.  It could be improved
   by binding the arrow keys instead of [ldur].

7. You proposed to use doremi.el as an example of what doremi.el can do
   when it comes to handling incremental actions.

7. The discussion sank into madness because of the confusion between
   what I called bi-directional and four-directional resizing schemes
   -- or size-wise and border-wise resizing schemes...

8. We still need to find an agreement on what resize-window should do
   and I pronounced myself in favor of the four-directional approach,
   provided we use arrow-keys for that. 

Next action: comment, test, improve and clean the latest `resize-window'
and see if everyone is happy with it!

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

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

Bastien wrote:
> 2. Lennart jumped in and pointed to bw-interactive.el, which does a 
>    good job at resizing windows border-wise.

I took the idea of using windmove to bw-interactive.el.

In addition to that I removed the minor mode and instead used 
overriding-terminal-local-map directly (I was on my way to do that 
earlier, but I forgot it).

I also changed the feedback to the user slightly.


*** Some old and new comments on the "whys" of bw-interactive.el:

- Using a keymap directly gives the user more freedom to choose the 
bindings.

- Getting resizing and balancing together in one key binding seems good.

- Choosing border before resizing is essential. I guess most users will 
find this familiar.

- The visual feedback is now in two forms: mode-line color (a bit better 
than before), mouse pointer movement. In addition to that I would like 
mouse pointer shape changes, but that seems like a bigger job to me. Or 
am I wrong?

- Exiting is flexible, similar to that in isearch.

[-- Attachment #2: bw-interactive.el --]
[-- Type: text/plain, Size: 12471 bytes --]

;;; bw-interactive.el --- Functions for interactive resize of windows
;;
;; Description:
;; Author: Lennart Borgman <lennart dot borgman dot 073 at student at lu at se>
;; Maintainer:
;; Created: Wed Dec 07 15:35:09 2005
;; Version: 0.91
;; Last-Updated: Sat Nov 03 17:32:16 2007 (3600 +0100)
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This file contains functions for interactive resizing of Emacs
;; windows. To use it put it in your `load-path' and add the following
;; to your .emacs:
;;
;;     (require 'bw-interactive)
;;     (global-set-key [(control x) ?+] 'bw-enter-resizing)
;;
;; Typing "C-x +" will now enter a temporary mode for resizing windows.
;; For more information see `bw-enter-resizing'.
;;
;; These functions were the second part of my proposal for a new
;; `balance-windows' function for Emacs. These second part were not
;; accepted into Emacs 22, but you can use this module instead to get
;; the functionality. It requires Emacs 22 from 2006 or later.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; TODO: Change mouse pointer shape during resizing.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:


(defun bw-balance-windows ()
  "Call `balance-windows' and exit window resizing."
  (interactive)
  (balance-windows)
  (bw-exit-resize-state nil))

(defun bw-balance-siblings ()
  "Make current window siblings the same height or width."
  (interactive)
  (balance-windows (selected-window))
  (bw-exit-resize-state nil))

(defun bw-shrink-window ()
  "Shrink the window to be as small as possible to display its contents."
  (interactive)
  (fit-window-to-buffer nil (window-height))
  (bw-exit-resize-state nil))

(defun bw-exit-resize-other ()
  "Exit window resizing."
  (interactive)
  (bw-exit-resize-state t))

(defun bw-exit-resize-state(put-back-last-event)
  (setq bw-window-resize-state nil)
  (setq overriding-terminal-local-map bw-old-overriding-terminal-local-map)
  (setq overriding-local-map-menu-flag bw-old-overriding-local-map-menu-flag)
  (setq bw-window-to-resize nil)
  (when (frame-live-p bw-frame)
    (set-face-attribute 'mode-line-inactive bw-frame :background bw-old-mode-line-inactive-bg)
    (set-face-attribute 'mode-line bw-frame :background bw-old-mode-line-bg))
  (message "Exited window resizing")
  (when (and put-back-last-event)
    ;; Add this to the input queue again:
    (isearch-unread last-command-event)))

(defvar bw-keymap
  (let ((map (make-sparse-keymap "Window Resizing")))
    (define-key map [menu-bar bw]
      (cons "Resize" (make-sparse-keymap "second")))
    (define-key map [menu-bar bw shrink]
      '("Shrink to Buffer" . bw-shrink-window))
    (define-key map [menu-bar bw siblings]
      '("Balance Window Siblings" . bw-balance-siblings))
    (define-key map [menu-bar bw balance]
      '("Balance Windows" . bw-balance-windows))
    (define-key map [t]  'bw-exit-resize-other)
    (define-key map [?+] 'bw-balance-windows)
    (define-key map [?.] 'bw-balance-siblings)
    (define-key map [?-] 'bw-shrink-window)
    (define-key map [(up)]    'bw-resize-up)
    (define-key map [(down)]  'bw-resize-down)
    (define-key map [(left)]  'bw-resize-left)
    (define-key map [(right)] 'bw-resize-right)
    map)
  "Keymap used during window resizing.")

(defvar bw-window-to-resize nil
  "Window selected for resizing.")
(defvar bw-frame nil "Frame for resizing.")


(defun bw-enter-resizing ()
  "Start window resizing.
During window resizing these keys are defined:
\\<bw-keymap>
\\{bw-keymap}

Arrow keys may both select border to move and resize window. See
`bw-resize-left' for an explanation of how the arrow keys
work.

All other keys exits window resizing."
  (interactive)
  (if (= 1 (length (window-list)))
      (message "There is only one window on this frame, can't resize that")
    (setq bw-window-for-side-hor nil)
    (setq bw-window-for-side-ver nil)
    (setq bw-window-to-resize (selected-window))
    (setq bw-frame (selected-frame))
    ;; Fix-me: use copy-keymap for old?
    (setq bw-old-overriding-terminal-local-map overriding-terminal-local-map)
    (setq overriding-terminal-local-map (copy-keymap bw-keymap))
    (setq bw-old-overriding-local-map-menu-flag overriding-local-map-menu-flag)
    (setq overriding-local-map-menu-flag t)
    (setq bw-old-mode-line-inactive-bg (face-attribute 'mode-line-inactive :background))
    (setq bw-old-mode-line-bg (face-attribute 'mode-line :background))
    (setq bw-window-resize-state t)
    (let ((left   (bw-window-beside (selected-window) 0))
          (top    (bw-window-beside (selected-window) 1))
          (right  (bw-window-beside (selected-window) 2))
          (bottom (bw-window-beside (selected-window) 3)))
      (if (< 1 (length (delq nil (list left top right bottom))))
          (progn
            (bw-move-mouse-to-middle)
            (set-face-attribute 'mode-line-inactive bw-frame :background "#ff0000")
            (set-face-attribute 'mode-line bw-frame :background "#ff0000")
            (message "Arrows: select border, +/./- : balance windows/siblings/fit, other: quit")
            )
        (when left   (bw-resize -1 t))
        (when top    (bw-resize -1 nil))
        (when right  (bw-resize 1 t))
        (when bottom (bw-resize 1 nil))
        (bw-start-resizing)))))

(defun bw-help-message ()
  (message "Arrows: resize, +/./-: balance windows/siblings/fit, other: quit"))

(defun bw-start-resizing ()
  (bw-help-message)
  (set-face-attribute 'mode-line-inactive bw-frame :background "#ffa500")
  (set-face-attribute 'mode-line bw-frame :background "#ffa500"))

(defvar bw-window-for-side-hor nil
  "Window used internally for resizing in horizontal direction.")

(defvar bw-window-for-side-ver nil
  "Window used internally for resizing in vertical direction.")

(defun bw-resize-left ()
  "Choose border to move. Or if border is choosen move that border.
When entering window resizing Emacs first need to know which
border to move. If there are several possible borders then the
first call to this function (or its siblings
`bw-resize-right', `bw-resize-top' and
`bw-resize-bottom') will choose border.

When the border is choosen this function moves that border to the left.

Note 1: This function of course only works for vertical borders.

Note 2: The behaviour is modelled after how some GUI window
managers do similar resizing."
  (interactive)(bw-resize -1 t))

(defun bw-resize-right ()
  "See `bw-resize-left'."
  (interactive)(bw-resize 1  t))

(defun bw-resize-up ()
  "See `bw-resize-left'."
  (interactive)(bw-resize -1 nil))

(defun bw-resize-down ()
  "See `bw-resize-left'."
  (interactive)(bw-resize 1  nil))

(defun bw-window-beside(window side)
  "Return a window directly beside WINDOW at side SIDE.
That means one whose edge on SIDE is touching WINDOW.  SIDE
should be a number corresponding to positions in the values
returned by 'window-edges'."
  (let* ((windmove-wrap-around nil)
         (win (windmove-find-other-window
              (cond
               ((= side 0) 'left)
               ((= side 1) 'up)
               ((= side 2) 'right)
               ((= side 3) 'down)
               ))))
    (unless (window-minibuffer-p win)
      win)))
;; (defun bw-window-beside-old(window side)
;;   (let ((start-window window)
;;         (start-left   (nth 0 (window-edges window)))
;;         (start-top    (nth 1 (window-edges window)))
;;         (start-right  (nth 2 (window-edges window)))
;;         (start-bottom (nth 3 (window-edges window)))
;; 	above-window)
;;     (setq window (previous-window window 0))
;;     (while (and (not above-window) (not (eq window start-window)))
;;       (let (
;;             (left   (nth 0 (window-edges window)))
;;             (top    (nth 1 (window-edges window)))
;;             (right  (nth 2 (window-edges window)))
;;             (bottom (nth 3 (window-edges window)))
;;             )
;;         (if (or (= side 0) (= side 2))
;;             (when (and (if (= side 0) (= right start-left) (= left start-right))
;;                        (or (and (<= top start-top)    (<= start-bottom bottom))
;;                            (and (<= start-top top)    (<= top start-bottom))
;;                            (and (<= start-top bottom) (<= bottom start-bottom))))
;;               (setq above-window window))
;;           (when (and (if (= side 1) (= bottom start-top) (= top start-bottom))
;;                      (or (and (<= left start-left)  (<= start-right right))
;;                          (and (<= start-left left)  (<= left start-right))
;;                          (and (<= start-left right) (<= right start-right))))
;;             (setq above-window window))))
;;       (setq window (previous-window window)))
;;     above-window))

(defun bw-resize(arg horizontal)
  "Choose border to move. Or if border is choosen move that border.
If HORIZONTAL is non-nil use the border earlier selected for
horizontal resizing, otherwise use the one for vertical resizing.

If ARG is -1 move border to the left or up, depending on
HORIZONTAL. If ARG is 1 move border to the right or down.

Used by `bw-resize-left' etc."
  (unless (= (* arg arg) 1)
    (error "ARG must be -1 or 1"))
  (let* ((bw-side (if horizontal 'bw-window-for-side-hor 'bw-window-for-side-ver))
         (bside (if horizontal
                    (if (< arg 0) 0 2)
                 (if (< arg 0) 1 3)))
         (window-beside (bw-window-beside (selected-window) bside)))
    (if (not (symbol-value bw-side))
        (progn
          (unless window-beside
            ;; Just take the window in the other direction then.
            (setq bside (mod (+ bside 2) 4))
            (setq window-beside (bw-window-beside (selected-window) bside))
            (setq arg (- arg)))
          (when (> arg 0) (setq window-beside (selected-window)))
          (bw-start-resizing)
          (set bw-side window-beside))
      (when bw-window-resize-state
        (condition-case err
            (adjust-window-trailing-edge (symbol-value bw-side) arg horizontal)
          (error (message "%s" (error-message-string err)))
          )))
    (when (= 1 (length (window-list))) (bw-exit-resize-state nil))
    (when (and bw-window-resize-state)
      (bw-help-message)
      (bw-move-mouse-to-resized))))

(defun bw-move-mouse-to-middle ()
  "Move mouse to the middle of the window to resize."
    (let ((bw-window-for-side-hor nil)
          (bw-window-for-side-ver nil))
      (bw-move-mouse-to-resized)))

(defun bw-move-mouse-to-resized ()
  "Move mouse to the border beeing moved in interactive resize."
  (let* ((edges (window-edges))
         (L (nth 0 edges))
         (T (nth 1 edges))
         (R (nth 2 edges))
         (B (nth 3 edges))
         (x (/ (+ L R) 2))
         (y (/ (+ T B) 2)))
    (when bw-window-for-side-hor
      (setq x (if (eq (selected-window) bw-window-for-side-hor) (- R 1) (- L 1))))
    (when bw-window-for-side-ver
      (setq y (if (eq (selected-window) bw-window-for-side-ver) (- B 1) (- T 1))))
    (set-mouse-position (selected-frame) x y)))


(defvar bw-old-mode-line-bg nil)
(defvar bw-old-mode-line-inactive-bg nil)
(defvar bw-old-overriding-terminal-local-map nil)
(defvar bw-old-overriding-local-map-menu-flag nil)
(defvar bw-window-resize-state t)


(provide 'bw-interactive)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; bw-interactive.el ends here

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

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    > "Up is more" is a common analogy.  Using it here could be a good idea
    > for simplicity's sake.  The most common case of changing window
    > sizes is with two windows.  So it is very convenient to be able
    > to specify "more" or "less" without saying which boundary.

    Hmm, I'd think + and - would be the most natural here... ?

+ would be good for "up" if there were only one dimension involved.
But we want commands for growing and shrinking, vertically and
horizontally.  Just + and - are not enough.

    E.g. + and - for simple "increase/decrease size" (I guess it needs to
    choose horizontal or vertical, but it could just use the "innermost"
    window split) and arrow-keys for "nudge the window border in that
    direction".

If using the innermost window split is good enough as regards the
choice of dorection, maybe just + and - are sufficient.

Bastien said: 

    FWIW, I think making both bi-directional and four-directional behaviors
    available from `window-resize' will be somewhat confusing for the user.

I don't agree.  If they are clearly different kinds of characters
(like + and - vs arrows), I think users will understand they work
differently.

We could give it a try and see what users think of it.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

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

Richard Stallman <rms@gnu.org> writes:

> We could give it a try and see what users think of it.

Here is another try.  

It uses the arrow keys to push borders and -/+ for raw
shrinking/enlarging.  I've also added other keys like 
`s' to store a window configuration and '_' to call 
it back.  See the docstring for details.

Feedback welcome.


[-- Attachment #2: window-reorganize.el --]
[-- Type: application/emacs-lisp, Size: 2750 bytes --]

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


-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

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

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> > We could give it a try and see what users think of it.
> 
> Here is another try.  
> 
> It uses the arrow keys to push borders and -/+ for raw
> shrinking/enlarging.  I've also added other keys like 
> `s' to store a window configuration and '_' to call 
> it back.  See the docstring for details.
> 
> Feedback welcome.

I like it, in general. 

Some quick minor feedback:

* Use `case' (compile-time require cl) to simplify code.
* Why is WCF an arg? (You immediately set it.)
* Bind `echo-keystrokes' to 0.
* Let `0' delete the selected window.
* Not sure `1' is a good idea (especially if no undo).
* Maybe `r' instead of `_'?
* When window reaches a minimum, trying to reduce it 
  more either moves it instead or deletes it instead.
  Maybe do something different (e.g. nothing?).
* +/- is only for vertical resizing. Why not horizontal
  also? Maybe let arrows do this also, with another key
  toggling the mode (move border vs increase/decrease
  size).
* Maybe let Shift always navigate - up/down/left/right,
  and use something else (`+' and `-'?) to
  increment/decrement ARG.
* Maybe negate (toggle sign of) ARG with a keystroke
  (e.g. `~'), instead of holding Meta down. (Modal.)
* And maybe let C-N (N an integer) set ARG absolutely?
* Maybe let mouse-1 select a window also.
* Maybe use mouse wheel also (if direction is known)?
* The prompt doesn't express much of what is possible.
  In particular, if `one-window-p', the prompt makes
  no sense (but `2' and `3' still make sense).
* Let `?' provide more help.
* Give confirmation message when save & restore.
  When save, it should mention `_' (or `r') to restore.
* Is it normal that the window is scrolled (perhaps to
  keep point in view)? Maybe not scrolling should be
  an option?
* Maybe let unrecognized events (keys, at least) quit
  instead of being ignored. And then perhaps be
  applied? So, e.g., `RET' would quit (and insert a
  newline?).
* Rename?  `window-edit'?
* Maybe bind it to `C-x w'. Or maybe have that be a
  prefix for several window commands and bind this one
  to `C-x w e' (for edit)?

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Hi Drew,

"Drew Adams" <drew.adams@oracle.com> writes:

> Some quick minor feedback:

Thanks very much for the useful suggestions, I will work on them.  

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

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

Hi,

I attach window-edit.el at the end of this email.  window-edit.el
contains only one function: M-x window-edit.  

I tried to implement Drew suggestions into one single function.  
See my comments below.  Any feedback is very welcome.

"Drew Adams" <drew.adams@oracle.com> writes:

> Some quick minor feedback:
>
> * Use `case' (compile-time require cl) to simplify code.

I didn't use it yet.

> * Why is WCF an arg? (You immediately set it.)

Fixed.

> * Bind `echo-keystrokes' to 0.

Done.

> * Let `0' delete the selected window.

Done.

> * Not sure `1' is a good idea (especially if no undo).

Yes, right, fixed.

> * Maybe `r' instead of `_'?

Yes.  Window configurations are now stored into a ring, so pressing `r'
twice will call back wcf2 then wcf1 if wcf1 and wcf2 were stored.  The
first config in this ring is the initial one.

> * When window reaches a minimum, trying to reduce it 
>   more either moves it instead or deletes it instead.
>   Maybe do something different (e.g. nothing?).

Fixed.  Hence the ugly part of the defun.  I couldn't figure out how to
factorize all this a bit yet.  Suggestions welcome.

> * +/- is only for vertical resizing. Why not horizontal
>   also? Maybe let arrows do this also, with another key
>   toggling the mode (move border vs increase/decrease
>   size).

SPC will toggle the mode.  See the docstring.

> * Maybe let Shift always navigate - up/down/left/right,
>   and use something else (`+' and `-'?) to
>   increment/decrement ARG.

Right. S-<arrow> now navigates through windows direction-wise.

> * Maybe negate (toggle sign of) ARG with a keystroke
>   (e.g. `~'), instead of holding Meta down. (Modal.)

Done.

> * And maybe let C-N (N an integer) set ARG absolutely?

Done.

> * Maybe let mouse-1 select a window also.

Done.

> * Maybe use mouse wheel also (if direction is known)?

Not done yet.   Don't know if this is really useful.

> * The prompt doesn't express much of what is possible.
>   In particular, if `one-window-p', the prompt makes
>   no sense (but `2' and `3' still make sense).

Fixed, even though there is room for improvement.

> * Let `?' provide more help.

Done.

> * Give confirmation message when save & restore.
>   When save, it should mention `_' (or `r') to restore.

Done.

> * Is it normal that the window is scrolled (perhaps to
>   keep point in view)? Maybe not scrolling should be
>   an option?

Fixed, but it's not an option.

> * Maybe let unrecognized events (keys, at least) quit
>   instead of being ignored. And then perhaps be
>   applied? So, e.g., `RET' would quit (and insert a
>   newline?).

Not done.  Will work on this later.  Depends on feedback about this
defun.

> * Rename?  `window-edit'?

Good suggestion, done.

> * Maybe bind it to `C-x w'. Or maybe have that be a
>   prefix for several window commands and bind this one
>   to `C-x w e' (for edit)?

I let this to the user.

Thanks again for the detailed suggestions.  That was very helpful.  I
hope this function is closer that one might expect from window-edit.


[-- Attachment #2: window-edit.el --]
[-- Type: application/emacs-lisp, Size: 8627 bytes --]

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


-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

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

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> I tried to implement Drew suggestions into one single function.
> See my comments below.  Any feedback is very welcome.

Thanks for working some more on this. I didn't expect that you would
implement most of what I suggested - they were just some ideas that occurred
to me. Anyway, here is some more feedback to think about:

I have a window config created by `window-edit 3 2 3 2'. I start with the
cursor in the middle window at the left of the frame.

1. When I use `?', I get a new frame *window-edit help* (I use non-nil
`pop-up-frames'). If I click mouse-1 in that frame, then the frame
disappears. That's no good. I need to be able to go to the help frame, move
around, select text, etc.

2. When help is shown, the window configuration should be left as is, if
`pop-up-frames' is non-nil. That is, there is no need to change it to a
single window.

3. Need more help in the help window. For instance, what do the arrows do,
by default? What does the prefix arg do?

4. Window resizing with arrows works fine. I see problems with border
movement, however:

a.  Bug (?): Cursor in middle-left window. `down' increases the window size,
as does ` `up': both move the upper border up.

b. Bug (?): Arrows with cursor in bottom-left window affect only the
middle-left window above it (and not even the common border): `up' moves
that window's top border down; `down' moves it up. And `down' moves the
cursor (focus) to that middle window (but `up' does not).

c. Bug (?): Similarly, try to use `left' arrow on the rightmost window. That
doesn't move either of its borders; instead, it moves the left border of the
middle-top window to the right. The `right' arrow correctly moves the right
window's left border to the right. One can work around this by negating the
increment with `~' (because the problem/bug is then reversed). But the
behavior is wrong, IMO.

d. Bug (?): Increase middle-left window to its max size, so you get the
[can't move up] message. Then put cursor in middle-top window and use
`down'. That moves the cursor to the middle-left window and tries to
increase it. There is no [can't move...] message, and the arrow in that
window has no effect. What should happen is the top-left window should grow
along with the bottom border moving down. Or at least something intuitive
should happen. Or at least the user should get some feedback about what is
going wrong.

e. Bug (?): Increase middle-left window to its max size, so you get the
[can't move up] message. Then try to move the lower border `down'. Nothing
happens - no feedback, no movement. The border (common to middle-top window)
should be moved down.

f. Whenever an arrow key cannot move a border for some reason, the user
should get feedback explaining why. For instance, in a window that is
full-frame height, you cannot move a border up or down, but there is no
message.

g. There is still the problem that moving a border can make windows
disappear because they get too small. To me, that's not the right behavior.
They should respect `window-min-width' and `window-min-height' - you should
get a "can't move..." message if the requested movement tries to undercut
these limits.

6. In general, border-movement mode seems inconsistent - or at least it is
unclear to me what the arrows do: which border is moved which way. Please
have a look a this again.

7. The binding of `echo-keystrokes' is not working. If I move the focus to
another window-manager window (e.g. this mail message, outside Emacs), then
I see a long string of keystrokes filling the echo area. Maybe move the
binding higher up?

8. +/- should go directly from 1 to -1, skipping 0, since 0 is a no-op for
resizing and border movement.

9. The prompt is still not general enough, IMO. Consider moving the feedback
regarding (1) the current mode (resize vs border-movement) and (2) error
messages to the mode line as a temporary display. The prompt can include
"[023=+-~srq? (S-)arrows]" as a reminder. I know you are most interested in
border movement, but that is the least likely thing users will use this for,
IMO - the prompt should emphasize 0, 2, 3, and = as much as the arrows, and
it should definitely mention `q' and `?'.

10. Change "negate argument" to "negate increment". Change ARG everywhere to
"INCREMENT", for clarity. And put ~ next to +/- in the help and the doc
string, so it's clearer that they all apply to the increment.

11. Let the arrows resize instead of move borders, by default. Resizing is
much easier to understand and works for 80% of what someone wants to do.
Consider border movement as an "advanced" mode. It is a mistake to dump a
user directly into border-movement mode, IMO.

12. Cursor in right window, `S-down' - no message. Instead, cursor moves to
bottom-left window. Another `S-down' - still no message - and no more cursor
movement.

13. Apparently, the cursor position within a window determines which window
to move to with `S-<arrow>'. That's a bonus. However, for that to be
worthwhile, you need to allow `mouse-1' to set point. Example. With cursor
in right window below midline window divider, `S-left' sends cursor to
lower-left window. With cursor above midline, it sends it to middle-top
window. That's good, but you should be able, with cursor below midline, to
click mouse-1 above midline and then do `S-left' to move to middle-top
window.

14. Yes, that is not very important, because if you can click above then you
can also click in the window you want. However, you might want to let `C-b',
`C-f', `C-p', and `C-n' move point to enable control over `S-<arrow>'. That
can be useful when there are multiple windows. For example, depending on
where the cursor is and the line length of where it is moved to by `S-down',
if you move from the middle-top window to the left-bottom window and then
back up by `S-up', you might end up in the middle-left window or the
middle-top window.

15. At the very least, this behavior needs to be explained to the user -
s?he needs to know that the cursor position wrt the window divider
determines the destination window. And s?he needs to know about the
line-length thing: if the cursor position in the frame is to the right of
the line length of the middle line in the destination window, then it will
be moved to the middle-line end, which might move it across the window
divider.

> > * Use `case' (compile-time require cl) to simplify code.
>
> I didn't use it yet.

It's simple:

(case e
  (left (if...)
  (right (if...)
  (up (if...)
  (down (if...))

(case e
  (?0 (delete-other-windows))
  (?2 ...)
  (?3 ...)
  (?o ...)
  ...
  (S-right ...)
  (S-down ...)
  ...
  ((?h ??) (let...)))

You might have to juggle a couple of pieces that aren't just constant
comparisons, but `case' will otherwise make the code more readable, IMO. (To
juggle them, you can use `case's `otherwise' clause with a `cond' of `if'.)

> Yes.  Window configurations are now stored into a ring, so pressing `r'
> twice will call back wcf2 then wcf1 if wcf1 and wcf2 were stored.  The
> first config in this ring is the initial one.

Please make this clearer in the doc string and help. It's there, but it's
not obvious.

> > * When window reaches a minimum, trying to reduce it
> >   more either moves it instead or deletes it instead.
> >   Maybe do something different (e.g. nothing?).
>
> Fixed.  Hence the ugly part of the defun.  I couldn't figure out how to
> factorize all this a bit yet.  Suggestions welcome.

See above. It still doesn't seem fixed to me.

> > * Maybe let Shift always navigate - up/down/left/right,
> >   and use something else (`+' and `-'?) to
> >   increment/decrement ARG.
>
> Right. S-<arrow> now navigates through windows direction-wise.
>
> > * And maybe let C-N (N an integer) set ARG absolutely?
>
> Done.

Please document it. The doc string and `?' help say nothing about the prefix
arg.

> > * Maybe let mouse-1 select a window also.
>
> Done.

`mouse-1' should set point, in whatever window.

> > * Maybe use mouse wheel also (if direction is known)?
>
> Not done yet.   Don't know if this is really useful.

Probably not.

> > * The prompt doesn't express much of what is possible.
> >   In particular, if `one-window-p', the prompt makes
> >   no sense (but `2' and `3' still make sense).
>
> Fixed, even though there is room for improvement.

Yes, see above. The prompt should indicate the most useful/common
keystrokes, and it should definitely indicate `q' and `?'. Other helpful
info that is now in the prompt could be moved to the mode-line (as a
temporary display).

> > * Maybe let unrecognized events (keys, at least) quit
> >   instead of being ignored. And then perhaps be
> >   applied? So, e.g., `RET' would quit (and insert a
> >   newline?).
>
> Not done.  Will work on this later.  Depends on feedback about this
> defun.

Looking good, IMO. The most important thing to take care of is the behavior
of arrows for moving borders: it's not understandable and is apparently
somewhat inconsistent (bugged).

HTH & thx.

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

Sorry, I forgot one: `0' should delete only the current window, as in `C-x
0'. It seems instead to do `C-x 1'.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I tried to implement Drew suggestions into one single function.
>> See my comments below.  Any feedback is very welcome.
>
> Thanks for working some more on this. I didn't expect that you would
> implement most of what I suggested - they were just some ideas that occurred
> to me. Anyway, here is some more feedback to think about:

Please check the latest window-edit.el here:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

Window shrinking/enlarging is okay.  

Borders moving might be somewhat inconsistent, but I could find any easy
way to predict the changes made by `shrink-window' and `enlarge-window'
in all possible window configurations.  Anyway, this should be accurate
in 95% of the real-life cases, and I do agree that the resize-mode will
be the most useful anyway.

> 1. When I use `?', I get a new frame *window-edit help* (I use non-nil
> `pop-up-frames'). If I click mouse-1 in that frame, then the frame
> disappears. That's no good. I need to be able to go to the help frame, move
> around, select text, etc.

I'm not sure about this.  The help window is now quite big, and people
using window-edit with a lot of windows might prefer not to loose their
configuration just by displaying the help window.

Hitting `?' once will first show a small help message, depending on 
the mode you're on.  Then hitting `?' again will display the window 
help.

> 2. When help is shown, the window configuration should be left as is, if
> `pop-up-frames' is non-nil. That is, there is no need to change it to a
> single window.

Fixed.

> 3. Need more help in the help window. For instance, what do the arrows do,
> by default? What does the prefix arg do?

I tried to improve this.

> 4. Window resizing with arrows works fine. I see problems with border
> movement, however:

Most of the bugs should be fixed now.

> f. Whenever an arrow key cannot move a border for some reason, the user
> should get feedback explaining why. For instance, in a window that is
> full-frame height, you cannot move a border up or down, but there is no
> message.

Fixed.  Let me know what you think.

> g. There is still the problem that moving a border can make windows
> disappear because they get too small. To me, that's not the right behavior.
> They should respect `window-min-width' and `window-min-height' - you should
> get a "can't move..." message if the requested movement tries to undercut
> these limits.

Fixed.

> 7. The binding of `echo-keystrokes' is not working. If I move the focus to
> another window-manager window (e.g. this mail message, outside Emacs), then
> I see a long string of keystrokes filling the echo area. Maybe move the
> binding higher up?

I already set (echo-keystrokes 0) - what can I do?

> 8. +/- should go directly from 1 to -1, skipping 0, since 0 is a no-op for
> resizing and border movement.

Fixed.

> 9. The prompt is still not general enough, IMO. 

Please comment the new prompt.

> 10. Change "negate argument" to "negate increment". Change ARG everywhere to
> "INCREMENT", for clarity. And put ~ next to +/- in the help and the doc
> string, so it's clearer that they all apply to the increment.

Done.

> 11. Let the arrows resize instead of move borders, by default. 

Done.

> 12. Cursor in right window, `S-down' - no message. Instead, cursor moves to
> bottom-left window. Another `S-down' - still no message - and no more cursor
> movement.

Fixed.

> However, you might want to let `C-b', `C-f', `C-p', and `C-n' move
> point to enable control over `S-<arrow>'.

Added.

> It's simple:
>
> (case e
>   (left (if...)
>   (right (if...)
>   (up (if...)
>   (down (if...))

Done.

> `mouse-1' should set point, in whatever window.

Not yet done.  I will do this if the new window-edit.el if I have more
feedback on window-edit.el, I need to be sure this is going somewhere.

Thanks,

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> Please check the latest window-edit.el here:
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el
>
> > 1. When I use `?', I get a new frame *window-edit help* (I use non-nil
> > `pop-up-frames'). If I click mouse-1 in that frame, then the frame
> > disappears. That's no good. I need to be able to go to the help
> > frame, move around, select text, etc.
>
> I'm not sure about this.  The help window is now quite big, and people
> using window-edit with a lot of windows might prefer not to loose their
> configuration just by displaying the help window.

I cannot see all of the text in the pop-up frame, and if I try to use the
mouse to resize the frame, the frame disappears - very user unfriendly.

To handle this for users with `pop-up-frames' non-nil as well as other
users, just use (with-output-to-temp-buffer "*Help*" ...), and don't read an
event to delete the buffer/window/frame. Users can use `q' in *Help* to get
rid of it, as usual. You can use `princ' to insert text in *Help*. The code
is also simpler that way - no switch-to-buffer-other-window, no
get-buffer-create, etc.

BTW, I don't see where you ever use `display-help-window', but you set
`last-command' to it - why? Is that a typo for `display-help-message'?

> Hitting `?' once will first show a small help message, depending on
> the mode you're on.

It doesn't tell you about SPC to switch mode.

> Then hitting `?' again will display the window help.

If you try the *Help* window suggested above, I don't think you'll need two
levels of help.

> > 3. Need more help in the help window. For instance, what do the
> arrows do,
> > by default? What does the prefix arg do?
>
> I tried to improve this.

Dunno, I can't see it (see above) ;-).

Well, I can read it in the source code. Looks OK. Perhaps "toggle" instead
of "switch". Perhaps "next window in arrow direction" instead of "jump
to..." Be consistent with letter case for "INCREMENT". "quit" is sufficient.
`other-window' is clearer for `o'. "C-f C-b" should be "C-f, C-b" to avoid
confusion with a two-key sequence. And "moving a border", not "moving its
borders" (only one is moved).

> > f. Whenever an arrow key cannot move a border for some reason, the user
> > should get feedback explaining why. For instance, in a window that is
> > full-frame height, you cannot move a border up or down, but there is no
> > message.
>
> Fixed.  Let me know what you think.

No, still no message for not being able to move border down in full-height
window.

And I still see the problem that trying to move a border of one window
instead moves a border of another window. E.g. window-edit 3 2 3 2, as
before, then put cursor in middle-top window and try to move border `down'.
The border between the top-left and middle-left window is instead moved
`up' - no relation to what is requested.

Also, in move-border mode, with cursor in right window, `left' moves both
the window's left border left (correct) and the other two vertical borders,
between top-left/middle-left and middle-left.

I think the border movement generally still has some some problems.

> > g. There is still the problem that moving a border can make windows
> > disappear because they get too small. To me, that's not the
> right behavior.
> > They should respect `window-min-width' and `window-min-height'
> - you should
> > get a "can't move..." message if the requested movement tries
> to undercut
> > these limits.
>
> Fixed.

I still see the problem: With cursor in bottom-left window, use `up'
repeatedly. Eventually, the top-left window disappears (there is no "can't
move" message).

> > 7. The binding of `echo-keystrokes' is not working. If I move
> the focus to
> > another window-manager window (e.g. this mail message, outside
> Emacs), then
> > I see a long string of keystrokes filling the echo area. Maybe move the
> > binding higher up?
>
> I already set (echo-keystrokes 0) - what can I do?

Move the binding to your first `let' - that takes care of it.

Also, C-N works only for positive N, not negative N. I tried C- - 1, and it
just removed all windows (like C-x 1), because the C- - was ignored. That's
OK, but if if that's the way it is, then the doc should say "N > 0".

> > 9. The prompt is still not general enough, IMO.
>
> Please comment the new prompt.

OK by me.

You might need to require `cl' at compile time, for macro `case' (but there
was some talk of adding that to Emacs - maybe that was already done).

Possibility: When you restore the last window config, first save the current
config at the end of the ring. That way, `s'.changes.`r'.`r' will bring back
the config before the first restoration.

It would be helpful if the feedback told you which window config was
saved/restored. E.g. saved config #2, restored config #4 etc. That gives you
an idea where you are in the ring.

> > `mouse-1' should set point, in whatever window.
>
> Not yet done.  I will do this if the new window-edit.el if I have more
> feedback on window-edit.el, I need to be sure this is going somewhere.

Looks good to me. Hope you get input from others. Thanks for making the
changes.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Hi Drew,

thanks for the comments.  Here is a new version:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

"Drew Adams" <drew.adams@oracle.com> writes:

> I cannot see all of the text in the pop-up frame, and if I try to use
> the mouse to resize the frame, the frame disappears - very user
> unfriendly.

Please test the new help mechanism.

The problem is that I don't know how to prevent Emacs from waiting an
event when the user select another frame, and making it wait for this
event when back to the frame where (read-event) was first called.

Any hint?

> No, still no message for not being able to move border down in
> full-height window.

This should be better now.

> I think the border movement generally still has some some problems.

Hopefully I made some progress on this front as well.  It was tricky
before knowing about `adjust-window-trailing-edge'.

> I still see the problem: With cursor in bottom-left window, use `up'
> repeatedly. Eventually, the top-left window disappears (there is no
> "can't move" message).

There still might be some oddities like that, I'll check when I've more
time.  

> Also, C-N works only for positive N, not negative N. I tried C- - 1, and it
> just removed all windows (like C-x 1), because the C- - was ignored. That's
> OK, but if if that's the way it is, then the doc should say "N > 0".

I update the docstring and the help window.

> Possibility: When you restore the last window config, first save the current
> config at the end of the ring. That way, `s'.changes.`r'.`r' will bring back
> the config before the first restoration.

Yes, maybe.  I'll try this and maybe implement it in 0.5.

> It would be helpful if the feedback told you which window config was
> saved/restored. E.g. saved config #2, restored config #4 etc. That gives you
> an idea where you are in the ring.

Same, will be in 0.5.

> Looks good to me. Hope you get input from others. Thanks for making
> the changes.

Hopefully it's getting better.  

Thanks!

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> thanks for the comments.  Here is a new version:
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el
>
> Please test the new help mechanism.

Better.

However, I suggest that showing help should quit window editing. The reason
is that you are in a `read-event' loop, and that prevents any normal
interactions with the help. For instance, you cannot resize the help frame
or scroll its window - all keystrokes (including mouse actions) are trapped
by the `read-event' loop. It is not difficult for a user to start
window-editing again, after help quits editing.

> The problem is that I don't know how to prevent Emacs from waiting an
> event when the user select another frame, and making it wait for this
> event when back to the frame where (read-event) was first called.
>
> Any hint?

See above. It is a mistake, IMO, to not exit the `read-event' loop when the
help is shown.

Also, please don't turn off the cursor in the help window.

Suggestion: Put key descriptions in a single column, instead of having lines
that are up to 90 chars wide.

You can also shorten some of the descriptions, for readability:

- "toggle mode: move border, resize"
- "C-f, C-b, C-n, C-p: move cursor"
- "quit"
- "save window configuration"
- "move border" (singular, and get rid of "direction-wise")
- "select adjacent window" ("select" not "find", and "other window" means
something different)

> > Possibility: When you restore the last window config, first
> > save the current config at the end of the ring.
> > That way, `s'.changes.`r'.`r' will bring back
> > the config before the first restoration.
>
> Yes, maybe.  I'll try this and maybe implement it in 0.5.

Among other reasons, it's important to be able to undo an accidental
restore - this provides that.

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    However, I suggest that showing help should quit window editing. The reason
    is that you are in a `read-event' loop, and that prevents any normal
    interactions with the help.

It is useful to present the help without exiting the special command
loop if the presence of the help does not interfere with continuing to
use the special command loop to resize the windows.

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

>     However, I suggest that showing help should quit window
>     editing. The reason
>     is that you are in a `read-event' loop, and that prevents any normal
>     interactions with the help.
>
> It is useful to present the help without exiting the special command
> loop if the presence of the help does not interfere with continuing to
> use the special command loop to resize the windows.

I explained that in the case of non-nil `pop-up-frames', it does interfere -
or, rather, continuing to read events interferes with being able to use the
help display (depending on the size of its frame).

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>>     However, I suggest that showing help should quit window
>>     editing. The reason
>>     is that you are in a `read-event' loop, and that prevents any normal
>>     interactions with the help.
>>
>> It is useful to present the help without exiting the special command
>> loop if the presence of the help does not interfere with continuing to
>> use the special command loop to resize the windows.
>
> I explained that in the case of non-nil `pop-up-frames', it does interfere -
> or, rather, continuing to read events interferes with being able to use the
> help display (depending on the size of its frame).

The last version do this: when pop-up-frames is `nil' don't exit the
loop.  When pop-up-frames is `t', exit the loop.  Is that ok?

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> The last version do this: when pop-up-frames is `nil' don't exit the
> loop.  When pop-up-frames is `t', exit the loop.  Is that ok?

Yes. Sorry, I was looking at the previous version. Looks good.

However, there is a new bug (at least in Emacs 22.1.1): `q' in *Help* no
longer quits help-mode. This is likely a `help-mode' or a `view-mode' bug,
not a bug in your code - `q' in `help-mode' is notorious for not doing the
right thing. At least with `pop-up-frames' non-nil and your code, `q' in
*Help* does nothing at all.

Martin was working on similar `View-quit' bugs; I don't know if this one is
fixed in CVS. Perhaps someone with the latest Emacs can test this using
window-edit.el and non-nil `pop-up-frames'.


BTW, byte-compiling window-edit.el gives this warning:

window-edit.el:219:22:Warning: variable assignment to nonvariable `""'

The line in question is this:

(ring-insert-at-beginning window-configuration-ring wcf0)

Anyone have an idea what this is about? The message doesn't seem too
helpful.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> BTW, byte-compiling window-edit.el gives this warning:
>
> window-edit.el:219:22:Warning: variable assignment to nonvariable `""'

My fault.  Fixed in 0.6:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

I also added the M-<arrows> keys, which negate INCREMENT temporarily.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Mon, 2007 Nov 12  10:48 UTC
GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
started with

     /usr/local/src/emacs/src/emacs -q -D 

With Version: 0.6 of window-edit.el

Please put   (provide 'window-edit)  at the end.
Having it first presumes my load is successful!

Please update messages more quickly.  For example:

  * evoke (window-edit)

  * press 2 to obtain two windows vertically

  * press spacebar to shift to `move borders' mode  

     ## point is in upper window

  * press the lower arrow key to move the modeline down

     ## lower arrow key correctly moves modeline down

  * press the upper arrow key and correctly receive the message
    `[can't move border up]'

  * move point to lower window  with C-x o

     ## point is in lower window

  * press the upper arrow key 
    incorrectly receive the message `[can't move border up]'
    even when modeline moves up

  * press the lower arrow key and correctly receive the message
    `[can't move border down]'

Thank you.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Please put   (provide 'window-edit)  at the end.
> Having it first presumes my load is successful!

Done in 0.7, thanks.

  http://www.cognition.ens.fr/guerry/u/window-edit.el

> Please update messages more quickly.  

Thanks for the example.  The code of 0.6 contained a FIXME stating that
this should be fixed.

When I first wrote this function, I used a timer to empty the message
regularily.  But Richard noted that this was weird and confusing.

In 0.7 `window-edit' runs a timer again, but this time I made sure that
the timer is canceled when we quit window editing.  I also used a safer
name for the variable: `window-edit-message' instead of `msg'.

I think it's okay now.  Any suggestion to get rid of this timer is
welcome.  I cannot think of another solution.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

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

Bastien wrote:
> "Robert J. Chassell" <bob@rattlesnake.com> writes:
> 
>> Please put   (provide 'window-edit)  at the end.
>> Having it first presumes my load is successful!
> 
> Done in 0.7, thanks.
> 
>   http://www.cognition.ens.fr/guerry/u/window-edit.el
> 
>> Please update messages more quickly.  


I have worked a bit with bw-interactive.el along the ideas that have 
surfaced here (and some I had before). I have renamed it to winsize.el.

It is mainly restructured for more flexibility. And some bugs have 
probably been fixed + the features are more worked through.

The resizing is done with the arrow keys. Switching borders and windows 
are done with META-arrow keys. For more info see the help (just type ? 
for that).

[-- Attachment #2: winsize.el --]
[-- Type: text/plain, Size: 23784 bytes --]

;;; winsize.el --- Interactive window structure editing
;;
;; Description:
;; Author: Lennart Borgman <lennart dot borgman dot 073 at student at lu at se>
;; Maintainer:
;; Created: Wed Dec 07 15:35:09 2005
;; Version: 0.91
;; Last-Updated: Mon Nov 12 19:54:46 2007 (3600 +0100)
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This file contains functions for interactive resizing of Emacs
;; windows. To use it put it in your `load-path' and add the following
;; to your .emacs:
;;
;;     (require 'winsize)
;;     (global-set-key [(control x) ?+] 'resize-windows)
;;
;; For more information see `resize-windows'.
;;
;; These functions are a slightly rewritten version of the second part
;; of the second part my proposal for a new `balance-windows' function
;; for Emacs 22. The rewrite is mostly a restructure to more easily
;; add new functions. All functions and variables have been renamed.
;; The file was originally named bw-interactive.el.
;;
;; New ideas for functionality have been to a large part adopted from
;; the Emacs Devel mailing list. Probably most of them originated from
;; Drew Adams and Bastien.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; TODO: Change mouse pointer shape during resizing.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:


;;; Keymap, interactive functions etc

(defconst winsize-keymap
  (let ((map (make-sparse-keymap "Window Resizing")))
    (define-key map [menu-bar bw]
      (cons "Resize" (make-sparse-keymap "second")))
    (define-key map [menu-bar bw shrink]
      '("Shrink to Buffer" . winsize-shrink-window))
    (define-key map [menu-bar bw siblings]
      '("Balance Window Siblings" . winsize-balance-siblings))
    (define-key map [menu-bar bw balance]
      '("Balance Windows" . winsize-balance-windows))

    ;;(define-key map [?+] 'winsize-balance-windows)
    (define-key map [?+] 'balance-windows)
    (define-key map [?=] 'winsize-balance-siblings)
    (define-key map [?-] 'winsize-shrink-window)
    (define-key map [(up)]    'winsize-resize-up)
    (define-key map [(down)]  'winsize-resize-down)
    (define-key map [(left)]  'winsize-resize-left)
    (define-key map [(right)] 'winsize-resize-right)

    (define-key map [?0] 'delete-window)
    (define-key map [?1] 'delete-other-windows)
    (define-key map [?2] 'split-window-vertically)
    (define-key map [?3] 'split-window-horizontally)

    (define-key map [mouse-1] 'mouse-set-point)
    (define-key map [down-mouse-1] 'mouse-set-point)

    (define-key map [??] 'winsize-help)
    (define-key map [(control ?g)]     'winsize-quit)
    (define-key map [(control return)] 'winsize-stop-go-back)
    (define-key map [(return)]         'winsize-stop)
    (define-key map [t]                'winsize-stop-and-execute)
    map)
  "Keymap used by `resize-windows'.")

(defun winsize-pickup-windmove-keys ()
  "Choose keys for moving between borders or windows during resizing.
First the look in `global-map' and see if `windmove-left' etc are
defined there. If so bind the same keys in `winsize-keymap' to
the corresponding commands for moving between borders or windows
during resizing. However if those bindings already are defined in
`winsize-keymap' then do not change them.

If there are no bindings in `global-map' for `windmove-left' etc
then bind M-<arrow keys> for moving between windows."
  (let ((left (or (where-is-internal 'windmove-left global-map t)
                  (setq left [(meta left)])))
        (up (or (where-is-internal 'windmove-up global-map t)
                [(meta up)]))
        (right (or (where-is-internal 'windmove-right global-map t)
                   [(meta right)]))
        (down (or (where-is-internal 'windmove-down global-map t)
                  [(meta down)])))

    (unless (lookup-key winsize-keymap left)  (define-key winsize-keymap left 'winsize-to-border-left))
    (unless (lookup-key winsize-keymap up)    (define-key winsize-keymap up 'winsize-to-border-up))
    (unless (lookup-key winsize-keymap right) (define-key winsize-keymap right 'winsize-to-border-right))
    (unless (lookup-key winsize-keymap down)  (define-key winsize-keymap down 'winsize-to-border-down))))

(defun winsize-pre-command ()
  "Do this before every command.
Runs this in `pre-command-hook'.

Remember the currently used borders for resizing for later use in
`winsize-post-command'."
  (setq winsize-border-hor (winsize-border-used-hor))
  (setq winsize-border-ver (winsize-border-used-ver)))

(defun winsize-post-command ()
  "Done after every command.
Runs this in `post-command-hook'.

Check the borders remembered in `winsize-pre-command' and restore
them if feasable.

Give the user feedback about selected window and borders. Also
give a short help message."
  (unless winsize-border-hor
    (winsize-select-initial-border-hor))
  (when winsize-border-hor
    (winsize-set-border winsize-border-hor t))
  (unless winsize-border-ver
    (winsize-select-initial-border-ver))
  (when winsize-border-ver
    (winsize-set-border winsize-border-ver t))
  (winsize-tell-user))

(defun resize-windows ()
  "Start window resizing.
During resizing a window is selected. You can move its
borders (by default with the arrow keys) and you can select other
borders to move (by default with Meta-arrow keys).

You can also do other window operations, like splitting, deleting
and balancing the sizes. The keybindings below describes the
available operations:

\\<winsize-keymap>\\{winsize-keymap}All other keys exits window resizing and they are also executed.

The colors of the modelines are changed to those given in
`winsize-mode-line-colors' to indicate that you are resizing
windows. To make this indication more prominent the text in the
selected window is marked with the face `secondary-selection'.

As you select other borders or move to new a window the mouse
pointer is moved inside the selected window to show which borders
are beeing moved.

Which borders initially are choosen are controlled by the
variable `winsize-autoselect-borders'."
  (interactive)
  (setq winsize-window-config-init (current-window-configuration))
  (setq winsize-resizing t)
  (winsize-set-mode-line-colors t)
  (setq winsize-window-for-side-hor nil)
  (setq winsize-window-for-side-ver nil)
  (setq winsize-window-at-entry (selected-window))
  (setq winsize-frame (selected-frame))
  (winsize-setup-local-map)
  (winsize-create-short-help-message)
  (winsize-add-command-hooks))


(defun winsize-setup-local-map ()
  "Setup an overriding keymap and use this during resizing.
Save current keymaps."
  ;; Fix-me: use copy-keymap for old?
  (setq winsize-old-overriding-terminal-local-map overriding-terminal-local-map)
  (winsize-pickup-windmove-keys)
  (setq overriding-terminal-local-map (copy-keymap winsize-keymap))
  (setq winsize-old-overriding-local-map-menu-flag overriding-local-map-menu-flag)
  (setq overriding-local-map-menu-flag t))

(defun winsize-restore-local-map ()
  "Restore keymaps saved by `winsize-setup-local-map'."
  (setq overriding-terminal-local-map winsize-old-overriding-terminal-local-map)
  (setq overriding-local-map-menu-flag winsize-old-overriding-local-map-menu-flag))


(defvar winsize-window-config-init nil
  "Holds window configuration that was at resizing start.")

(defvar winsize-window-config-help nil
  "Holds window configuration when help is shown.")

(defun winsize-restore-after-help (buffer)
  "Restore window configuration after help.
Raise frame and reactivate resizing."
  (when (select-frame winsize-frame)
    (raise-frame)
    (set-window-configuration winsize-window-config-help)
    (resize-windows)))

(defun winsize-help ()
  "Give help during resizing.
Save current window configuration and pause resizing."
  (interactive)
  (setq winsize-window-config-help (current-window-configuration))
  (delete-other-windows)
  (with-output-to-temp-buffer (help-buffer)
    (with-current-buffer (help-buffer)
      (help-setup-xref (list #'winsize-hep) (interactive-p))
      (let ((str "*** Type q to return to window resizing ***"))
        (put-text-property 0 (length str) 'face 'highlight str)
        (insert str "\n\n")
        (insert "resize-windows is ")
        (describe-function-1 'resize-windows)
        (insert "\n\n" str))))
  ;; There are two windows shown after the above. Delete current
  ;; window so that only the help buffer is shown. NOTE: This is
  ;; necessary also for the restoring of window structure to work, but
  ;; at the moment it beats me why.
  (delete-window)
  (winsize-stop)
  (setq view-exit-action 'winsize-restore-after-help)
  (message "Type q to return to window resizing"))

(defun winsize-quit ()
  "Quit resing, restore window configuration at start."
  (interactive)
  (set-window-configuration winsize-window-config-init)
  (winsize-exit-resizing nil))

(defun winsize-stop-go-back ()
  "Exit window resizing. Go back to the window started in."
  (interactive)
  (winsize-exit-resizing nil t))

(defun winsize-stop-and-execute ()
  "Exit window resizing and put last key on the input queue.
Select the window marked during resizing before putting back the
last key."
  (interactive)
  (winsize-exit-resizing t))

(defun winsize-stop ()
  "Exit window resizing.
Select the window marked during resizing."
  (interactive)
  (winsize-exit-resizing nil))

(defun winsize-balance-windows ()
;; Fix-me: Currently not used.
  "Make windows same heights or widths and then exit window resizing.
This calls `balance-windows'."
  (interactive)
  (balance-windows)
  (winsize-exit-resizing nil))

(defun winsize-balance-siblings ()
  "Make current window siblings the same height or width."
  (interactive)
  (balance-windows (selected-window)))

(defun winsize-shrink-window ()
  "Shrink the window to be as small as possible to display its contents."
  (interactive)
  (fit-window-to-buffer nil (window-height)))

(defun winsize-to-border-left ()
  "Switch to border leftwards, maybe moving to next window."
  (interactive) (winsize-switch-border 'left t))

(defun winsize-to-border-right ()
  "Switch to border rightwards, maybe moving to next window."
  (interactive) (winsize-switch-border 'right t))

(defun winsize-to-border-up ()
  "Switch to border upwards, maybe moving to next window."
  (interactive) (winsize-switch-border 'up t))

(defun winsize-to-border-down ()
  "Switch to border downwards, maybe moving to next window."
  (interactive) (winsize-switch-border 'down t))

(defun winsize-resize-left ()
  "Move border left, but select border first if not done."
  (interactive) (winsize-resize 'left))

(defun winsize-resize-right ()
  "Move border right, but select border first if not done."
  (interactive) (winsize-resize 'right))

(defun winsize-resize-up ()
  "Move border up, but select border first if not done."
  (interactive) (winsize-resize 'up))

(defun winsize-resize-down ()
  "Move border down, but select border first if not done."
  (interactive) (winsize-resize 'down))


;;; Custom variables

(defcustom winsize-autoselect-borders t
  "Determines how borders are selected by default.
If nil hever select borders automatically (but keep them on the
same side while changing window). If 'when-single select border
automatically if there is only one possible choice. If t alwasy
select borders automatically if they are not selected."
  :type '(choice (const :tag "Always" t)
                 (const :tag "When only one possbility" when-single)
                 (const :tag "Never" nil))
  :group 'winsize)

(defcustom winsize-mode-line-colors (list t (list "green" "green4"))
  "Mode line colors used during resizing."
  :type '(list (boolean :tag "Enable mode line color changes during resizing")
               (list
                (color :tag "- Active window mode line color")
                (color :tag "- Inactive window mode line color")))
  :group 'winsize)

(defcustom winsize-mark-selected-window t
  "Mark selected window if non-nil."
  :type 'boolean
  :group 'winsize)


;;; Internals

(defvar winsize-old-mode-line-bg nil)
(defvar winsize-old-mode-line-inactive-bg nil)
(defvar winsize-old-overriding-terminal-local-map nil)
(defvar winsize-old-overriding-local-map-menu-flag nil)

(defvar winsize-resizing nil
  "t during resizing, nil otherwise.")

(defvar winsize-window-at-entry nil
  "Window that was selected when `resize-windows' started.")

(defvar winsize-frame nil
  "Frame that `resize-windows' is operating on.")


(defun winsize-exit-resizing (put-back-last-event &optional stay)
  "Stop window resizing.
Put back mode line colors and keymaps that was changed.

Upon exit first select window. If STAY is non-nil then select the
window which was selected when `resize-windows' was called,
otherwise select the last window used during resizing. After
that, if PUT-BACK-LAST-EVENT is non-nil, put back the last input
event on the input queue."
  (setq winsize-resizing nil)
  (winsize-set-mode-line-colors nil)
  (winsize-restore-local-map)
  (winsize-remove-command-hooks)
  (when stay (select-window winsize-window-at-entry))
  (winsize-mark-selected-window nil)
  (message "Exited window resizing")
  (when (and put-back-last-event)
    ;; Add this to the input queue again:
    (isearch-unread last-command-event)))

(defun winsize-add-command-hooks ()
  (add-hook 'pre-command-hook 'winsize-pre-command)
  (add-hook 'post-command-hook 'winsize-post-command))

(defun winsize-remove-command-hooks ()
  (remove-hook 'pre-command-hook 'winsize-pre-command)
  (remove-hook 'post-command-hook 'winsize-post-command))


;;; Borders

(defvar winsize-window-for-side-hor nil
  "Window used internally for resizing in vertical direction.")

(defvar winsize-window-for-side-ver nil
  "Window used internally for resizing in horizontal direction.")

(defvar winsize-border-hor nil
  "Used internally to keep border choice on the same side.
This is set by `winsize-pre-command' and checked by
`winsize-post-command'.")

(defvar winsize-border-ver nil
  "Used internally to keep border choice on the same side.
This is set by `winsize-pre-command' and checked by
`winsize-post-command'.")

(defun winsize-border-used-hor()
  "Return the border side used for horizontal resizing."
  (let ((hor (when winsize-window-for-side-hor
               (if (eq (selected-window) winsize-window-for-side-hor)
                   'right
                 'left))))
    hor))

(defun winsize-border-used-ver()
  "Return the border side used for vertical resizing."
  (let ((ver (when winsize-window-for-side-ver
               (if (eq (selected-window) winsize-window-for-side-ver)
                   'down
                 'up))))
    ver))

(defun winsize-switch-border (dir allow-windmove)
  "Switch border that is beeing resized.
Switch to border in direction DIR. If ALLOW-WINDMOVE is non-nil
then change window if necessary, otherwise stay and do not change
border."
  (let* ((window-in-that-dir (windmove-find-other-window
                              dir nil (selected-window))))
    (when (window-minibuffer-p window-in-that-dir)
      (setq window-in-that-dir nil))
    (when window-in-that-dir
      (let* ((is-hor (memq dir '(left right)))
             (border-used (if is-hor
                             (winsize-border-used-hor)
                           (winsize-border-used-ver)))
             (using-dir-border (eq dir border-used)))
        (when (and using-dir-border
                   allow-windmove)
          (setq winsize-window-for-side-hor nil)
          (setq winsize-window-for-side-ver nil)
          (windmove-do-window-select dir nil))
        (winsize-select-border dir)))))


(defun winsize-select-initial-border-hor ()
  "Select a default border horizontally."
  (let ((has-left  (winsize-window-beside (selected-window) 'left))
        (has-right (winsize-window-beside (selected-window) 'right)))
    (cond
     ((not winsize-autoselect-borders) t)
     ((eq winsize-autoselect-borders 'when-single)
      (when (= 1 (length (delq nil (list has-left has-right))))
        (winsize-select-border 'right)))
     (t
      (winsize-select-border 'right)))))

(defun winsize-select-initial-border-ver ()
  "Select a default border vertically."
  (let ((has-up  (winsize-window-beside (selected-window) 'up))
        (has-down (winsize-window-beside (selected-window) 'down)))
    (cond
     ((not winsize-autoselect-borders) t)
     ((eq winsize-autoselect-borders 'when-single)
      (when (= 1 (length (delq nil (list has-left has-up))))
        (winsize-select-border 'up)))
     (t
      (winsize-select-border 'up)))))

(defun winsize-select-border (dir)
  "Select border to be set for resizing.
The actually setting is done in `post-command-hook'."
  (cond
   ((memq dir '(left right))
    (setq winsize-border-hor dir))
   ((memq dir '(up down))
    (setq winsize-border-ver dir))
   (t (error "Bad DIR=%s" dir))))

(defun winsize-set-border (dir allow-other-side)
  "Set border for resizing.
This should be done in `post-command-hook'."
  (let ((window-beside (winsize-window-beside (selected-window) dir))
        (horizontal (memq dir '(left right))))
    (unless window-beside
      (when allow-other-side
        (setq dir (winsize-other-side dir))
        (setq window-beside
              (winsize-window-beside (selected-window) dir))))
    (if horizontal
        (progn
          (setq winsize-border-hor nil)
          (setq winsize-window-for-side-hor nil))
      (setq winsize-border-ver nil)
      (setq winsize-window-for-side-ver nil))
    (when window-beside
      (let ((window-for-side (if (memq dir '(right down))
                                 (selected-window)
                               window-beside)))
        (if horizontal
            (setq winsize-window-for-side-hor window-for-side)
          (setq winsize-window-for-side-ver window-for-side))))))

(defun winsize-resize (dir)
  "Choose border to move. Or if border is chosen move that border.
Used by `winsize-resize-left' etc."
  (let* ((horizontal (memq dir '(left right)))
         (arg (if (memq dir '(left up)) -1 1))
         (window-for-side (if horizontal 'winsize-window-for-side-hor 'winsize-window-for-side-ver))
         (window-for-side-val (symbol-value window-for-side)))
    (if (not window-for-side-val)
        (winsize-select-border dir)
      (when (and winsize-resizing
                 (not (eq window-for-side-val 'checked)))
        (condition-case err
            (adjust-window-trailing-edge (symbol-value window-for-side) arg horizontal)
          (error (message "%s" (error-message-string err))))))))

(defun winsize-other-side (side)
  "Return other side for 'left etc, ie 'left => 'right."
  (cond
    ((eq side 'left) 'right)
    ((eq side 'right) 'left)
    ((eq side 'up) 'down)
    ((eq side 'down) 'up)
    (t (error "Invalid SIDE=%s" side))))

(defun winsize-window-beside (window side)
  "Return a window directly beside WINDOW at side SIDE.
That means one whose edge on SIDE is touching WINDOW.  SIDE
should be one of 'left, 'up, 'right and 'down."
  (require 'windmove)
  (let* ((windmove-wrap-around nil)
         (win (windmove-find-other-window side nil window)))
    (unless (window-minibuffer-p win)
      win)))


;;; User feedback

(defun winsize-set-mode-line-colors (on)
  "Turn mode line colors on if ON is non-nil, otherwise off."
  (when on
    (setq winsize-old-mode-line-inactive-bg (face-attribute 'mode-line-inactive :background))
    (setq winsize-old-mode-line-bg (face-attribute 'mode-line :background)))
  (if on
      (let* ((use-colors (car winsize-mode-line-colors))
             (colors (cadr winsize-mode-line-colors))
             (active-color (elt colors 0))
             (inactive-color (elt colors 1)))
        (when use-colors
          (set-face-attribute 'mode-line-inactive nil :background inactive-color)
          (set-face-attribute 'mode-line nil :background active-color)))
    (set-face-attribute 'mode-line-inactive nil :background winsize-old-mode-line-inactive-bg)
    (set-face-attribute 'mode-line nil :background winsize-old-mode-line-bg)))

(defvar winsize-short-help-message nil
  "Short help message shown in echo area.")

(defun winsize-create-short-help-message ()
  "Create short help message to show in echo area."
  (let ((msg ""))
    (mapc (lambda (rec)
            (let ((fun (elt rec 0))
                  (desc (elt rec 1))
                  (etc (elt rec 2)))
              (when (< 0 (length msg))
                (setq msg (concat msg ", ")))
              (setq msg (concat msg
                                desc
                                ":"
                                (key-description
                                 (where-is-internal fun winsize-keymap t))
                                (if etc " etc" "")))))
          '(
            (balance-windows "balance" nil)
            (winsize-resize-left "resize" t)
            (winsize-to-border-left "border" nil)
            ))
    (setq msg (concat msg ", exit:RET, help:?"))
    (setq winsize-short-help-message msg)))

(defun winsize-move-mouse-to-resized ()
  "Move mouse to show which border(s) are beeing moved."
  (let* ((edges (window-edges (selected-window)))
         (L (nth 0 edges))
         (T (nth 1 edges))
         (R (nth 2 edges))
         (B (nth 3 edges))
         (x (/ (+ L R) 2))
         (y (/ (+ T B) 2)))
    (when (and winsize-window-for-side-hor
               (not (eq winsize-window-for-side-hor 'checked)))
      (setq x (if (eq (selected-window) winsize-window-for-side-hor) (- R 6) (+ L 2))))
    (when (and winsize-window-for-side-ver
               (not (eq winsize-window-for-side-ver 'checked)))
      (setq y (if (eq (selected-window) winsize-window-for-side-ver) (- B 2) (+ T 0))))
    (set-mouse-position (selected-frame) x y)))

(defvar winsize-selected-window-overlay nil)

(defun winsize-mark-selected-window (active)
  (when winsize-selected-window-overlay
    (delete-overlay winsize-selected-window-overlay)
    (setq winsize-selected-window-overlay nil))
  (when active
    (with-current-buffer (window-buffer (selected-window))
      (let ((ovl (make-overlay (point-min) (point-max))))
        (setq winsize-selected-window-overlay ovl)
        (overlay-put ovl 'window (selected-window))
        (overlay-put ovl 'pointer 'arrow)
        (overlay-put ovl 'priority 1000)
        (overlay-put ovl 'face 'secondary-selection)))))

(defun winsize-tell-user ()
  "Give the user feedback."
  (when winsize-mark-selected-window
    (winsize-mark-selected-window t))
  (winsize-move-mouse-to-resized)
  (message "%s" winsize-short-help-message))


(provide 'winsize)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; winsize.el ends here

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

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

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Robert J. Chassell]

In a short test, in 
today's GNU Emacs CVS snapshot, Mon, 2007 Nov 12 10:48 UTC
GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
started with 
      emacs -q 
winsize.el looks better.  I don't plan to use it much since the
current windows have been right for me, but I think the code could be
introduced into CVS Emacs.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> I have worked a bit with bw-interactive.el along the ideas that have
> surfaced here (and some I had before). I have renamed it to winsize.el.
>
> It is mainly restructured for more flexibility. And some bugs have
> probably been fixed + the features are more worked through.
>
> The resizing is done with the arrow keys. Switching borders and windows
> are done with META-arrow keys. For more info see the help (just type ?
> for that).

Some feedback from very quick testing - I used the config given by M-x
resize-windows 3 2 3 2.

1. In addition to the test frame, I had also another frame showing the same
file (your file). The latter frame was scrolled down to show command
resize-windows. I put the cursor in one of the windows on the other frame
and used M-x resize-windows. The second frame was scrolled to the top.
That's a bug, IMO: Other frames should not be affected, and no window should
be scrolled, just because I'm resizing windows. I had to copy the code to
another buffer, just to be able to continue seeing it while executing
resize-windows.

2. M-left/right does not let you get to all windows (but you can click
mouse-1 to get there). Actually, the problem seems to be the same as for
window-edit: the cursor must be on a line that is adjacent to the window to
select.

3. So allow C-n, C-f, etc. to move the cursor without exiting. That way, you
can use M-<arrow> to get to any window you want, using just the keyboard.

4. No need to highlight the mode lines of all windows. It would be helpful
to highlight only the border to be moved - perhaps by showing the
corresponding fringe specially temporarily (left/right) or highlighting the
appropriate mode line (only).

5. Highlighting the window background is not a great way to indicate the
border that will be moved. But it does help show which window has the focus.
IMO, it would be better to not reuse face `secondary-selection', but define
a new one just for this.

6. You should not exit window resizing just because you click somewhere
outside the frame that has the windows to be resized, or even outside Emacs
(the latter happens only sometimes).

7. I hit `?' for help. I got no help, and all of the windows were blown away
except one. I tried it other times, and the frame itself was blown away. The
latter effect is from my code, but it indicates that `delete-window' was
called for the last remaining window.

8. Some way to save and restore window configs would be nice.

9. Sometimes, I need to press M-left (or right etc) to get it to take
effect - the first press does nothing.

10. There is no feedback when resizing is not possible - the keys just seem
not to work.

11. `=' in lower left window (configuration 3 2 3 2), causes the two windows
above it to have the same width. What does "Make current window siblings the
same height or width." mean? Does it mean make the siblings the same
height/width as each other or the same as the selected window? Sometimes it
seems to be one, sometimes the other.

12. `-' seems to do nothing.

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> I have worked a bit with bw-interactive.el along the ideas that have
>> surfaced here (and some I had before). I have renamed it to winsize.el.
>>
>> It is mainly restructured for more flexibility. And some bugs have
>> probably been fixed + the features are more worked through.
>>
>> The resizing is done with the arrow keys. Switching borders and windows
>> are done with META-arrow keys. For more info see the help (just type ?
>> for that).
> 
> Some feedback from very quick testing - I used the config given by M-x
> resize-windows 3 2 3 2.

Thanks for testing.

> 1. In addition to the test frame, I had also another frame showing the same
> file (your file). The latter frame was scrolled down to show command
> resize-windows. I put the cursor in one of the windows on the other frame
> and used M-x resize-windows. The second frame was scrolled to the top.
> That's a bug, IMO: Other frames should not be affected, and no window should
> be scrolled, just because I'm resizing windows. I had to copy the code to
> another buffer, just to be able to continue seeing it while executing
> resize-windows.

That is very strange. I can see nothing like that happening.

> 2. M-left/right does not let you get to all windows (but you can click
> mouse-1 to get there). Actually, the problem seems to be the same as for
> window-edit: the cursor must be on a line that is adjacent to the window to
> select.

I think both Bastien and I use windmove for moving between the windows. 
(Using windmove makes it more consistent for the users, I hope.)

> 3. So allow C-n, C-f, etc. to move the cursor without exiting. That way, you
> can use M-<arrow> to get to any window you want, using just the keyboard.

I can not find any window configuration where I see the problem. If 
however it does happen then I think it is a bug in windmove.

> 4. No need to highlight the mode lines of all windows. It would be helpful
> to highlight only the border to be moved - perhaps by showing the
> corresponding fringe specially temporarily (left/right) or highlighting the
> appropriate mode line (only).

Thanks, I did not think about fringes. But I wonder if it is possible. 
First it looks like there are not window specific fringes - or are 
there? Then I am not sure there are any usable fringes defined currently 
- or?

> 5. Highlighting the window background is not a great way to indicate the
> border that will be moved. But it does help show which window has the focus.
> IMO, it would be better to not reuse face `secondary-selection', but define
> a new one just for this.

I am a bit hesitating that this is worth the trouble of defining a new 
face. What is the drawbacks of using secondary-selection? (or maybe 
highlight?)

> 6. You should not exit window resizing just because you click somewhere
> outside the frame that has the windows to be resized, or even outside Emacs
> (the latter happens only sometimes).

The implementation uses overriding-terminal-local-map during resizing. 
That means that there are two alternatives when switching frame: Either 
resize on that frame too or stop resizing when switching frame. I have 
chosen the latter.

> 7. I hit `?' for help. I got no help, and all of the windows were blown away
> except one. I tried it other times, and the frame itself was blown away. The
> latter effect is from my code, but it indicates that `delete-window' was
> called for the last remaining window.

Thanks I will try to fix it. Probably something with popup frames.

> 8. Some way to save and restore window configs would be nice.

I think Bastien had the idea of using a kill ring for that. Is that 
useful? Maybe some convenient way to choose from that then?

> 9. Sometimes, I need to press M-left (or right etc) to get it to take
> effect - the first press does nothing.

M-left etc first switches border and then window. Is that what happens?

> 10. There is no feedback when resizing is not possible - the keys just seem
> not to work.

Ok, I will think about catching the error messages and showing them.

> 11. `=' in lower left window (configuration 3 2 3 2), causes the two windows
> above it to have the same width. What does "Make current window siblings the
> same height or width." mean? Does it mean make the siblings the same
> height/width as each other or the same as the selected window? Sometimes it
> seems to be one, sometimes the other.

It works the same way as balance-windows, but only for siblings. The 
concept is actually a tree where the siblings in each node get equal 
amounts of space. I can find no good and short way to express that though.

> 12. `-' seems to do nothing.

It only shrinks vertically and if the buffer height is smaller than the 
window height. There should be some feedback when that is not the case, 
I will add it.


> HTH.

It does.

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> > 1. In addition to the test frame, I had also another frame
> showing the same
> > file (your file). The latter frame was scrolled down to show command
> > resize-windows. I put the cursor in one of the windows on the
> other frame
> > and used M-x resize-windows. The second frame was scrolled to the top.
> > That's a bug, IMO: Other frames should not be affected, and no
> window should
> > be scrolled, just because I'm resizing windows. I had to copy
> the code to
> > another buffer, just to be able to continue seeing it while executing
> > resize-windows.
>
> That is very strange. I can see nothing like that happening.

I no longer see it now either; sorry. Don't know what caused it
(repeatedly), but since I can't reproduce it now, please ignore the noise.

> > 3. So allow C-n, C-f, etc. to move the cursor without exiting.
> That way, you
> > can use M-<arrow> to get to any window you want, using just the
> keyboard.
>
> I can not find any window configuration where I see the problem. If
> however it does happen then I think it is a bug in windmove.

The config I gave: 3 2 3 2. And the example I gave Bastien before.
Basically, the cursor position determines the destination window to the left
(for example), when there is more than one such window. You need to be able
to move the cursor to put it next to the window you want to move to.

> > 4. No need to highlight the mode lines of all windows. It would
> be helpful
> > to highlight only the border to be moved - perhaps by showing the
> > corresponding fringe specially temporarily (left/right) or
> highlighting the
> > appropriate mode line (only).
>
> Thanks, I did not think about fringes. But I wonder if it is possible.
> First it looks like there are not window specific fringes - or are
> there? Then I am not sure there are any usable fringes defined currently
> - or?

I don't know much about fringes. My main point was that there is no need to
highlight any mode line except possibly the one along the border to be
moved. The rest is just distraction. I'm not against highlighting, but only
if it serves a purpose.

> > 5. Highlighting the window background is not a great way to indicate the
> > border that will be moved. But it does help show which window
> has the focus.
> > IMO, it would be better to not reuse face
> `secondary-selection', but define
> > a new one just for this.
>
> I am a bit hesitating that this is worth the trouble of defining a new
> face. What is the drawbacks of using secondary-selection? (or maybe
> highlight?)

I'm probably alone on this - for some reason, people (mistakenly, IMO) want
to reuse faces in unrelated contexts.

My point is that the purpose of the face is not the same as the use you make
of it. A user might well want to change the face for just this use. A user
might think a yellow background is great for secondary selection (or
highlight or whatever), but s?he might not think it is so great to fill the
entire window for resizing - s?he might instead prefer a light gray or
pastel shading (or dark shading, for a dark background) for that - or
`default', to get no such highlighting at all.

There is zero connection between the meaning and use of the
`secondary-selection' face and the highlighting you are doing here. But, as
I said, I'm probably a lone voice on this matter.

> > 6. You should not exit window resizing just because you click somewhere
> > outside the frame that has the windows to be resized, or even
> outside Emacs
> > (the latter happens only sometimes).
>
> The implementation uses overriding-terminal-local-map during resizing.
> That means that there are two alternatives when switching frame: Either
> resize on that frame too or stop resizing when switching frame. I have
> chosen the latter.

I can't speak to the problem of implementation - my comment was as a user.

> > 7. I hit `?' for help. I got no help, and all of the windows
> were blown away
> > except one. I tried it other times, and the frame itself was
> blown away. The
> > latter effect is from my code, but it indicates that `delete-window' was
> > called for the last remaining window.
>
> Thanks I will try to fix it. Probably something with popup frames.

Yes, probably. Bastien had a similar problem. The solution was to use
(with-output-to-temp-buffer "*Help*"...).

> > 8. Some way to save and restore window configs would be nice.
>
> I think Bastien had the idea of using a kill ring for that. Is that
> useful? Maybe some convenient way to choose from that then?

He uses a ring (but not the kill-ring). Yes, it's useful and convenient,
IMO. It's likely that a user will fiddle with resizing only a relatively few
times during an Emacs session (or during a particular work task). S?he is
likely to want to return to a configuration s?he already had, rather than
fine-tuning sizes again from scratch.

> > 9. Sometimes, I need to press M-left (or right etc) to get it to take
> > effect - the first press does nothing.
>
> M-left etc first switches border and then window. Is that what happens?

I don't know. As a user, it seems that there is an unnecessary (extra)
keystroke. But there is no feedback for what it does, so I can't tell you
what it's doing.

> > 10. There is no feedback when resizing is not possible - the
> keys just seem
> > not to work.
>
> Ok, I will think about catching the error messages and showing them.

Some feedback for each keystroke isn't a bad idea here. If a window visibly
changes size, that's sufficient feedback; otherwise, something should be
echoed.

> > 11. `=' in lower left window (configuration 3 2 3 2), causes
> the two windows
> > above it to have the same width. What does "Make current window
> siblings the
> > same height or width." mean? Does it mean make the siblings the same
> > height/width as each other or the same as the selected window?
> Sometimes it
> > seems to be one, sometimes the other.
>
> It works the same way as balance-windows, but only for siblings. The
> concept is actually a tree where the siblings in each node get equal
> amounts of space.

Equal to what? That's the question. Sometimes they seem to be equal only to
each other; sometimes they seem to be equal to each other and to the
selected window.

> I can find no good and short way to express that though.
>
> > 12. `-' seems to do nothing.
>
> It only shrinks vertically and if the buffer height is smaller than the
> window height. There should be some feedback when that is not the case,
> I will add it.

Not just feedback, but doc. There is no doc for it, beyond the function
name, and that just tells you that it shrinks the window. So far, I don't
see the value of (use case for) this option.

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> 3. So allow C-n, C-f, etc. to move the cursor without exiting.

Ok, I see. I have added support for this, a defcustom
winsize-let-me-use.


> My point is that the purpose of the face is not the same as the use you make
> of it. A user might well want to change the face for just this use. A user

Ok, I have added a new face variable that just inherits from
`secondary-selection' (and a variable pointing to this, the standard
Emacs way).


>>> 7. I hit `?' for help. I got no help, and all of the windows
>> were blown away

Thanks, I think I have fixed this (in a different way).


>>> 8. Some way to save and restore window configs would be nice.

Ok, I added support for it.


>>> 9. Sometimes, I need to press M-left (or right etc) to get it to take
>>> effect - the first press does nothing.
>> M-left etc first switches border and then window. Is that what happens?
> 
> I don't know. As a user, it seems that there is an unnecessary (extra)
> keystroke. But there is no feedback for what it does, so I can't tell you
> what it's doing.

I guess the problem might have been that you are using
mouse-avoidance-mode. Do you do that?

I move the mouse pointer to the relevant corner in the selected window
to show which borders that will be moved. In the new version I turn off
mouse avoidance during resizing.

Just moving the mouse pointer is not a very prominent sign however.
Changing the mouse color could help, but that does not work on w32.


>>> 10. There is no feedback when resizing is not possible - the

The error messages were overwritten. Fixed.


>>> 12. `-' seems to do nothing.

I have changed this to use fit-window-to-buffer. I think that feedback
should be given by that function.

And I have moved it to = which seems more mnemonic now then.


> HTH.

Thanks. The new version is on

   http://ourcomments.org/Emacs/DL/elisp/winsize.el

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> > > 4. No need to highlight the mode lines of all windows. It would
> > > be helpful to highlight only the border to be moved - perhaps
> > > by showing the corresponding fringe specially temporarily
> > > (left/right) or highlighting the appropriate mode line (only).
> >
> > Thanks, I did not think about fringes. But I wonder if it is possible.
> > First it looks like there are not window specific fringes - or are
> > there? Then I am not sure there are any usable fringes defined
> > currently - or?
>
> I don't know much about fringes. My main point was that there is
> no need to highlight any mode line except possibly the one along
> the border to be moved. The rest is just distraction. I'm not
> against highlighting, but only if it serves a purpose.

I see that this has not changed. I reiterate the following suggestions:

1. There is no need to highlight the mode lines of the windows that are
*not* being resized - that serves only to distract.

2. The window being resized is already highlighted using the background
overlay. There is no reason to also highlight its mode line - *unless* the
mode-line highlighting indicates that that particular border is being moved
(which it does not, for the moment).

3. It would be very helpful if the mode line of the border being moved were
highlighted. That would not help with the top border of a window at the top
of the frame, and it would not help with a vertical border, but at least it
would help with the other borders.

4. For vertical borders, you can, I think, use something in the fringe to
indicate the border being moved. Again, I'm not an expert on fringe, but
this should be possible. IIUC, fringe is window-specific, and the left and
right can be manipulated separately.

5. For consistency, the mode-line indication for moving a horizontal border
could be (a temporary display that is) similar to whatever you use in the
fringe.

6. If you can't use fringe, then consider using the so-called "overlay
arrow". Or a temporary `display' property. Or something else. (Fringe would
be much better, however.) There should be some indication of which border is
the subject.

> > > 6. You should not exit window resizing just because you click
> > > somewhere outside the frame that has the windows to be resized,
> > > or even outside Emacs (the latter happens only sometimes).
> >
> > The implementation uses overriding-terminal-local-map during resizing.
> > That means that there are two alternatives when switching frame: Either
> > resize on that frame too or stop resizing when switching frame. I have
> > chosen the latter.
>
> I can't speak to the problem of implementation - my comment was as a user.

The problem is still there.

> > > 7. I hit `?' for help. I got no help, and all of the windows
> > > were blown away except one. I tried it other times, and the
> > > frame itself was blown away. The latter effect is from my
> > > code, but it indicates that `delete-window' was
> > > called for the last remaining window.
> >
> > Thanks I will try to fix it. Probably something with popup frames.
>
> Yes, probably. Bastien had a similar problem. The solution was to use
> (with-output-to-temp-buffer "*Help*"...).

This problem remains. Now, the help text replaces all windows in the frame
(no reason for that), and when I hit `q' the entire frame is deleted. Also,
the *Help* buffer is currently not read-only.

Please use (with-output-to-temp-buffer "*Help*"...) or equivalent. It will
solve the problem.

[The reason that the frame is deleted in my case is no doubt because I have
redefined `delete-window' to delete the frame also if the window is
`one-window-p'. Without that redefinition, a call to `delete-window' will do
nothing if `one-window-p' - it just raises an error that you can't delete
the sole window. That is not TRT either.]

> > > 8. Some way to save and restore window configs would be nice.
> >
> > I think Bastien had the idea of using a kill ring for that. Is that
> > useful? Maybe some convenient way to choose from that then?
>
> He uses a ring (but not the kill-ring). Yes, it's useful and convenient,
> IMO. It's likely that a user will fiddle with resizing only a
> relatively few
> times during an Emacs session (or during a particular work task). S?he is
> likely to want to return to a configuration s?he already had, rather than
> fine-tuning sizes again from scratch.

`!' is not the best choice for config saving, IMO. It usually indicates
something that requires care or has a non-reversible effect. Saving a window
config is entirely benign. Consider using `s' or `C-x C-s' or similar.

> > > 9. Sometimes, I need to press M-left (or right etc) to get it to take
> > > effect - the first press does nothing.
> >
> > M-left etc first switches border and then window. Is that what happens?
>
> I don't know. As a user, it seems that there is an unnecessary (extra)
> keystroke. But there is no feedback for what it does, so I can't tell you
> what it's doing.

You provided some feedback; thanks. Still, it would be better if the
feedback mentioned *which* border was selected, especially if you don't show
that visually.

> > > 11. `=' in lower left window (configuration 3 2 3 2), causes
> > the two windows
> > > above it to have the same width. What does "Make current window
> > siblings the
> > > same height or width." mean? Does it mean make the siblings the same
> > > height/width as each other or the same as the selected window?
> > Sometimes it
> > > seems to be one, sometimes the other.
> >
> > It works the same way as balance-windows, but only for siblings. The
> > concept is actually a tree where the siblings in each node get equal
> > amounts of space.
>
> Equal to what? That's the question. Sometimes they seem to be
> equal only to
> each other; sometimes they seem to be equal to each other and to the
> selected window.

New problems I noticed:

Please don't use the mouse pointer to try to indicate the selected border.
That's not what it is for. Also, it is misleading and annoying if you just
click a window to select it - the mouse pointer should, well, point out the
mouse position. And, before clicking mouse-1 to select a window, I would not
even have noticed this (mis-)feature if I had not read the email thread.

BUG: Configuration 3 2 3 2; cursor in lower-left window; hit `='. All
windows along the left side are replaced by a single window. With cursor in
top-middle window, the windows is extended to full frame height, and one of
the windows on the left side is deleted. None of this behavior seems
comprehensible or right.

BUG: Sometimes, when I hit `C-g', all windows but one disappear. That is,
from, say, 5 windows I end up with only one.

Suggestion: Bind `q' also to `winsize-quit'. Currently, it is
self-inserting.

I don't understand why you have (define-key [t] 'winsize-stop-and-execute).
Why allow any keys to (exit and) self-insert? Why not make the user
explicitly exit first? That's not hard for the user to do. Otherwise, they
will get some surprises.

Why `4' for `other-window'? If a binding for this is really needed (not
IMO), `o' is better.

Why bind both `mouse-1' and `down-mouse-1' to the same command?

Please take a look at the behavior of Bastien's code and perhaps my feedback
that led to some of the changes he made. IMO, some of his UI is more natural
than yours. But I like the idea of highlighting the selected window (but
please also highlight the selected border).

Please think about adding simple window-resizing as the default behavior. I
really think that 90% of the time a user will need and use only that; s?he
will not bother to move a particular border. To me, it is overly complex to
make a user reason in terms of border movement, if all s?he wants to do is
increase or decrease the size of a window. Border movement is fine tuning
that will rarely be needed, IMO.

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> I don't know much about fringes. My main point was that there is
>> no need to highlight any mode line except possibly the one along
>> the border to be moved. The rest is just distraction. I'm not
>> against highlighting, but only if it serves a purpose.
> 
> I see that this has not changed. I reiterate the following suggestions:
 >
> 1. There is no need to highlight the mode lines of the windows that are
> *not* being resized - that serves only to distract.

It serves a purpose, it shows that Emacs is now doing something 
different with the input you give. And changing the colors of the 
borders seems adequate since this is what you are currently working 
with, moving and/or deleting them.

But I made this optional ;-)


> 2. The window being resized is already highlighted using the background
> overlay. There is no reason to also highlight its mode line - *unless* the
> mode-line highlighting indicates that that particular border is being moved
> (which it does not, for the moment).

I thought the same myself, but I was not sure, since the selected window 
normally have another mode color. I made this an option to for that.


> 3. It would be very helpful if the mode line of the border being moved were
> highlighted. That would not help with the top border of a window at the top
> of the frame, and it would not help with a vertical border, but at least it
> would help with the other borders.

Maybe, but wouldn't it be confusing when you exit window resizing, at 
least if you have choosen to not have any background color for the 
selected window (in this case Juri's proposal is better).


> 4. For vertical borders, you can, I think, use something in the fringe to
> indicate the border being moved. Again, I'm not an expert on fringe, but
> this should be possible. IIUC, fringe is window-specific, and the left and
> right can be manipulated separately.

Didn't I tell that it looked impossible to use the fringes for this?


> 5. For consistency, the mode-line indication for moving a horizontal border
> could be (a temporary display that is) similar to whatever you use in the
> fringe.

If it were possible, yes.


> 6. If you can't use fringe, then consider using the so-called "overlay
> arrow". Or a temporary `display' property. Or something else. (Fringe would
> be much better, however.) There should be some indication of which border is
> the subject.

Is not that tied to the buffer text? That means you can not position it 
were you want. You have more freedom with the mouse pointer.


>>>> 6. You should not exit window resizing just because you click
>>>> somewhere outside the frame that has the windows to be resized,
>>>> or even outside Emacs (the latter happens only sometimes).
>>> The implementation uses overriding-terminal-local-map during resizing.
>>> That means that there are two alternatives when switching frame: Either
>>> resize on that frame too or stop resizing when switching frame. I have
>>> chosen the latter.
>> I can't speak to the problem of implementation - my comment was as a user.
> 
> The problem is still there.

I did comment on that, didn't I? I can see that this is a problem for 
you since you use popup frames. An alternative to end it as I do now 
would be to pause it and resume it when switching back to the other 
frame. (That was actually one of the reasons I choosed to have other 
colors for the mode lines during resizing, at least as a possibility.)


>>>> 7. I hit `?' for help. I got no help, and all of the windows
>>>> were blown away except one. I tried it other times, and the
>>>> frame itself was blown away. The latter effect is from my
>>>> code, but it indicates that `delete-window' was
>>>> called for the last remaining window.
>>> Thanks I will try to fix it. Probably something with popup frames.
>> Yes, probably. Bastien had a similar problem. The solution was to use
>> (with-output-to-temp-buffer "*Help*"...).
> 
> This problem remains. Now, the help text replaces all windows in the frame
> (no reason for that), 

Oh, yes, there is a reason. When you are trying to arrange the window 
borders to your taste I believe it would be irritating to get this 
destroyed by some help function tampering with the window layout.

> and when I hit `q' the entire frame is deleted. 

Eh, sorry ;-) It is not supposed to do that. It should restore the 
window layout you had before you asked for help.

There must be something I have missed about the handling of popup 
windows. I do not know very much about them since I do not use them 
myself. (I maximize all windows ...)

> Also, the *Help* buffer is currently not read-only.

Oh. The help functions are not easy. Fixed. Thanks.

> Please use (with-output-to-temp-buffer "*Help*"...) or equivalent. It will
> solve the problem.

You always do that with the normal help functions.

> [The reason that the frame is deleted in my case is no doubt because I have
> redefined `delete-window' to delete the frame also if the window is
> `one-window-p'. Without that redefinition, a call to `delete-window' will do
> nothing if `one-window-p' - it just raises an error that you can't delete
> the sole window. That is not TRT either.]

I wonder what happens. The only thing I do to make exit help resume the 
window resizing is to set `view-exit-action' to the function 
winsize-restore-after-help. Could you please look at that function and 
see if you can find anything suspicious there. I can not see anything 
myself.

Which version of winsize.el are you using? I just uploaded a new version 
with the help buffer read-only problem fixed.

> `!' is not the best choice for config saving, IMO. It usually indicates
> something that requires care or has a non-reversible effect. Saving a window
> config is entirely benign. Consider using `s' or `C-x C-s' or similar.

Doesn't it also mean "I like this!"?

> You provided some feedback; thanks. Still, it would be better if the
> feedback mentioned *which* border was selected, especially if you don't show
> that visually.

Thanks, added.

> New problems I noticed:
> 
> Please don't use the mouse pointer to try to indicate the selected border.
> That's not what it is for. 

It is actually used to indicate the border while resizing w32 windows 
from the keyboard. In that case the mouse is moved back to where it was 
before resizing, but since we might to more here when resizing several 
windows, maybe splitting and deleting to I did not find it meaningful to 
put back the mouse where it was. It would probably instead be more 
confusing.

> BUG: Configuration 3 2 3 2; cursor in lower-left window; hit `='. All
> windows along the left side are replaced by a single window. With cursor in
> top-middle window, the windows is extended to full frame height, and one of
> the windows on the left side is deleted. None of this behavior seems
> comprehensible or right.

This is the way the function fit-window-to-buffer-works. Maybe I should 
use shrink-window-if-larger-than-buffer instead? Or

   =   fit-window-to-buffer-works
   -   shrink-window-if-larger-than-buffer

> BUG: Sometimes, when I hit `C-g', all windows but one disappear. That is,
> from, say, 5 windows I end up with only one.

C-g should quit window resizing and go back to the configuration you 
started with.

There might be some bug if help was quitted in an unexpected way. Some 
example would help.

> Suggestion: Bind `q' also to `winsize-quit'. Currently, it is
> self-inserting.

I have tried to avoid using alphabetic characters so that it is easy 
that all just quits resizing and self-insert.

But this is one of the points were I am not sure. The current use of key 
bindings during resizing is maybe inconsistent.

> I don't understand why you have (define-key [t] 'winsize-stop-and-execute).
> Why allow any keys to (exit and) self-insert? Why not make the user
> explicitly exit first? That's not hard for the user to do. Otherwise, they
> will get some surprises.
> 
> Why `4' for `other-window'? If a binding for this is really needed (not
> IMO), `o' is better.
> 
> Why bind both `mouse-1' and `down-mouse-1' to the same command?

Just because I was not sure which one is used for choosing window.

> Please take a look at the behavior of Bastien's code and perhaps my feedback
> that led to some of the changes he made. IMO, some of his UI is more natural
> than yours. But I like the idea of highlighting the selected window (but
> please also highlight the selected border).
> 
> Please think about adding simple window-resizing as the default behavior. I
> really think that 90% of the time a user will need and use only that; s?he
> will not bother to move a particular border. To me, it is overly complex to
> make a user reason in terms of border movement, if all s?he wants to do is
> increase or decrease the size of a window. Border movement is fine tuning
> that will rarely be needed, IMO.

I do not think it is a good idea personally. Here are some reasons:

- What would it mean to increase or decrease the window? Don't you care 
if it is done horizontally or vertically?

- If you do then why not use the arrow keys and move the border in the 
desired direction? That behaviour would be consistent with what most 
users expect I believe.

- Mixing different ways to do resizing might be very confusing.

- At least users on w32 are used to reszing with the arrow keys (if they 
use the keyboard for that).

> HTH.

Thanks for thinking about it. I am not writing this for myself (only ;-)

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> >> My main point was that there is no need to highlight any
> >> mode line except possibly the one along the border to be
> >> moved. The rest is just distraction. I'm not against
> >> highlighting, but only if it serves a purpose.
> >
> > I see that this has not changed. I reiterate the following suggestions:
> >
> > 1. There is no need to highlight the mode lines of the windows that are
> > *not* being resized - that serves only to distract.
>
> It serves a purpose, it shows that Emacs is now doing something
> different with the input you give. And changing the colors of the
> borders seems adequate since this is what you are currently working
> with, moving and/or deleting them.
>
> But I made this optional ;-)

Sorry, I don't understand what you are saying here. Something different from
what with what input you give? Changing the colors of which borders seems
adequate? I don't understand your last sentence at all.

The highlighting of all mode lines doesn't change depending on your input
(aside from the highlighting of the selected window's mode line). It is a
constant, and just represents noise - it doesn't indicate anything (except
that you are using `resize-windows').

> > 2. The window being resized is already highlighted using the background
> > overlay. There is no reason to also highlight its mode line -
> > *unless* the mode-line highlighting indicates that that particular
> > border is being moved (which it does not, for the moment).
>
> I thought the same myself, but I was not sure, since the selected window
> normally have another mode color. I made this an option to for that.

Sorry, I don't understand, again. Changing the mode line of the selected
window is not needed to simply show that the window is selected - you
already change the window background to show that.

> > 3. It would be very helpful if the mode line of the border
> > being moved were highlighted. That would not help with the
> > top border of a window at the top of the frame, and it would
> > not help with a vertical border, but at least it
> > would help with the other borders.
>
> Maybe, but wouldn't it be confusing when you exit window resizing, at
> least if you have choosen to not have any background color for the
> selected window (in this case Juri's proposal is better).

You have chosen to highlight the selected window's background, no? Why would
highlighting the border to be moved be confusing when you exit resizing? I
really do not follow you, sorry.

> > 4. For vertical borders, you can, I think, use something in the
> > fringe to indicate the border being moved. Again, I'm not an
> > expert on fringe, but this should be possible. IIUC, fringe is
> > window-specific, and the left and right can be manipulated separately.
>
> Didn't I tell that it looked impossible to use the fringes for this?

No, you said that you didn't know, and you thought that fringe was not
window-specific - but it is, AFAIK. What is the impossibility you see for
this?

> > 5. For consistency, the mode-line indication for moving a
> > horizontal border could be (a temporary display that is)
> > similar to whatever you use in the fringe.
>
> If it were possible, yes.

What is the impossibility you see?

> > 6. If you can't use fringe, then consider using the so-called "overlay
> > arrow". Or a temporary `display' property. Or something else.
> > (Fringe would be much better, however.) There should be some
> > indication of which border is the subject.
>
> Is not that tied to the buffer text? That means you can not position it
> were you want.

Yes, but there is some buffer text in the window, presumably. You need only
some line of text (preferably mid-window). This is not as good as using
fringe, admittedly, but it is better than abusing the mouse pointer.

> You have more freedom with the mouse pointer.

I don't know what freedom I have with it, but the mouse pointer is a bad
idea. It is either unnoticeable (if you aren't currently using the mouse) or
it is plain wrong (if you are using the mouse). It should reflect the mouse
position.

> >>>> 7. I hit `?' for help. I got no help, and all of the windows
> >>>> were blown away except one. I tried it other times, and the
> >>>> frame itself was blown away. The latter effect is from my
> >>>> code, but it indicates that `delete-window' was
> >>>> called for the last remaining window.
> >>> Thanks I will try to fix it. Probably something with popup frames.
> >> Yes, probably. Bastien had a similar problem. The solution was to use
> >> (with-output-to-temp-buffer "*Help*"...).
> >
> > This problem remains. Now, the help text replaces all windows
> > in the frame (no reason for that),
>
> Oh, yes, there is a reason. When you are trying to arrange the window
> borders to your taste I believe it would be irritating to get this
> destroyed by some help function tampering with the window layout.

Help in a separate frame does not tamper with the window layout.

> > and when I hit `q' the entire frame is deleted.
>
> Eh, sorry ;-) It is not supposed to do that. It should restore the
> window layout you had before you asked for help.
>
> There must be something I have missed about the handling of popup
> windows. I do not know very much about them since I do not use them
> myself. (I maximize all windows ...)

If you maximize all windows, then you will certainly have difficulty
implementing and testing a command for resizing windows. ;-)

> > Also, the *Help* buffer is currently not read-only.
>
> Oh. The help functions are not easy. Fixed. Thanks.
>
> > Please use (with-output-to-temp-buffer "*Help*"...) or
> > equivalent. It will solve the problem.
>
> You always do that with the normal help functions.

I don't know what that means. The above problems (popup frame, self-insert
keys, `q' etc.) should be solved if you just use that form. The *Help*
buffer should then be in help-mode.

> > [The reason that the frame is deleted in my case is no doubt
> > because I have redefined `delete-window' to delete the frame
> > also if the window is `one-window-p'. Without that redefinition,
> > a call to `delete-window' will do nothing if `one-window-p' -
> > it just raises an error that you can't delete
> > the sole window. That is not TRT either.]
>
> I wonder what happens. The only thing I do to make exit help resume the
> window resizing is to set `view-exit-action' to the function
> winsize-restore-after-help. Could you please look at that function and
> see if you can find anything suspicious there. I can not see anything
> myself.

No way I'm going to dive into view-exit-action - sorry. The
help-mode/view-mode code is quick-sand. Again, (with-output-to-temp-buffer
"*Help*"...) should take care of these things - try it.

> Which version of winsize.el are you using? I just uploaded a new version
> with the help buffer read-only problem fixed.

I used the last version you had posted before my reply: 0.94.

> > `!' is not the best choice for config saving, IMO. It usually indicates
> > something that requires care or has a non-reversible effect.
> > Saving a window config is entirely benign. Consider using `s'
> > or `C-x C-s' or similar.
>
> Doesn't it also mean "I like this!"?

Not to me. In some international signage, `!' means "Danger!". But I don't
really care which keys you use; it was just a suggestion.

> > You provided some feedback; thanks. Still, it would be better if the
> > feedback mentioned *which* border was selected, especially if
> > you don't show that visually.
>
> Thanks, added.
>
> > New problems I noticed:
> >
> > Please don't use the mouse pointer to try to indicate the
> > selected border. That's not what it is for.
>
> It is actually used to indicate the border while resizing w32 windows
> from the keyboard. In that case the mouse is moved back to where it was
> before resizing, but since we might to more here when resizing several
> windows, maybe splitting and deleting to I did not find it meaningful to
> put back the mouse where it was. It would probably instead be more
> confusing.

Well, add my vote to those who don't care for it, whether MS Windows uses it
or not. For pointing out the selected border, it's useless here - unless you
already know to look for it. And if you click mouse-1 yourself, it is
downright confusing, since the pointer then doesn't correspond to where you
click.

> > BUG: Configuration 3 2 3 2; cursor in lower-left window; hit `='. All
> > windows along the left side are replaced by a single window.
> > With cursor in top-middle window, the windows is extended to full
> > frame height, and one of the windows on the left side is deleted.
> > None of this behavior seems comprehensible or right.
>
> This is the way the function fit-window-to-buffer-works. Maybe I should
> use shrink-window-if-larger-than-buffer instead? Or
>
>    =   fit-window-to-buffer-works
>    -   shrink-window-if-larger-than-buffer

I don't know. I'm unfamiliar with those commands. I only know that the
behavior I see doesn't correspond to anything I can make sense of or find
useful (in the cases I mentioned). If the functions you use don't do what's
right for this context, then you might want to use something else.

> > BUG: Sometimes, when I hit `C-g', all windows but one
> > disappear. That is, from, say, 5 windows I end up with only one.
>
> C-g should quit window resizing and go back to the configuration you
> started with.

Yes, it should.

> There might be some bug if help was quitted in an unexpected way. Some
> example would help.

It has nothing to do with using help.

emacs -Q
(setq pop-up-frames t)
M-x resize-windows
3 2 3 2
C-g

Bam!

> > Suggestion: Bind `q' also to `winsize-quit'. Currently, it is
> > self-inserting.
>
> I have tried to avoid using alphabetic characters so that it is easy
> that all just quits resizing and self-insert.
>
> But this is one of the points were I am not sure. The current use of key
> bindings during resizing is maybe inconsistent.
>
> > I don't understand why you have (define-key [t]
> > 'winsize-stop-and-execute). Why allow any keys to (exit and)
> > self-insert? Why not make the user explicitly exit first?
> > That's not hard for the user to do. Otherwise, they
> > will get some surprises.

That responds to what you just wrote. Why not have a standard way to exit
and stick to it?

> > Why `4' for `other-window'? If a binding for this is really needed (not
> > IMO), `o' is better.
> >
> > Why bind both `mouse-1' and `down-mouse-1' to the same command?
>
> Just because I was not sure which one is used for choosing window.

`mouse-1' is the usual binding for `mouse-set-point'. That should be fine.

> > Please take a look at the behavior of Bastien's code and
> > perhaps my feedback that led to some of the changes he made.
> > IMO, some of his UI is more natural
> > than yours. But I like the idea of highlighting the selected window (but
> > please also highlight the selected border).
> >
> > Please think about adding simple window-resizing as the default
> > behavior. I really think that 90% of the time a user will need
> > and use only that; s?he will not bother to move a particular
> > border. To me, it is overly complex to make a user reason in
> > terms of border movement, if all s?he wants to do is increase
> > or decrease the size of a window. Border movement is fine tuning
> > that will rarely be needed, IMO.
>
> I do not think it is a good idea personally. Here are some reasons:
>
> - What would it mean to increase or decrease the window? Don't you care
> if it is done horizontally or vertically?

See Bastien's alternate mode (which was the default mode before, and should
be again), which resizes the selected window. Both horizontal and vertical
resizing are available. Please give his code a try, to see what it does.

There is no reason to start with the complex if the simple does the job.
Most of the time, a user will just want to resize a window or two, not
necessarily move particular borders.

> - If you do then why not use the arrow keys and move the border in the
> desired direction? That behaviour would be consistent with what most
> users expect I believe.

If a user wants only (horiz or vert) resizing, then it doesn't matter which
border moves, as long as the window is resized (horiz or vert).

> - Mixing different ways to do resizing might be very confusing.

See Bastien's code. There is no mixing. There are two possible modes. The
default mode is border movement. The alternate mode is window resizing. It
should be the other way around: simple as default, complex as alternate;
gross tuning as default, fine-tuning as alternate.

> - At least users on w32 are used to reszing with the arrow keys (if they
> use the keyboard for that).

How many Windows users use the keyboard to resize frames? And does that
matter here? And you're talking about resizing frames anyway, in that case.

> Thanks for thinking about it. I am not writing this for myself (only ;-)

My main suggestions are (1) simplify the UI, and (2) find a good way to
indicate which border is active (for border movement).

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Drew Adams wrote:
> The highlighting of all mode lines doesn't change depending on your input
> (aside from the highlighting of the selected window's mode line). It is a
> constant, and just represents noise - it doesn't indicate anything (except
> that you are using `resize-windows').

It indicates just that (that you are using `resize-windows' at the 
moment). You might for example leave the computer for a while and come 
back. Isn't it good then to know that you are using `resize-windows'? 
You may have forgotten, but Emacs knows - and behaves a bit differently ;-)

> Sorry, I don't understand, again. Changing the mode line of the selected
> window is not needed to simply show that the window is selected - you
> already change the window background to show that.

Those two are alternatives that you can turn on/off with two defcustoms.

> No, you said that you didn't know, and you thought that fringe was not
> window-specific - but it is, AFAIK.

You are right.

> What is the impossibility you see?

Changing the colors of one of the fringes in a window.

>> You have more freedom with the mouse pointer.
> 
> I don't know what freedom I have with it,

You can position the mouse pointer wherever you want.

> but the mouse pointer is a bad
> idea. It is either unnoticeable (if you aren't currently using the mouse) or
> it is plain wrong (if you are using the mouse).

As I said in the portion you are replying to here I do not think that is 
  wrong to use the mouse pointer to give feedback when you are working 
from the keyboard. That is the way the window manager in w32 sometimes 
does it. (It does exactly that when resizing a window from the keyboard.)

Of course one can have different opinions wheter this is good or bad, 
but "plain wrong" is a bit to strong here in my taste.

> Help in a separate frame does not tamper with the window layout.

It is a good point and I have already said that if it is desireable I 
could add support for it. It is however not quite as simple as one might 
expect in this case.

> If you maximize all windows, then you will certainly have difficulty
> implementing and testing a command for resizing windows. ;-)

;-)

>>> Please use (with-output-to-temp-buffer "*Help*"...) or
>>> equivalent. It will solve the problem.
>> You always do that with the normal help functions.
> 
> I don't know what that means. The above problems (popup frame, self-insert
> keys, `q' etc.) should be solved if you just use that form. The *Help*
> buffer should then be in help-mode.

I am afraid that you might be misunderstanding the problem here. What I 
have been trying to do is to temporary show the help and after this 
return to resizing for those people that do not normally use popup 
frames for help.

At the moment I have not taken care of popup help. I can do that if it 
is desireable, but it requires some careful thought about how to do it 
in this case. You are welcome with suggestions. (In fact I hoped that 
you would have some thoughts about this.) But please then try to answer 
the following questions:

- When showing help in a popup frame the popup frame should of course 
not be in a resizing state. Should resizing be resumed when quitting help?

- If yes how should that be indicated to the user?

- If no, when should resizing be resumed?

>>    =   fit-window-to-buffer-works
>>    -   shrink-window-if-larger-than-buffer
> 
> I don't know. I'm unfamiliar with those commands. I only know that the
> behavior I see doesn't correspond to anything I can make sense of or find
> useful (in the cases I mentioned). If the functions you use don't do what's
> right for this context, then you might want to use something else.

I decided to give the user the choice (= fit, - shrink).

>> C-g should quit window resizing and go back to the configuration you
>> started with.
> 
> Yes, it should.

Thanks.

> emacs -Q
> (setq pop-up-frames t)
> M-x resize-windows
> 3 2 3 2
> C-g
> 
> Bam!
> 
> I used the last version you had posted before my reply: 0.94.

Please try the latest version instead.

> That responds to what you just wrote. Why not have a standard way to exit
> and stick to it?

No problem. I actually wanted some feedback on this. The current way try 
to mimick how isearch exits, but that might be a bad choice in this case.

> `mouse-1' is the usual binding for `mouse-set-point'. That should be fine.

Thanks.

> See Bastien's code. There is no mixing. There are two possible modes. The
> default mode is border movement. The alternate mode is window resizing. It
> should be the other way around: simple as default, complex as alternate;
> gross tuning as default, fine-tuning as alternate.

Unfortunately I think it is (or rather was) utterly confusing for more 
complex window layouts even though the intention to simply was nice. 
(For simple layouts it was fine.)

> My main suggestions are (1) simplify the UI, and (2) find a good way to
> indicate which border is active (for border movement).

(1) can't be done without (2) here. The problem is really that it is 
hard to find a good way to do (2). That was what I tried to explain from 
the beginning. Coloring the relevant vertical border or fringe would IMO 
opinion be the best solution. (An additional possibility is to change 
the mouse pointer shape, but that is a lot of work.)

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> > The highlighting of all mode lines doesn't change depending on
> > your input (aside from the highlighting of the selected
> > window's mode line). It is a constant, and just represents
> > noise - it doesn't indicate anything (except
> > that you are using `resize-windows').
>
> It indicates just that (that you are using `resize-windows' at the
> moment).

That's too heavy-handed a way to indicate that, IMO. Consider something
else - perhaps a mode-line indication. Users won't want to see neon mode
lines *everywhere*.

> You might for example leave the computer for a while and come
> back. Isn't it good then to know that you are using `resize-windows'?
> You may have forgotten, but Emacs knows - and behaves a bit
> differently ;-)

1. If the feedback is reasonable, then you will soon realize that you left
Emacs in such a "mode". Instead, this is like parking a meter-square PostIt
on your screen just to remind yourself.

2. And besides, you already have the selected window's changed background to
let you know. If that isn't enough, then highlighting all of the mode lines
won't help more. What would be next, play loud music? ;-)

> > Sorry, I don't understand, again. Changing the mode line of the selected
> > window is not needed to simply show that the window is selected - you
> > already change the window background to show that.
>
> Those two are alternatives that you can turn on/off with two defcustoms.

Oh, I see (I think). You are saying that the selected window can be
indicated by highlighting its mode line or highlightings its background or
both. Is that it? If so, then it would be clearer to combine that into a
single defcustom (`choice'). And the default behavior should *not* be to
highlight both. I have no problem with either alone, personally.

> > No, you said that you didn't know, and you thought that fringe was not
> > window-specific - but it is, AFAIK.
>
> You are right.
>
> > What is the impossibility you see?
>
> Changing the colors of one of the fringes in a window.

I don't see why that's impossible - just show only one of the fringes. You
don't necessarily need to change the color. You can use some mark in the
fringe if you can't change the color (but I think you can). Left and right
fringe are independent, AFAIK, and they can be almost anything, visually
(AFAIK). Again, I'm no expert on fringe (I turn it off, in fact), but I
think these things are possible.

And, again, any use of fringes for this should be temporary, for the
duration only. You should restore whatever fringe preference the user had
originally.

> >> You have more freedom with the mouse pointer.
> >
> > I don't know what freedom I have with it,
>
> You can position the mouse pointer wherever you want.

My impression is that you (Lennart) reposition it where you want; it doesn't
stay where I want (at the mouse position).

> > but the mouse pointer is a bad idea. It is either
> > unnoticeable (if you aren't currently using the mouse) or
> > it is plain wrong (if you are using the mouse).
>
> As I said in the portion you are replying to here I do not think that is
> wrong to use the mouse pointer to give feedback when you are working
> from the keyboard.

How do you know I am working from the keyboard? You might have an argument,
if you knew that I didn't care about the mouse pointer. Then, perhaps, you
could co-opt the pointer for another purpose. As it happens, I do care about
the pointer, and I do use the mouse - e.g. to select the window to operate
on. Touches pas a mon pointeur.

> That is the way the window manager in w32 sometimes
> does it. (It does exactly that when resizing a window from the keyboard.)

So what? Why is that relevant? And those "windows" are really frames anyway.
I don't see how this argues for taking over the mouse pointer here to
indicate the active border.

> Of course one can have different opinions wheter this is good or bad,
> but "plain wrong" is a bit to strong here in my taste.

It is plain wrong if you are using the mouse, because in that case you
depend on the pointer representing the mouse position. You yourself
introduced your defense of this by saying "when you are working from the
keyboard". It is unnoticeable if you are working from the keyboard (unless
you read the doc), and it is plain wrong if you are working with the mouse.
In the latter case, you expect the pointer to tell you where the mouse is.

> > Help in a separate frame does not tamper with the window layout.
>
> It is a good point and I have already said that if it is desireable I
> could add support for it. It is however not quite as simple as one might
> expect in this case.

(with-output-to-temp-buffer "*Help*"...) should take care of my objections.
Try it.

> >>> Please use (with-output-to-temp-buffer "*Help*"...) or
> >>> equivalent. It will solve the problem.
> >>
> >> You always do that with the normal help functions.
> >
> > I don't know what that means. The above problems (popup frame,
> > self-insert keys, `q' etc.) should be solved if you just use
> > that form. The *Help* buffer should then be in help-mode.
>
> I am afraid that you might be misunderstanding the problem here. What I
> have been trying to do is to temporary show the help and after this
> return to resizing for those people that do not normally use popup
> frames for help.

(with-output-to-temp-buffer "*Help*"...) should work regardless of the value
of pop-up-frames. If pop-up-frames is nil, then it uses a window, not the
whole frame, but if you want to use the whole frame in that case, then just
test pop-up-frames before doing what you do now, and, if non-nil, use
(with-output-to-temp-buffer "*Help*"...) instead.

> At the moment I have not taken care of popup help. I can do that if it
> is desireable, but it requires some careful thought about how to do it
> in this case. You are welcome with suggestions. (In fact I hoped that
> you would have some thoughts about this.) But please then try to answer
> the following questions:
>
> - When showing help in a popup frame the popup frame should of course
> not be in a resizing state. Should resizing be resumed when quitting help?

It doesn't matter to me. Resuming is no doubt doable, but why bother? Keep
it simple.

What is difficult for a user about issuing the command resize-windows again?
People won't be asking for help every four seconds. They won't mind hitting
the resize-windows key again after reading the help. And the benefit of
being able to see their window config while reading the help outweighs the
cost of needing to hit that key again.

> - If yes how should that be indicated to the user?
> - If no, when should resizing be resumed?

Save the configuration and exit. The user will hit the resize-windows key
again if s?he wants.

> >>    =   fit-window-to-buffer-works
> >>    -   shrink-window-if-larger-than-buffer
> >
> > I don't know. I'm unfamiliar with those commands. I only know that the
> > behavior I see doesn't correspond to anything I can make sense
> > of or find useful (in the cases I mentioned). If the functions
> > you use don't do what's right for this context, then you might
> > want to use something else.
>
> I decided to give the user the choice (= fit, - shrink).

Nothing wrong with choices. I described behavior that doesn't work (windows
disappearing unexpectedly), that's all.

> > emacs -Q
> > (setq pop-up-frames t)
> > M-x resize-windows
> > 3 2 3 2
> > C-g
> >
> > Bam!
> >
> > I used the last version you had posted before my reply: 0.94.
>
> Please try the latest version instead.

Where is it?

> > That responds to what you just wrote. Why not have a standard
> > way to exit and stick to it?
>
> No problem. I actually wanted some feedback on this. The current way try
> to mimick how isearch exits, but that might be a bad choice in this case.

I think it is. resize-windows is a mix of functionalities (split, resize,
etc.). Isearch is the wrong model here, IMO.

BTW, an argument could be made that Isearch too should be exited in a
uniform way (only a few keys, such as C-g and RET). But RMS, in particular,
wants control keys to do their thing immediately. This has come up nearly
every time someone wants to bind a control-key sequence in the isearch map.
Little by little, some control keys (e.g. C-y, C-w) have been added to the
map, but it's requires a "discussion" each time.

From the user's point of view, the exiting rule is therefore complex. Here
is what the manual says:

 "<RET> is necessary only if the next command you want
  to type is a printing character, <DEL>, <RET>, or
  another character that is special within searches
  (`C-q', `C-w', `C-r', `C-s', `C-y', `M-y', `M-r',
  `M-c', `M-e', and some other meta-characters)."

IOW, you need to be aware of each key that is special within searches, in
order to know which keys (all the others) exit Isearch. Not friendly to
newbies, and, IMO, not all that useful to non-newbies. C'est la vie.

> > See Bastien's code. There is no mixing. There are two possible
> > modes. The default mode is border movement. The alternate mode
> > is window resizing. It should be the other way around: simple
> > as default, complex as alternate;
> > gross tuning as default, fine-tuning as alternate.
>
> Unfortunately I think it is (or rather was) utterly confusing for more
> complex window layouts even though the intention to simply was nice.
> (For simple layouts it was fine.)

Resizing is a simple operation. Most of the time, it suffices for what users
need, IMO. If they need more complex maneuvering, then they can have
recourse to the heavy lifting of border movement. You should not plunge them
immediately into something that is more complex and requires more thought.
If the aim is simply to increase or decrease a window's horizontal or
vertical dimension (which it is 80% of the time), then one shouldn't need to
think in terms of selecting a border to move and a direction to move it.

> > My main suggestions are (1) simplify the UI, and (2) find a good way to
> > indicate which border is active (for border movement).
>
> (1) can't be done without (2) here.

I don't understand that statement. I offered some suggestions for
simplification, from highlighting to help display to default behavior
(resize vs move border).

> The problem is really that it is
> hard to find a good way to do (2). That was what I tried to explain from
> the beginning. Coloring the relevant vertical border or fringe would IMO
> opinion be the best solution.

We agree on that last part. And highlight the mode line, for a horizontal
border (except top).

BTW, for a top window top border, you might temporarily add a header line as
the selected-border indicator.

> (An additional possibility is to change
> the mouse pointer shape, but that is a lot of work.)

My advice is to stay away from the mouse pointer for things that have
nothing to do with the mouse.

HTH.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Robert J. Chassell]

Minor typo:

    Put back mode line colors and keymaps that was changed.
                                               ^^^
That should be `were'.

    (defvar winsize-border-hor nil
      "Used internally to keep border choice on the same side.

Please use an imperative!  

    Use internally to keep border choice on the same side.

I know, I make the same mistake since a developer notes what he or
she had done, but ...

There are other phrases like this and other minor typos ... you will
probably see them if you don't look at the code for a while ...

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Robert J. Chassell wrote:
> Minor typo:
> 
>     Put back mode line colors and keymaps that was changed.
>                                                ^^^
> That should be `were'.
> 
>     (defvar winsize-border-hor nil
>       "Used internally to keep border choice on the same side.
> 
> Please use an imperative!  
> 
>     Use internally to keep border choice on the same side.
> 
> I know, I make the same mistake since a developer notes what he or
> she had done, but ...
> 
> There are other phrases like this and other minor typos ... you will
> probably see them if you don't look at the code for a while ...

Feedback on those errors are very welcome! Just mail them directly to me.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I have worked a bit with bw-interactive.el along the ideas that have
> surfaced here (and some I had before). I have renamed it to winsize.el.
>
> It is mainly restructured for more flexibility. And some bugs have
> probably been fixed + the features are more worked through.

And here comes window-edit.el 0.9! :)

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

Changes:

- I took your idea of using M-<arro> instead of S-<arrow> to select the
  adjacent window.  Now S-<arrow> temporarily negates the increment.

- I also use the "move border" mode by default.  I think window-edit.el
  is more likely to be used for this.

- When a border cannot be moved further, window-edit tries to move the
  opposite border to the same direction (see the docstring).

Feedback welcome!

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

On 11/13/07, Bastien <bzg@altern.org> wrote:

> - I took your idea of using M-<arrow> instead of S-<arrow> to select the
>   adjacent window.  Now S-<arrow> temporarily negates the increment.

Could you please just add options to configure the modifiers for
"adjacent window" and "negate increment" keys?

I'm using s-{up,down,left,right} for windmove (via
`windmove-default-keybindings'), because S-{up,down,left,right} is
used to select the region in cua-selection-mode, and it's quite
disorienting to alternate between s-arrow (in the normal case) and
M-arrow (while in window-edit). I would like to be able to setup both
to the same modifier.

> - When a border cannot be moved further, window-edit tries to move the
>   opposite border to the same direction (see the docstring).

This is highly non-intuitive (to me). Is there any posibility to
optionally disable it?

Other than these minor nitpicks, the package is great. Thanks!

             Juanma

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/13/07, Bastien <bzg@altern.org> wrote:
>
>> - I took your idea of using M-<arrow> instead of S-<arrow> to select the
>>   adjacent window.  Now S-<arrow> temporarily negates the increment.
>
> Could you please just add options to configure the modifiers for
> "adjacent window" and "negate increment" keys?
>
> I'm using s-{up,down,left,right} for windmove (via
> `windmove-default-keybindings'), because S-{up,down,left,right} is
> used to select the region in cua-selection-mode, and it's quite
> disorienting to alternate between s-arrow (in the normal case) and
> M-arrow (while in window-edit). I would like to be able to setup both
> to the same modifier.

I wasn't aware that S-{up,down,left,right} was the default keys for
`windmove-default-keybindings'. I guess it is better to stick to these
keys for selecting adjacent windows in window-edit as well.

As for options for configuring these keys, I will add them.  

>> - When a border cannot be moved further, window-edit tries to move the
>>   opposite border to the same direction (see the docstring).
>
> This is highly non-intuitive (to me). Is there any posibility to
> optionally disable it?

Yes, good idea.

> Other than these minor nitpicks, the package is great. Thanks!

Thanks,

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    > - I took your idea of using M-<arrow> instead of S-<arrow> to select the
    >   adjacent window.  Now S-<arrow> temporarily negates the increment.

    Could you please just add options to configure the modifiers for
    "adjacent window" and "negate increment" keys?

There is no need to add options just to choose different keys.
All keymaps are customizable.  The thing to do is get rid of the
unusual code that copies the bindings of windmove, and put these
bindings directly into the keymap in the standard way.  Then people
can change these bindings in the standard ways.

    > - When a border cannot be moved further, window-edit tries to move the
    >   opposite border to the same direction (see the docstring).

    This is highly non-intuitive (to me). Is there any posibility to
    optionally disable it?

I think I agree with you.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juanma Barranquero]

On 11/14/07, Richard Stallman <rms@gnu.org> wrote:

> The thing to do is get rid of the
> unusual code that copies the bindings of windmove, and put these
> bindings directly into the keymap in the standard way.  Then people
> can change these bindings in the standard ways.

I can live with that.

             Juanma

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> And here comes window-edit.el 0.9! :)
>
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el
>
> Feedback welcome!

This is really nice!  May I ask for two additional things:

1. Could you allow the same keys to select a different window
that users bind in .emacs?  I.e. additonally to the `o' key
you provide just look to which keys `other-window' is bound
(using `(where-is-internal 'other-window)') and accept the same
keys in window-edit mode for selecting a different window.

2. A key to abort changes and restore the initial window
configuration (for example, like in wdired `C-c ESC'
to abort changes, and `C-c C-c' to accept changes).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

> 1. Could you allow the same keys to select a different window
> that users bind in .emacs?  I.e. additonally to the `o' key
> you provide just look to which keys `other-window' is bound
> (using `(where-is-internal 'other-window)') and accept the same
> keys in window-edit mode for selecting a different window.

Excellent, I'll do this.

> 2. A key to abort changes and restore the initial window
> configuration (for example, like in wdired `C-c ESC'
> to abort changes, and `C-c C-c' to accept changes).

I am not sure to understand this: you can already restore the initial
configuration by pressing `r' repeatedly until you reach this config.

Maybe we could save the initial configuration separately and restore it
with a dedicated key like `_'.

Or better: only validate the visible window configuration (with last
changes) if the user quit the mode with C-c C-c.  If the user quit the
mode with C-g or q (or C-c ESC), then the initial configuration will be
restored.

What do you think?

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    I explained that in the case of non-nil `pop-up-frames', it does interfere -
    or, rather, continuing to read events interferes with being able to use the
    help display (depending on the size of its frame).

Interference in that direction doesn't really matter.
Looking at the help display is not the end, just means to help.
If the end interferes with the means, that suggests changing the
means slightly so that they work better.

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

>     I explained that in the case of non-nil `pop-up-frames', it
>     does interfere - or, rather, continuing to read events
>     interferes with being able to use the
>     help display (depending on the size of its frame).
>
> Interference in that direction doesn't really matter.
> Looking at the help display is not the end, just means to help.
> If the end interferes with the means, that suggests changing the
> means slightly so that they work better.

I suggested changing the means (help display), which in my case was not
readable.

Anyway, Bastien has already fixed the problem. There remains a
help-mode/view-mode bug that prevents `q' in *Help* from quitting it.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> Borders moving might be somewhat inconsistent, but I could find any easy
> way to predict the changes made by `shrink-window' and `enlarge-window'
> in all possible window configurations.  Anyway, this should be accurate
> in 95% of the real-life cases, and I do agree that the resize-mode will
> be the most useful anyway.

Have you tried to use `adjust-window-trailing-edge'?


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Borders moving might be somewhat inconsistent, but I could find any easy
>> way to predict the changes made by `shrink-window' and `enlarge-window'
>> in all possible window configurations.  Anyway, this should be accurate
>> in 95% of the real-life cases, and I do agree that the resize-mode will
>> be the most useful anyway.
>
> Have you tried to use `adjust-window-trailing-edge'?

I didn't know about this, thanks!  It's indeed much simpler to use this.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    Borders moving might be somewhat inconsistent, but I could find any easy
    way to predict the changes made by `shrink-window' and `enlarge-window'
    in all possible window configurations.

To make that reliable, use `adjust-window-trailing-edge'
instead of `shrink-window' and `enlarge-window'.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     Borders moving might be somewhat inconsistent, but I could find any easy
>     way to predict the changes made by `shrink-window' and `enlarge-window'
>     in all possible window configurations.
>
> To make that reliable, use `adjust-window-trailing-edge'
> instead of `shrink-window' and `enlarge-window'.

Yes, but `adjust-window-trailing-edge' knows only about the bottom and
the right edge.  I cannot handle every border move with this.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    Yes, but `adjust-window-trailing-edge' knows only about the bottom and
    the right edge.  I cannot handle every border move with this.

You can by specifying the proper choice of window as argument.
Specify a window for which the desired edge is the bottom or right
edge.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     Yes, but `adjust-window-trailing-edge' knows only about the bottom and
>     the right edge.  I cannot handle every border move with this.
>
> You can by specifying the proper choice of window as argument.
> Specify a window for which the desired edge is the bottom or right
> edge.

Thanks for the hint.  

I generalized the use of `adjust-window-trailing-edge' in the
window-edit.el 0.9:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Robert J. Chassell]

`window-edit' should only disable some commands.

    I generalized the use of `adjust-window-trailing-edge' in the
    window-edit.el 0.9:

That is good, but in
today's GNU Emacs CVS snapshot, Tue, 2007 Nov 13  10:51 UTC
GNU Emacs 23.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
started with
    emacs -q -D -l ~bob/emacs-21/window-edit.el \
    --visit ~bob/emacs-21/window-edit.el --eval="(window-edit)"

when I tried to find out the name of the command that moved the border
of the upper window (i.e., the lower border of that window) with the
upper arrow key, `C-h k' (describe-key) failed and I continued to move
the border.

I was not able to exit Emacs with `C-x C-c'
(save-buffers-kill-terminal) either, not until I quit editing the
windows with `q'.  Then I was able to quit.

Certainly, `window-edit' should not disable `C-h k' (describe-key) or
`C-x C-c' (save-buffers-kill-terminal).

The other library, winsize.el, also does not let you discover what an
arrow key does when C-x + is active.


On an other topic, in the documentation for `window-edit', rather than
use the spoken but not the written term `wise' as in `direction-wise'
you might write 'as directed by arrows'.  The original word is in a
line 57 characters long; the new phrase adds seven characters but the
total is still only 64 characters.

Indeed, please avoid hardwiring the `window-edit' commands.  You might
want to display them in the documentation in the normal way.  (You
would have to reword the documentation and maybe the names of the
commands.)

For example, a somewhat similar function is artist-mode.  That saves
the previous configuration before it toggles on.  The function is in a
library that has an `artist-mode-map' although the function's
documentation does tell you in a hardwired fashion what the
traditional three mouse buttons do.  As for disabling other commands,
in artist-mode, `C-h k' (describe-key) says the down arrow key evokes
`artist-next-line'.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Robert J. Chassell wrote:
> when I tried to find out the name of the command that moved the border
> of the upper window (i.e., the lower border of that window) with the
> upper arrow key, `C-h k' (describe-key) failed and I continued to move
> the border.
> 
> I was not able to exit Emacs with `C-x C-c'
> (save-buffers-kill-terminal) either, not until I quit editing the
> windows with `q'.  Then I was able to quit.
> 
> Certainly, `window-edit' should not disable `C-h k' (describe-key) or
> `C-x C-c' (save-buffers-kill-terminal).
> 
> The other library, winsize.el, also does not let you discover what an
> arrow key does when C-x + is active.


Fixed in the new version of winsize.el:

   http://ourcomments.org/Emacs/DL/elisp/winsize.el

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
>> The other library, winsize.el, also does not let you discover what an
>> arrow key does when C-x + is active.
> 
> 
> Fixed in the new version of winsize.el:
> 
>   http://ourcomments.org/Emacs/DL/elisp/winsize.el


Fixed some bug in help handling during resizing in version 0.94 of 
winsize.el. Same link as above.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> when I tried to find out the name of the command that moved the border
> of the upper window (i.e., the lower border of that window) with the
> upper arrow key, `C-h k' (describe-key) failed and I continued to move
> the border.
>
> I was not able to exit Emacs with `C-x C-c'
> (save-buffers-kill-terminal) either, not until I quit editing the
> windows with `q'.  Then I was able to quit.
>
> Certainly, `window-edit' should not disable `C-h k' (describe-key) or
> `C-x C-c' (save-buffers-kill-terminal).

All this is because window-edit doesn't have "real" commands (except the
window-edit command itself).  Rather it binds functions to events inside
a loop constantly waiting for them.

I do understand this is not very convenient, and I think I'll consider
implementing `window-edit' as a real mode.  Then we'll have a map and
the mode won't prevent usual commands from being invocated.

> On an other topic, in the documentation for `window-edit', rather than
> use the spoken but not the written term `wise' as in `direction-wise'
> you might write 'as directed by arrows'.  The original word is in a
> line 57 characters long; the new phrase adds seven characters but the
> total is still only 64 characters.

Thanks very much, I'll fix this.  I'm not a native english speaker, so
inputs like those are really useful.

> Indeed, please avoid hardwiring the `window-edit' commands.  You might
> want to display them in the documentation in the normal way.  (You
> would have to reword the documentation and maybe the names of the
> commands.)

They won't be hardwired when I implement the mode and its map.

> For example, a somewhat similar function is artist-mode.  That saves
> the previous configuration before it toggles on.  

Thanks for pointing this out.  

Here is what I plan to do: M-x `window-edit-mode' (or
`window-resize-mode', which sounds better IMO) will store the initial
configuration, let the user resize the windows as i does now, then the
user will have to validate the changes by exiting the mode with C-c C-c.

Would that be okay?

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Robert J. Chassell]

    I think I'll consider implementing `window-edit' as a real mode.

Excellent!

    M-x `window-edit-mode' (or `window-resize-mode', which sounds
    better IMO) ...

`window-resize-mode' is better because that is what you are doing.
With `window-edit-mode', someone might think you are editing text in a
window ...

    ... the user will have to validate the changes by exiting the mode
    with C-c C-c.

I think that is good, but I will have to wait and experience it before
I can really judge.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     I think I'll consider implementing `window-edit' as a real mode.
>
> Excellent!

Done.  I've put window-resize.el here:

  http://www.cognition.ens.fr/~guerry/u/window-resize.el 

M-x window-resize-mode now enters a mode where you can interactively
resize windows.  `q' quit the mode and cancel the change.  `RET' keeps
the changes and quit the mode.

AFAIK, there are a few differences with Lennart's package:

- no colors
- more feedback on commands
- window configuration ring (`s' and `r')
- don't change the mouse pointer position
- interactively set the increment value
- switch from border moving (default) to normal resizing
- Use S-<arrow> for calls to windmove commands
- M-<arrow> have a single meaning: negate the increment

Hope it meets most needs around.  This is only 0.1 though, so don't
expect it to work perfectly!

Thanks for feedback so far.

PS: I keep window-edit.el somewhere, I think some people might prefer to
be in a loop while editing the window configuration...

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Bastien <bzg@altern.org> writes:

> AFAIK, there are a few differences with Lennart's package:
>
> - window configuration ring (`s' and `r')

Oops sorry, this is in latest winsize.el.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Bastien wrote:
>
>> Done.  I've put window-resize.el here:
>>
>>   http://www.cognition.ens.fr/~guerry/u/window-resize.el 
>>
>> M-x window-resize-mode now enters a mode where you can interactively
>> resize windows.  `q' quit the mode and cancel the change.  `RET' keeps
>> the changes and quit the mode.
>
> If you want to use a mode I think you should use a global minor mode and
> place that in emulation-mode-map-alist at the front.

I'm not convinced.  Why would anyone use window-resize as a minor mode?
It uses a very specific keymap and I don't see why people would like to
access major-mode features while being in a window-resize-mode session.

Maybe the name window-resize-mode is confusing and should rather be
window-resize only.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

Lennart Borgman has been working on a similar package, now called
winsize.el, which is implemented using the ordinary command reader
with a special keymap.  That's the basic difference between these two
packages.

If it is now clear that using the ordinary command reader is the best
approach, we may as well go with winsize.el.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Lennart Borgman has been working on a similar package, now called
> winsize.el, which is implemented using the ordinary command reader
> with a special keymap.  That's the basic difference between these two
> packages.
>
> If it is now clear that using the ordinary command reader is the best
> approach, we may as well go with winsize.el.

I started to rewrite window-edit.el (now window-resize-mode.el) so that
it implements a command reader.  I will post it by tomorrow.

I don't know what will be the differences with Lennart's package but
maybe some of them will surely deserve vote/discussion in this list.

In any case, Lennart has been very responsive to all suggestions -- and
I've been trying to be as well! -- so it is very likely that the set of
features will converge at some point.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Hi Lennart,

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I guess the structure will be rather similar. It is quite a bit of work
> to get all features in place, check the newest version of winsize.el:
>
>   http://ourcomments.org/Emacs/DL/elisp/winsize.el

Yes, I've checked it.  The documentation is clearer indeed!

> I have tried to explain at least the surface features there in the doc
> string of resize-windows. Help is tricky to get to work and for the
> moment I have left out popup help (though it is quite possible to get it
> into the current structure for help handling - I believe ;-).

I'm using a simple (with-output-to-temp-buffer "*Help" ...) as I don't
think people will need this help window *that* often.

> I am not sure what features you will be missing in this version, but
> your feedback is welcome.

I implemented window-resize.el as a mode because it was easier for me to
read my code than to check whether yours had room for improvements on
some features (even if I know you know it has).  The ring for window
configurations in winsize.el is okay, and I like the `!' `<' '>' keys.

I'm not into colors and mouse pointer movements, but that's just a
matter of taste and it's optional, as you stated before.

What I still found a bit confusing is the fact that the M-<arrow> keys
either select a window or select a border to move.  In any case, thanks
for the exchange of ideas!

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

> What I still found a bit confusing is the fact that the M-<arrow> keys
> either select a window or select a border to move.  In any case, thanks
> for the exchange of ideas!

It always selects a border, but move to a new window too if the selected 
border is in the direction of the movement.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
>> What I still found a bit confusing is the fact that the M-<arrow> keys
>> either select a window or select a border to move.  In any case, thanks
>> for the exchange of ideas!
> 
> It always selects a border, but move to a new window too if the selected 
> border is in the direction of the movement.

Eh, and maybe that was not quite correct. I should have written "the 
previously selected border":

It always selects a border, but moves to a new window too if the 
previously selected border is in the direction of the movement.

Doing it this way you can always use the M-<arrow> keys to select a border.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Lennart Borgman (gmail) wrote:
>>> What I still found a bit confusing is the fact that the M-<arrow> keys
>>> either select a window or select a border to move.  In any case, thanks
>>> for the exchange of ideas!
>>
>> It always selects a border, but move to a new window too if the
>> selected border is in the direction of the movement.
>
> Eh, and maybe that was not quite correct. I should have written "the
> previously selected border":
>
> It always selects a border, but moves to a new window too if the
> previously selected border is in the direction of the movement.
>
> Doing it this way you can always use the M-<arrow> keys to select a
> border.

Yes.  Now I understand why the colors and the mouse pointer jumps.
Because if M-<arrow> does not move a border because it jumped to the
opposite border, then you have to make it clear to the user, who might
have thought M-<arrow> will immediately move the border instead.

FWIW, I prefer to spare the user with the select-border step.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> Yes.  Now I understand why the colors and the mouse pointer jumps.
> Because if M-<arrow> does not move a border because it jumped to the
> opposite border, then you have to make it clear to the user, who might
> have thought M-<arrow> will immediately move the border instead.

The current window is highlighted by the special face of the mode-line,
so there is no need in additional highlighting.  However, there is no
special indication of the current window border in Emacs, but I think
mouse movements is not an adequate replacement for the missing window
border highlighting.  Instead of inventing special indications for the
selected window border, it would be better to use one set of keys
(e.g. arrows) to resize the right/bottom window border, and another set of
keys (e.g. M-arrows or S-arrows) to resize the opposite left/top window
border (while using M-arrows or S-arrows to switch windows).

This will help avoiding unnatural indications in winsize.el, and will be
better than using an inconvenient key scheme in window-resize.el where
the same set of arrows (either arrows or M-arrows) is used for resizing
opposite borders.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>> Yes.  Now I understand why the colors and the mouse pointer jumps.
>> Because if M-<arrow> does not move a border because it jumped to the
>> opposite border, then you have to make it clear to the user, who might
>> have thought M-<arrow> will immediately move the border instead.
> 
> The current window is highlighted by the special face of the mode-line,
> so there is no need in additional highlighting.  However, there is no
> special indication of the current window border in Emacs, but I think
> mouse movements is not an adequate replacement for the missing window
> border highlighting.  Instead of inventing special indications for the
> selected window border, it would be better to use one set of keys
> (e.g. arrows) to resize the right/bottom window border, and another set of
> keys (e.g. M-arrows or S-arrows) to resize the opposite left/top window
> border (while using M-arrows or S-arrows to switch windows).
> 
> This will help avoiding unnatural indications in winsize.el, 

Thanks for your suggestion and comments, it is difficult to find a 
solution that does everything you want in this case.

Your suggestion to instead S-arrows is of course very simple to 
implement in the current version of winsize.el, maybe as an alternative. 
If we want that I would suggest using S-arrows, since shift can be seen 
as a mnemonic for "upper" (and maybe also since I think a shift to the 
left might be good).

After thinking about this for some minutes I am still not sure what I 
think about it. One drawback is that it is more to remember and that is 
not good for something you do rather seldom.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> Your suggestion to instead S-arrows is of course very simple to implement
> in the current version of winsize.el, maybe as an alternative. If we want
> that I would suggest using S-arrows, since shift can be seen as a mnemonic
> for "upper" (and maybe also since I think a shift to the left might be
> good).

This is a good mnemonic, but then we should use M-arrows for windmove
instead of its default S-arrows.

> After thinking about this for some minutes I am still not sure what
> I think about it. One drawback is that it is more to remember and that is
> not good for something you do rather seldom.

The need to decide between resizing two opposite borders arises very
rarely, only when there is more then two windows in a row (either
horizontally or vertically).  And even for users who forget keys
for resizing the top/left border it is easy to switch to the upper/left
window with M-arrows, resize its bottom/right border with simple arrow
keys (which is the same as the top/left border of the original window),
and switch back to the original window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[martin rudalics]

> This is a good mnemonic, but then we should use M-arrows for windmove
> instead of its default S-arrows.

I'm using M-S-arrows for a couple of years now (since shifted
arrows do marking).

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

martin rudalics <rudalics@gmx.at> writes:

>> This is a good mnemonic, but then we should use M-arrows for windmove
>> instead of its default S-arrows.
>
> I'm using M-S-arrows for a couple of years now (since shifted
> arrows do marking).

This M-S-arrows are now the default for selecting adjacent windows with
windmove in windresize.  I also find it more useful.

The modifiers are now customizable and can be either a symbol (like
`shift') or a list of symbols (like '(meta shift)).

See `windresize-modifiers' docstring for details.

  http://www.cognition.ens.fr/~guerry/u/windresize.el

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

> Instead of inventing special indications for the selected window
> border, it would be better to use one set of keys (e.g. arrows) to
> resize the right/bottom window border, and another set of keys
> (e.g. M-arrows or S-arrows) to resize the opposite left/top window
> border (while using M-arrows or S-arrows to switch windows).

This is in window-resize.el 0.3:

http://www.cognition.ens.fr/~guerry/u/window-resize.el

> This will help avoiding unnatural indications in winsize.el, and will
> be better than using an inconvenient key scheme in window-resize.el
> where the same set of arrows (either arrows or M-arrows) is used for
> resizing opposite borders.

Yes.  Now moving borders and moving opposite borders are completely
separeted.  And you can select the modifier key for selecting window,
moving opposite borders, temporarily negate the increment.  See the
`window-resize-modifiers' variable.

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> window-resize.el 0.3:
> http://www.cognition.ens.fr/~guerry/u/window-resize.el

I'm sorry to see that much of what you had improved at one point is now
lost.

Window resizing is no longer the default. The prompt doesn't say anything
about the possibilities. There is (almost) no feedback during window
resizing. Shrinking a window can make it disappear. C-g doesn't quit ("Key
`^G' not bound"). With pop-up-frames non-nil, at least, `q' in *Help* quits
resizing, not *Help* (a second `q' then quits help), and it deletes one of
the windows of the initial config. And so on.

Too bad. You appear to have "improved" it to the point of regress. ;-)

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>> window-resize.el 0.3:
>> http://www.cognition.ens.fr/~guerry/u/window-resize.el
>
> I'm sorry to see that much of what you had improved at one point is now
> lost.

No problem.  

And it is not entirely lost for everyone, it's still here:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

> Window resizing is no longer the default. 

Unless lots of people complain about this, I think it's ok to make the
move-borders method the default.  If the user just wants to shrink or
enlarge the window, she might just use the already available keys.

> The prompt doesn't say anything about the possibilities.

This is because we're not in a loop anymore.  Any suggestion on making
the prompt persistent while in a major mode?

> There is (almost) no feedback during window resizing.

"Less is better."  There is feedback when no move is possible.  What
feedback are you really missing?

> Shrinking a window can make it disappear. 

I somehow tend to think this is an issue with `shrink-window' itself.
It doesn't quite respect `window-min-height'.

> C-g doesn't quit ("Key `^G' not bound").

Right, fixed.

> With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
> not *Help* (a second `q' then quits help), and it deletes one of the
> windows of the initial config. And so on.

I think this is an issue with `overriding-terminal-local-map'.  I might
find a workaround later.

> Too bad. You appear to have "improved" it to the point of regress. ;-)

No.  I think windresize.el (was window-resize.el) fits more its goal.  I
will give it a rest for a while, and see what people think.

Thanks for the feedbakc!

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> >> window-resize.el 0.3:
> >> http://www.cognition.ens.fr/~guerry/u/window-resize.el
> >
> > I'm sorry to see that much of what you had improved at one point is now
> > lost.
>
> No problem.
>
> And it is not entirely lost for everyone, it's still here:
>
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el

OK, not lost but abandoned. It's there if someone wants to pick it up and
work with it.

> > Window resizing is no longer the default.
>
> Unless lots of people complain about this, I think it's ok to make the
> move-borders method the default.  If the user just wants to shrink or
> enlarge the window, she might just use the already available keys.

If there is an argument for bundling all of this (0 1 2 3, resize,
border-move, and all the rest) together in one command (key), and I think
there is, then that argument applies equally to window resizing and border
movement. With such a bundle, it makes sense for the default behavior to be
the behavior that is most common (80%) rather than least common.

You may disagree about the common use case (though you agreed before). I
don't use Emacs windows much, but I did for decades. I cannot imagine that
someone would typically be interested in border movement and not simply
resizing. My guess is that the reasons you and Lennart concentrate on border
movement are (1) that it has been more fun (more of a challenge)
implementing and (2) it is more general.

Neither of those is a good reason to make it the default. It should be the
default only if it is a more common task.

> > The prompt doesn't say anything about the possibilities.
>
> This is because we're not in a loop anymore.  Any suggestion on making
> the prompt persistent while in a major mode?

It doesn't need to be repeated. It is the initial prompt that lets you know
that there are many possibilities, that this is a command that lets you
perform various operations on windows. Either the prompt should be somewhat
general or there should be none (or perhaps just "`?' for help"). This is
akin to Dired and Buffer Edit, which have no such prompt. Currently, the
prompt tells you only about border movement (and `?').

> > There is (almost) no feedback during window resizing.
>
> "Less is better."  There is feedback when no move is possible.  What
> feedback are you really missing?

Window resizing. I'm talking about window resizing, not border movement. The
feedback telling you that the window cannot be resized is now missing (but I
did see it pop up in one such situation, however, so I said "almost").

You've concentrated so much on border movement, perhaps to match Lennart's
bells and whistles, that you've lost sight of the common use case - simple
resizing.

> > Shrinking a window can make it disappear.
>
> I somehow tend to think this is an issue with `shrink-window' itself.
> It doesn't quite respect `window-min-height'.

That's not an argument. If `shrink-window' doesn't do what you need by
itself, then compensate in the code. This was working 100% well before, BTW:
you had previously corrected this bug; this is a regression. It seems to
work in the horizontal direction, BTW; I think it is only vertical resizing
that is broken.

> > C-g doesn't quit ("Key `^G' not bound").
>
> Right, fixed.

Thx, one should always respect C-g.

> > With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
> > not *Help* (a second `q' then quits help), and it deletes one of the
> > windows of the initial config. And so on.
>
> I think this is an issue with `overriding-terminal-local-map'.  I might
> find a workaround later.

Again, this was fixed and working before - regression.

> > Too bad. You appear to have "improved" it to the point of regress. ;-)
>
> No.  I think windresize.el (was window-resize.el) fits more its goal.  I
> will give it a rest for a while, and see what people think.

If the goal is to let people manipulate windows in various ways: their
number, size, and relative positions (including borders), then I disagree.
It was better before. In terms of implementation, it might be better to use
a keymap and mode than a read-event loop, but it is only better if the
behavior is at least as good. The latest changes sacrifice the user
experience (so far).

I've been testing this and Lennart's, even though I hardly ever resize,
split etc. Emacs windows (I use frames) anymore. I too will give it a rest,
as my input seems to be less effective now.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Unless lots of people complain about this, I think it's ok to make the
>> move-borders method the default.  If the user just wants to shrink or
>> enlarge the window, she might just use the already available keys.
>
> You may disagree about the common use case (though you agreed before). I
> don't use Emacs windows much, but I did for decades. I cannot imagine that
> someone would typically be interested in border movement and not simply
> resizing. My guess is that the reasons you and Lennart concentrate on border
> movement are (1) that it has been more fun (more of a challenge)
> implementing and (2) it is more general.

Yes, you may be right.  As you pointed out, I have no steady opinion on
what should be the default.  Let's wait and see what other people think.

>> Any suggestion on making the prompt persistent while in a major mode?
>
> It doesn't need to be repeated. It is the initial prompt that lets you know
> that there are many possibilities, that this is a command that lets you
> perform various operations on windows. Either the prompt should be somewhat
> general or there should be none (or perhaps just "`?' for help"). This is
> akin to Dired and Buffer Edit, which have no such prompt. Currently, the
> prompt tells you only about border movement (and `?').

The initial prompt is:

  "Use the arrow keys to resize windows (`?' for more)"

I think it is general.  Suggestion?

>> "Less is better."  There is feedback when no move is possible.  What
>> feedback are you really missing?
>
> Window resizing. I'm talking about window resizing, not border movement. The
> feedback telling you that the window cannot be resized is now missing (but I
> did see it pop up in one such situation, however, so I said "almost").
>
> You've concentrated so much on border movement, perhaps to match Lennart's
> bells and whistles, that you've lost sight of the common use case - simple
> resizing.

I added more feedback for normal resizing.

>> > With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
>> > not *Help* (a second `q' then quits help), and it deletes one of the
>> > windows of the initial config. And so on.
>>
>> I think this is an issue with `overriding-terminal-local-map'.  I might
>> find a workaround later.
>
> Again, this was fixed and working before - regression.

I used the same workaround, namely disabling windresize-mode if
pop-up-frames is `t' and the user wants to display the help.

> If the goal is to let people manipulate windows in various ways: their
> number, size, and relative positions (including borders), then I
> disagree.  It was better before. In terms of implementation, it might
> be better to use a keymap and mode than a read-event loop, but it is
> only better if the behavior is at least as good. The latest changes
> sacrifice the user experience (so far).

Yes.  Please consider that switching from the loop to the mode was quite
an amount of work; i couldn't implement all features from window-edit.el
at the same time and didn't want to spent time on features that I wasn't
sure people would need.

If your patience can suffer this, let me know about windresize.el 0.4 :)

> I've been testing this and Lennart's, even though I hardly ever
> resize, split etc. Emacs windows (I use frames) anymore. I too will
> give it a rest, as my input seems to be less effective now.

Thanks again for the feedback!  I guess it's more rewarding for me (or
Lennart) to try to fiddle with the code than for you to comment in the
hope that all your comments will be useful... 

'doing my best, though.

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> >> Any suggestion on making the prompt persistent while in a major mode?
> >
> > It doesn't need to be repeated. It is the initial prompt that
> > lets you know that there are many possibilities, that this is
> > a command that lets you perform various operations on windows.
> > Either the prompt should be somewhat general or there should
> > be none (or perhaps just "`?' for help"). This is akin to
> > Dired and Buffer Edit, which have no such prompt. Currently,
> > the prompt tells you only about border movement (and `?').
>
> The initial prompt is: "Use the arrow keys to resize windows
> (`?' for more)"  I think it is general.  Suggestion?

I offered a suggestion many moon ago:

>> 9. The prompt is still not general enough, IMO. Consider moving
>> the feedback regarding (1) the current mode (resize vs
>> border-movement) and (2) error messages to the mode line as a
>> temporary display. The prompt can include
>> "[023=+-~srq? (S-)arrows]" as a reminder. I know you are most
>> interested in border movement, but that is the least likely
>> thing users will use this for, IMO - the prompt should
>> emphasize 0, 2, 3, and = as much as the arrows, and
>> it should definitely mention `q' and `?'.

That would now be something like "[0123sr +-~=?], arrows, RET/q". You want
to let users know that there are several things they can do with this.

The command is not only (or even primarily?) about window resizing. To me,
it is about editing window configs: splitting, deleting, resizing, saving,
restoring. The command name would preferably indicate that. Likewise, the
prompt. If you need a single verb for what it does, it is "configure" - it
configures windows. An alternative is "edit". Resizing is only one of
several ways you can configure the windows.

> >> "Less is better."  There is feedback when no move is possible.  What
> >> feedback are you really missing?
> >
> > The feedback telling you that the window cannot be resized is now
> > missing (but I did see it pop up in one such situation, however,
> > so I said "almost").
>
> I added more feedback for normal resizing.

Thanks. But it is still missing for resizing with `down' when a window is
the full frame height - no feedback.

> >> > With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
> >> > not *Help* (a second `q' then quits help), and it deletes one of the
> >> > windows of the initial config. And so on.
> >>
> >> I think this is an issue with `overriding-terminal-local-map'.  I might
> >> find a workaround later.
> >
> > Again, this was fixed and working before - regression.
>
> I used the same workaround, namely disabling windresize-mode if
> pop-up-frames is `t' and the user wants to display the help.

In version 0.4, `q' in *Help* still exits the modal command, not *Help*. And
because `q' now restores the last saved or the original config, this can
blow away multiple windows that you added etc.

> > If the goal is to let people manipulate windows in various ways: their
> > number, size, and relative positions (including borders), then I
> > disagree.  It was better before. In terms of implementation, it might
> > be better to use a keymap and mode than a read-event loop, but it is
> > only better if the behavior is at least as good. The latest changes
> > sacrifice the user experience (so far).
>
> Yes.  Please consider that switching from the loop to the mode was quite
> an amount of work; i couldn't implement all features from window-edit.el
> at the same time and didn't want to spent time on features that I wasn't
> sure people would need.

I understand that it is a lot of work, and we all appreciate your efforts
and responsiveness. I can only comment on what I see, however, in hopes that
it helps.

> If your patience can suffer this, let me know about windresize.el 0.4 :)

See above. Also:

1. Consider letting the last mode (resizing or moving border) be the default
mode for the next time (i.e. save it for the user). Whatever you use most is
then available most easily (and the design choice of the default mode
becomes less important).

2. `?' says that M-<arrow> does this: "move opposite border inwards". I
don't see that at all. To me, M-<arrow> reverses the direction of border
movement; it does not move a different border. Also, both "opposite border"
and "inwards" are unclear here.

3. C-<arrow> does nothing at all when I use it. `?' says that it negates the
increment. Depending on what you mean by "negate the increment", C-<arrow>
would seem to be a bad choice for that (negating is just negating - why
several different arrows for that?).

4. `?' - missing the final `n': "restore window configuratio". Also, "in"
the arrow direction, not "into".

5. Consider adding some kind of visual indication of what is being acted
upon - perhaps something similar to what Lennart does. Currently, the way I
can tell that the command is still active is that the window buffers are
made read-only (but if they were already so, then this wouldn't help).

> > I've been testing this and Lennart's, even though I hardly ever
> > resize, split etc. Emacs windows (I use frames) anymore. I too will
> > give it a rest, as my input seems to be less effective now.
>
> Thanks again for the feedback!  I guess it's more rewarding for me (or
> Lennart) to try to fiddle with the code than for you to comment in the
> hope that all your comments will be useful...
>
> 'doing my best, though.

I'm sure it's appreciated, and the result (yours, Lennart's, both, or a
merger) will be useful for Emacs users. Thx.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Hi Drew,

I switched back to the loop.  The feedback looks more accurate.  The
only problem is about numeric prefixes, but I hope I can handle this
later.

I see your point about "editing" windows instead of simply resizing
them.  What about windconfig.el?  BTW, "winsize.el" sounds a bit like
...spam to me (no offense.)  Why not "enlarge.el"?

As for the prompt, "[023=+-~srq? (S-)arrows]" looks unclear to me.  
I will work on this once I solve the problem with the numeric prefixes
and I'm sure that the functionality won't move.

Whether you want C-<arrows> or not is controled by the user variable
`windresize-modifiers'.  We might find better defaults later.

For "opposite borders" and "inwards", I will get rid of unclarity when
the functionality are more steady.  And I'll handle the problem with the
help window when I know what I put in this window.

Again, thanks for the feedback!

-- 
Bastien

RE: New keybinding suggestion: C-x _ for `shrink-window'

[Drew Adams]

> I switched back to the loop.  The feedback looks more accurate.  The
> only problem is about numeric prefixes, but I hope I can handle this
> later.

Hmm. I thought that folks had determined that the non-loop was cleaner. Why
the need for a loop? Isn't specific feedback possible otherwise?

> I see your point about "editing" windows instead of simply resizing
> them.  What about windconfig.el?  BTW, "winsize.el" sounds a bit like
> ...spam to me (no offense.)  Why not "enlarge.el"?

No offense received - I didn't propose winsize.el or any other file name.
Any name you like is OK. It's the command name, doc, help, prompt etc. that
are most important wrt signaling what this does. IMO, this is about window
configuration (or editing), and resizing is only one such editing tool.

> As for the prompt, "[023=+-~srq? (S-)arrows]" looks unclear to me.

Maybe. It certainly doesn't explain anything, but it can serve as an
invitation to the doc and as a reminder. As I said previously, just a bare
"`?' for help" is sufficient. It's important to at least suggest that there
is more possible than just resizing - or, rather, at least not to suggest
that you are expecting (only) input for resizing.

> I will work on this once I solve the problem with the numeric prefixes
> and I'm sure that the functionality won't move.

FWIW, I don't agree with RMS that anyone would ever use an increment greater
than 9 lines. In fact, I don't think the C-N setting of the increment is
important at all. A single-line increment is sufficient for everything
(plenty fast), and if it were not, then it would be enough to offer just two
increments: 1 line and, say, 4 lines.

> Whether you want C-<arrows> or not is controled by the user variable
> `windresize-modifiers'.  We might find better defaults later.

I never saw that C-arrow did anything at all, IIRC.

> For "opposite borders" and "inwards", I will get rid of unclarity when
> the functionality are more steady.  And I'll handle the problem with the
> help window when I know what I put in this window.
>
> Again, thanks for the feedback!

Good luck. Thanks for working on this.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> Too bad. You appear to have "improved" it to the point of regress. ;-)

I see regress too.  I think the up key should move the only movable
horizontal border up, and the down key should move the only movable
horizontal border down; the left key should move the only movable
vertical border left, and the right key should move the only movable
vertical border right.  When there are two movable borders then I think
up/down keys should move the bottom border up/down, and left/right keys
should move the right border left/right, and M-up/down keys should move
the top border up/down, and M-left/right keys should move the left
border left/right.  Isn't this the most natural behavior?

Since mindmove have the Shift modifier by default, windresize should use
the same modifier.  When the user modifies the mindmove modifier, it would
be good if windresize used the same mindmove modifier as customized by
the user.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juri Linkov wrote:
> Since mindmove have the Shift modifier by default, windresize should use
> the same modifier.

That is a very bad default choice for windmove, since it interferes with 
the normal use of shift-arrowkeys in cua-mode. I think very many users 
use cua-mode.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

>> Since mindmove have the Shift modifier by default, windresize should use
>> the same modifier.
>
> That is a very bad default choice for windmove, since it interferes with
> the normal use of shift-arrowkeys in cua-mode. I think very many users use
> cua-mode.

Then let's change the default modifier in windmove, and use the same new
modifier for switching windows during window resizing.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>>> Since mindmove have the Shift modifier by default, windresize should use
>>> the same modifier.
>> That is a very bad default choice for windmove, since it interferes with
>> the normal use of shift-arrowkeys in cua-mode. I think very many users use
>> cua-mode.
> 
> Then let's change the default modifier in windmove, and use the same new
> modifier for switching windows during window resizing.

Agree. (Actually winsize.el already checks the bindings used for 
windmove.el.)

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>> Since mindmove have the Shift modifier by default, windresize should use
>>> the same modifier.
>>
>> That is a very bad default choice for windmove, since it interferes with
>> the normal use of shift-arrowkeys in cua-mode. I think very many users use
>> cua-mode.
>
> Then let's change the default modifier in windmove, and use the same new
> modifier for switching windows during window resizing.

FWIW I don't use cua-mode but I also think M-S-<arrows> is a more
sensible choice for windmove default keybindings.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>> Too bad. You appear to have "improved" it to the point of regress. ;-)
>
> I see regress too.  I think the up key should move the only movable
> horizontal border up, and the down key should move the only movable
> horizontal border down; the left key should move the only movable
> vertical border left, and the right key should move the only movable
> vertical border right.  

This is precisely what I tried to do at first.  

I should better have used this very clear notion of "movable border",
but continuing the outwards move of a border with the inwards move of
the opposite border (when the first border cannot move further) boils
down to the same.

I removed this "continuous" moving in 0.3 because you said:

> it would be better to use one set of keys (e.g. arrows) to resize the
> right/bottom window border, and another set of keys (e.g. M-arrows or
> S-arrows) to resize the opposite left/top window border (while using
> M-arrows or S-arrows to switch windows).

... making me think it might be better to separate border moves and
opposite borders moves.

Anyway, 0.4 now implements what you proposed.

> When there are two movable borders then I think up/down keys should
> move the bottom border up/down, and left/right keys should move the
> right border left/right, and M-up/down keys should move the top border
> up/down, and M-left/right keys should move the left border left/right.
> Isn't this the most natural behavior?

This is now the default behavior in windresize.el 0.4:

  http://www.cognition.ens.fr/~guerry/u/windresize.el

> Since mindmove have the Shift modifier by default, windresize should use
> the same modifier.  When the user modifies the mindmove modifier, it would
> be good if windresize used the same mindmove modifier as customized by
> the user.

Let's use M-S-<arrows> for now, since windmove keys will maybe change.

I will let the dust settle a bit now.  Thanks for the clear idea of
movable border.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> Anyway, 0.4 now implements what you proposed.

Thank you, it now works as I expected.  When others will propose different
schemes, you could add more options, and later could take a poll what
scheme to use as default.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>> Anyway, 0.4 now implements what you proposed.
>
> Thank you, it now works as I expected.  

Pleased to hear this.

> When others will propose different schemes, you could add more
> options, and later could take a poll what scheme to use as default.

All right.  Thanks again for the very clear suggestion.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Bastien wrote:
> Juri Linkov <juri@jurta.org> writes:
> 
>>> Anyway, 0.4 now implements what you proposed.
>> Thank you, it now works as I expected.  
> 
> Pleased to hear this.
> 
>> When others will propose different schemes, you could add more
>> options, and later could take a poll what scheme to use as default.
> 
> All right.  Thanks again for the very clear suggestion.

I agree. I just added this as juris-way and made it the default:

  http://ourcomments.org/Emacs/DL/elisp/winsize.el

Now the things to settle is how help and feedback should work. (I think
I fixed the problem with help when using popup frames.)

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

>>>> Anyway, 0.4 now implements what you proposed.
>>> Thank you, it now works as I expected.
>>
>> Pleased to hear this.
>>
>>> When others will propose different schemes, you could add more
>>> options, and later could take a poll what scheme to use as default.
>>
>> All right.  Thanks again for the very clear suggestion.
>
> I agree. I just added this as juris-way and made it the default:

Hmm, this name doesn't say anything about the behavior of this option :-)
You could use e.g. the symbol `move-borders' to denote the behavior
I proposed, and the symbol `select-borders' for your original behavior,
while using these choices in a customizable variable `...-default-method'
like is implemented by Bastien in windresize-default-method.
So for the final implementation we will have at least three methods:
`move-borders', `select-borders' and `resize-window'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>>>> Anyway, 0.4 now implements what you proposed.
>>>> Thank you, it now works as I expected.
>>>
>>> Pleased to hear this.
>>>
>>>> When others will propose different schemes, you could add more
>>>> options, and later could take a poll what scheme to use as default.
>>>
>>> All right.  Thanks again for the very clear suggestion.
>>
>> I agree. I just added this as juris-way and made it the default:
>
> Hmm, this name doesn't say anything about the behavior of this option
> :-)

We should call this Juridiction! :-)  

> You could use e.g. the symbol `move-borders' to denote the behavior
> I proposed, and the symbol `select-borders' for your original behavior,
> while using these choices in a customizable variable `...-default-method'
> like is implemented by Bastien in windresize-default-method.

I windresize-default-method was not very descriptive neither.  It's now
windresize-move-borders and boolean (since I only support two modes for
now.)

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Richard Stallman wrote:
> Lennart Borgman has been working on a similar package, now called
> winsize.el, which is implemented using the ordinary command reader
> with a special keymap.  That's the basic difference between these two
> packages.
> 
> If it is now clear that using the ordinary command reader is the best
> approach, we may as well go with winsize.el.


For those interested in testing or taking a look there is a new version 
here:

   http://ourcomments.org/Emacs/DL/elisp/winsize.el

Small improvements in help handling and in the doc string for 
resize-windows (which now explains the model for selecting and moving 
borders with userfeedback graphically).

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

> Lennart Borgman has been working on a similar package, now called
> winsize.el, which is implemented using the ordinary command reader
> with a special keymap.  That's the basic difference between these two
> packages.

Lennart's version has one drawback: it includes too much unnecessary
and distracting features like excessive coloring and mouse pointer jumping.

I don't care who will implement the final version that goes to Emacs
but I think we should have a simple package that just does its primary
job without all the bells and whistles.

> If it is now clear that using the ordinary command reader is the best
> approach, we may as well go with winsize.el.

Neither allows using keys normally bound to window manipulation commands
(`other-window', `split-window', `windmove-...') in window-resizing mode.
I think it would be preferable to make it a global mode (with an
indication string in the mode-line) and redefining a few keybindings for
doing its job.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Juri Linkov wrote:
> Lennart's version has one drawback: it includes too much unnecessary
> and distracting features like excessive coloring and mouse pointer jumping.

They are optional. It is a hard question to decide what feedback is 
needed. If you want to comment on this you are very welcome. (Maybe read 
the doc for resize-windows, it tries in the example to explain what is 
going on. But of course it should be intuitive.)

One might for example argue that the colors should not be that 
disturbing. My reply would be that it perhaps does not matter that much 
since those colors are only used shortly during windows resizing. And 
that it is quite good to get a feeling (through the visual feedback) 
that the Emacs for a short moment does something different then normally.

Or that the (short) mouse pointer jumping is disturbing. It may be 
helpful for the beginner I would say. He/she might not notice otherwise 
and perhaps even have to read the documentation. Turn the jumping off if 
you do not like it.

But there are probably better arguments from your side.


> Neither allows using keys normally bound to window manipulation commands
> (`other-window', `split-window', `windmove-...') in window-resizing mode.

I preferred to leave those bindings out, but the user can easily add 
them by customizing winsize-let-me-use.


> I think it would be preferable to make it a global mode (with an
> indication string in the mode-line) and redefining a few keybindings for
> doing its job.

Hm. I started with a global minor mode (or really from the beginning 
with a loop while testing). I have not much against that (if you put it 
in emulation-mode-map-alist). The key bindings should be rather similar 
though.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> Hm. I started with a global minor mode (or really from the beginning with
> a loop while testing). I have not much against that (if you put it in
> emulation-mode-map-alist). The key bindings should be rather similar though.

I think the most sensible choice is to use the same approach as used by
isearch (i.e. overriding-terminal-local-map).


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> Hm. I started with a global minor mode (or really from the beginning with
>> a loop while testing). I have not much against that (if you put it in
>> emulation-mode-map-alist). The key bindings should be rather similar though.
> 
> I think the most sensible choice is to use the same approach as used by
> isearch (i.e. overriding-terminal-local-map).


That is what is used currently in winsize.el.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Juri Linkov]

>> Hm. I started with a global minor mode (or really from the beginning with
>> a loop while testing). I have not much against that (if you put it in
>> emulation-mode-map-alist). The key bindings should be rather similar though.
>
> I think the most sensible choice is to use the same approach as used by
> isearch (i.e. overriding-terminal-local-map).

If using the same approach as used by isearch then it makes sense also
to add a feature like isearch-allow-scroll that after setting a property
like isearch-scroll on a command's symbol (e.g. `other-window') will accept
this command without exiting during window resizing.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>> Hm. I started with a global minor mode (or really from the beginning with
>>> a loop while testing). I have not much against that (if you put it in
>>> emulation-mode-map-alist). The key bindings should be rather similar though.
>>
>> I think the most sensible choice is to use the same approach as used by
>> isearch (i.e. overriding-terminal-local-map).
>
> If using the same approach as used by isearch then it makes sense also
> to add a feature like isearch-allow-scroll that after setting a property
> like isearch-scroll on a command's symbol (e.g. `other-window') will accept
> this command without exiting during window resizing.

Maybe I'm a bit dim on this, but I don't really get the point about
using `overriding-terminal-local-map'.

Stefan proposed this when Lennart replied to Juri's suggestion to
implement winsize.el (bw-interative.el at that time) as a major mode.
Can `overriding-terminal-local-map' be useful in the context of a major
mode?  of a minor mode?  of a loop waiting for an event?

For now I don't see any good reasons to implement window-resize.el as a
minor mode or to use `overriding-terminal-local-map'.  I guess I miss
something here.

Can anyone shed some light?

Thanks,

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> Maybe I'm a bit dim on this, but I don't really get the point about
> using `overriding-terminal-local-map'.

> Stefan proposed this when Lennart replied to Juri's suggestion to
> implement winsize.el (bw-interative.el at that time) as a major mode.
> Can `overriding-terminal-local-map' be useful in the context of a major
> mode?  of a minor mode?  of a loop waiting for an event?

> For now I don't see any good reasons to implement window-resize.el as a
> minor mode or to use `overriding-terminal-local-map'.  I guess I miss
> something here.

I'm not sure what method you use instead, but I see two choices:

- use a keymap with high priority.
- use `read-event' in a loop.

If using the first, then overriding-terminal-local-map is about as high
priority as it gets.  And it's terminal-specific so you should be able
to use it independently, from two terminals at the same time (assuming
the rest of the code is careful not to abuse global vars when
terminal-parameters should be used instead).

If using the second, you lose most of the benefits of the top-level
loop: you don't call pre/post-command-hook, you may prevent filters from
running, you have to be careful with input-decode-map, function-key-map,
etc...

Note that using overriding-terminal-local-map is not necessarily a piece
of cake either.  Actually I think it would be good to extract the
relevant part of isearch and make it isearch-independent so it can be
reused by other packages.


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm not sure what method you use instead, but I see two choices:
>
> - use a keymap with high priority.

This is what I currently use, with a simple (use-local-map ...) in the
definition of `window-resize-mode'.

> - use `read-event' in a loop.

This what I used in window-edit -- but this is history now.

> If using the first, then overriding-terminal-local-map is about as high
> priority as it gets.  And it's terminal-specific so you should be able
> to use it independently, from two terminals at the same time (assuming
> the rest of the code is careful not to abuse global vars when
> terminal-parameters should be used instead).

Ok, thanks for the explanations.  

> If using the second, you lose most of the benefits of the top-level
> loop: you don't call pre/post-command-hook, you may prevent filters from
> running, you have to be careful with input-decode-map, function-key-map,
> etc...

Which are some of the reasons why I switched back to the other solution.

> Note that using overriding-terminal-local-map is not necessarily a
> piece of cake either.

I gave overriding-terminal-local-map a try. 

The problem is that when `window-resize-mode' sends an error, the point
goes in the minibuffer and the active keymap is still the one defined by
`overriding-terminal-local-map'.  This is rather confusing since
window-resize-mode-map redefines the arrow keys and that these keys
might be useful in the minibuffer.  I don't know how to avoid this.

Another question about keymaps in general: in window-resize-mode the
buffer is read-only and I'd like to prevent errors to be thrown when the
user hits a key that should insert itself in another mode.  

So I tried to substitute 'self-insert-command with a variant of my own,
with 'self-insert-command in (ignore-errors ...) or (condition-case...).
But it seems then that those keys which are bound to a command -- other
than 'self-insert-command -- are not working anymore.  

Do you have an idea?

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

>> I'm not sure what method you use instead, but I see two choices:
>> - use a keymap with high priority.

> This is what I currently use, with a simple (use-local-map ...) in the
> definition of `window-resize-mode'.

That's the second lowest priority :-(

> The problem is that when `window-resize-mode' sends an error, the point
> goes in the minibuffer and the active keymap is still the one defined by
> `overriding-terminal-local-map'.  This is rather confusing since
> window-resize-mode-map redefines the arrow keys and that these keys
> might be useful in the minibuffer.  I don't know how to avoid this.

I'm not sure I understand the problem (i.e. in which way is this
different with use-local-map).  Maybe all you're missing is
`unwind-protect'?

> Another question about keymaps in general: in window-resize-mode the
> buffer is read-only and I'd like to prevent errors to be thrown when the
> user hits a key that should insert itself in another mode.

isearch uses a default binding:

   (define-key map [t] 'window-resize-other-key)

check isearch-other-control-char and isearch-other-meta-char.


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I'm not sure what method you use instead, but I see two choices:
>>> - use a keymap with high priority.
>
>> This is what I currently use, with a simple (use-local-map ...) in the
>> definition of `window-resize-mode'.
>
> That's the second lowest priority :-(

Okay, I'm using `overriding-terminal-local-map' in 0.2:

  http://www.cognition.ens.fr/~guerry/u/window-resize.el

>> The problem is that when `window-resize-mode' sends an error, the point
>> goes in the minibuffer and the active keymap is still the one defined by
>> `overriding-terminal-local-map'.  This is rather confusing since
>> window-resize-mode-map redefines the arrow keys and that these keys
>> might be useful in the minibuffer.  I don't know how to avoid this.
>
> I'm not sure I understand the problem (i.e. in which way is this
> different with use-local-map).  Maybe all you're missing is
> `unwind-protect'?

AFAIK it's different because `overriding-terminal-local-map' will be
used in the minibuffer as well (whether the user is here intentionally
or by error doesn't really matter.)

I've already protected command from returning errors, but I need to
protect self-insert-command as well.

>> Another question about keymaps in general: in window-resize-mode the
>> buffer is read-only and I'd like to prevent errors to be thrown when the
>> user hits a key that should insert itself in another mode.
>
> isearch uses a default binding:
>
>    (define-key map [t] 'window-resize-other-key)
>
> check isearch-other-control-char and isearch-other-meta-char.

Thanks a lot, I will check this.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> AFAIK it's different because `overriding-terminal-local-map' will be
> used in the minibuffer as well (whether the user is here intentionally
> or by error doesn't really matter.)

Why would you let the user get into the minibuffer?


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> AFAIK it's different because `overriding-terminal-local-map' will be
>> used in the minibuffer as well (whether the user is here intentionally
>> or by error doesn't really matter.)
>
> Why would you let the user get into the minibuffer?

He wouldn't.  But hitting M-x accidently will lead to weird things.
Also, going to the help window and tring to scroll with arrow keys won't
work unless I cancel the overriding-terminal-local-map, which cannot be
buffer-local (if I understand correctly.  Please give a try to latest
window-resize.el and let me know.

As for the keybindings, I implemented what you suggested:

  (define-key map [t] 'window-resize-other-char)

BTW, I think "window-resize" is a bit long.  

What about "windresize" (which gets along great with "windmove") ?

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

>>> AFAIK it's different because `overriding-terminal-local-map' will be
>>> used in the minibuffer as well (whether the user is here intentionally
>>> or by error doesn't really matter.)
>> 
>> Why would you let the user get into the minibuffer?

> He wouldn't.  But hitting M-x accidently will lead to weird things.

So the problem is not that bindings don't work when the user gets in
the minibuffer.  The problem is "how do I prevent the user from doing M-x?".

> Also, going to the help window and tring to scroll with arrow keys won't
> work

Right, allowing that might be tricky.  An easy way out is to make sure
the help never needs to be scrolled (i.e. make the behavior sufficiently
simple and intuitive that it can be described in 1-2 lines).

> unless I cancel the overriding-terminal-local-map, which cannot be
> buffer-local

Again, take a look at how isearch handles similar issues.


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> He wouldn't.  But hitting M-x accidently will lead to weird things.
>
> So the problem is not that bindings don't work when the user gets in
> the minibuffer.  The problem is "how do I prevent the user from doing
> M-x?".

Okay, I undefined (kbd "M-x") in windresize.el.

>> Also, going to the help window and tring to scroll with arrow keys won't
>> work
>
> Right, allowing that might be tricky.  An easy way out is to make sure
> the help never needs to be scrolled (i.e. make the behavior sufficiently
> simple and intuitive that it can be described in 1-2 lines).

Tough.  The new help window doesn't display the documentation of the
mode anymore, but it's not 1-2 lines.

http://www.cognition.ens.fr/guerry/u/windresize.el

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Stefan Monnier]

> Okay, I undefined (kbd "M-x") in windresize.el.

You shouldn't need to: the [t] default binding should take care of it.


        Stefan

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Okay, I undefined (kbd "M-x") in windresize.el.
>
> You shouldn't need to: the [t] default binding should take care of it.

Yes.  

Generally, I have this dilemma: in the mode-approach, I miss the loop
and the general feedback it immediately gives; in the loop-approach, I
miss the universal-argument (since `windresize-other-char' is not clever
enough to handle them for now.)

At the end of the tunnel, there is this little light: being able to
read key sequences that understand prefixes (AFAIK read-key-sequence
doesn't) and do this in a loop.

For now (0.5) I switched back to the loop approach.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    > I think it would be preferable to make it a global mode (with an
    > indication string in the mode-line) and redefining a few keybindings for
    > doing its job.

    Hm. I started with a global minor mode (or really from the beginning 
    with a loop while testing). I have not much against that (if you put it 
    in emulation-mode-map-alist). The key bindings should be rather similar 
    though.

I don't think it should be a minor mode, because it makes
no sense to enable it and disable it arbitrarily.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    Lennart's version has one drawback: it includes too much unnecessary
    and distracting features like excessive coloring and mouse pointer jumping.

Those are minor details -- no reason to make a decision
about the basic implementation.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

I uploaded a new version:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

Richard Stallman <rms@gnu.org> writes:

>     If this command is invoked in a single-window frame, only propose
>     to split the window.  Otherwise propose to move the borders with
>     the arrow keys.
>
> I don't understand what that means.  Could you please spell it out?

I updated the docstring like this:

  By default, resizing is done by increasing/decreasing window
  width and height.  In this mode, use the up and down arrow keys
  to enlarge or shrink the window and use the right and left arrow
  keys to enlarge or shrink the window horizontally.
  
  Resizing can also be done by moving the window borders.  In this
  mode, use the arrow keys to move the corresponding border in the
  arrow direction -- e.g. the left arrow key will try to move the
  left border to the left.

  You can toggle between resize-window and move-borders with SPC.
  
  The initial window configuration is stored in a ring.  You can
  switch back to this configuration by pressing `r'.  You can add
  more window configurations to this ring by pressing `s'.
  
>       Hitting SPC will switch from this move-borders mode to the
>     resize-windows mode, where arrows keys don't point to direction
>     but rather increase or decrease the window size.
>
> I have a guess as to what that means, but I am not confident the guess
> is right.  Can you please spell it out?

We had a discussion earlier on this list about whether the arrow keys
should just increase/decrease the window width/height, or better move
the borders (with the left arrow key moving the left border to the left,
for example.)

By default, window-edit expect the arrow keys to increase/decrease the
width/height of the window.  Pressing SPC switches to the move-borders
mode.  Maybe "resize-window" and "move-borders" are not the right names
for the modes, I don't have better ones for now.

>     S-arrows:    jump to other window direction-wise
>
> What does that mean?

Hitting the right arrow key will find the right window, if any.  It
basically calls (windmove-right).

> 	 +/-:    increase/decrease line units
>
> Does that mean + and - always change the height of the window?

I changed this to:

  +/-:    increase/decrease INCREMENT

where INCREMENT is the number of line(s) for any resizing. 

I hope it's clearer.

> 	   ~:    negate argument
>
> Where would you want to use a negative argument?

  |---+---+---|
  | A | B | C |
  |---+---+---|

When the point is in window B and you're in move-borders mode, <left>
will move the left border of window B to the left, and <right> will move
its right border to the right.  But you might want to quickly move the
left border to the right.  So instead of finding window A and moving its
right border to the right, you'll negate the argument and move the left
border (which will move to the right instead of moving to the left.)

Don't know if this is *that* useful, I'll see later.

> 	(run-at-time 15 10 '(lambda () (setq msg "")))
>
> cthat is a very strange thing.  There needs to be a comment that
> thoroughly explains the use of MSG.

Removed.

> 		 ((setq arg0 (memq e '(?\^1 ?\^2 ?\^3 ?\^4 ?\^5 ?\^6 ?\^7 ?\^8 ?\^9)))
> 		  (setq arg (- 10 (length arg0))))
>
> What does that do?  There is no comment.

Added.  It "computes" the value of `N' from a keystroke like C-N.

Thanks for the feedback,

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

      By default, resizing is done by increasing/decreasing window
      width and height.  In this mode, use the up and down arrow keys
      to enlarge or shrink the window and use the right and left arrow
      keys to enlarge or shrink the window horizontally.

So in this mode you don't control which border moves.

      Resizing can also be done by moving the window borders.  In this
      mode, use the arrow keys to move the corresponding border in the
      arrow direction -- e.g. the left arrow key will try to move the
      left border to the left.

So in this mode you can only enlarge the window.

    When the point is in window B and you're in move-borders mode, <left>
    will move the left border of window B to the left, and <right> will move
    its right border to the right.  But you might want to quickly move the
    left border to the right.  So instead of finding window A and moving its
    right border to the right, you'll negate the argument and move the left
    border (which will move to the right instead of moving to the left.)

Oh, so that's how you would use the window borders mode to make this
window smaller.

It seems unnatural, and I think it will be hard to remember.

Perhaps the right thing to do is use arrow keys to select the border
to move, and use + and - to grow or shrink the window using that border.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>       By default, resizing is done by increasing/decreasing window
>       width and height.  In this mode, use the up and down arrow keys
>       to enlarge or shrink the window and use the right and left arrow
>       keys to enlarge or shrink the window horizontally.
>
> So in this mode you don't control which border moves.

Right.  `shrink-window' and `enlarge-window' decide.

>       Resizing can also be done by moving the window borders.  In this
>       mode, use the arrow keys to move the corresponding border in the
>       arrow direction -- e.g. the left arrow key will try to move the
>       left border to the left.
>
> So in this mode you can only enlarge the window.

Right.

>     When the point is in window B and you're in move-borders mode, <left>
>     will move the left border of window B to the left, and <right> will move
>     its right border to the right.  But you might want to quickly move the
>     left border to the right.  So instead of finding window A and moving its
>     right border to the right, you'll negate the argument and move the left
>     border (which will move to the right instead of moving to the left.)
>
> Oh, so that's how you would use the window borders mode to make this
> window smaller.
>
> It seems unnatural, and I think it will be hard to remember.

I first used M-<arrows> to let the user move the border inwards.

Drew suggested to use `~' to negate the value of INCREMENT and I gave it
a try.  Actually, I think using M-<arrows> to move the border inwards is
better: no need for `~' and easy to remember.

> Perhaps the right thing to do is use arrow keys to select the border
> to move, and use + and - to grow or shrink the window using that
> border.

This is similar to Lennart's approach in bw-interactive.el:

  http://ourcomments.org/Emacs/DL/elisp/bw-interactive.el

I reacted to his code by saying that the left arrow key should *both*
select the left border and move it to the left.  Hence window-edit.el,
where I prefer to keep both actions (i.e. selecting and moving) to be
performed with a single keystroke.

IMO using the Meta key to move inwards instead of outwards is simpler
than first selecting the border and then moving it.

I'll implement back M-<arrow> for inwards border moves, while keeping
`~' for a while, let's see what people prefer.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    IMO using the Meta key to move inwards instead of outwards is simpler
    than first selecting the border and then moving it.

That sounds plausible.  Let's see how people like it.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     IMO using the Meta key to move inwards instead of outwards is simpler
>     than first selecting the border and then moving it.
>
> That sounds plausible.  Let's see how people like it.

I swapped S-<arrow> and M-<arrow>.  

Now M-<arrow> select the adjacent window and S-<arrow> temporarily
negates the increment value.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    > What does that do?  There is no comment.

    Added.  It "computes" the value of `N' from a keystroke like C-N.

It should accept plain digits too, and it should understand numbers
greater than 9.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     > What does that do?  There is no comment.
>
>     Added.  It "computes" the value of `N' from a keystroke like C-N.
>
> It should accept plain digits too, and it should understand numbers
> greater than 9.

Those plain digits are already taken: 

  0 : delete-window
  1 : delete-other-windows
  2 : split-window
  3 : split-window-horizontally

These commands are likely to be used more often than C-N so I guess it's
okay like that.

BTW, I doubt numbers greaters than 9 are useful here, we're just taking
about *incremental* resizing.  Do you think people would like to resize
windows by 11 or 20 lines?
  
-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    BTW, I doubt numbers greaters than 9 are useful here, we're just taking
    about *incremental* resizing.  Do you think people would like to resize
    windows by 11 or 20 lines?

Why not?  Anyway, it is a bug not to support such arguments.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     BTW, I doubt numbers greaters than 9 are useful here, we're just taking
>     about *incremental* resizing.  Do you think people would like to resize
>     windows by 11 or 20 lines?
>
> Why not?  Anyway, it is a bug not to support such arguments.

In latest windresize.el, I'm reading the key sequence in a loop with
`read-key-sequence'.  I don't know how to handle numeric prefixes with
it, maybe I'm missing something here.  But as Stefan suggested, I will
study the isearch.el code and see how `isearch-other-meta-char' works.

Then hopefully windresize will understand numeric prefixes in the loop.

-- 
Bastien

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Sascha Wilde]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Actually, I'd prefer to deprecate those bindings (along with C-x ^) and
> replace them with a binding that allows the user to do:
>
>    M-x window-resize RET
>
> (which we'd of course bind to some key) and then
>
>    ^ ^ ^ } } } } } { { { { } } ...
> or
>    left left left up up up up up up up

I like that idea very much.

> I usually don't know how by how many lines I want to expand/shrink a window,
> so I typically end up doing
>
>    C-x ^ C-x ^ C-x ^
>
> which is *really* inconvenient. 

Just for the record (and because I tend to forget about C-x z my self):

C-x ^ C-x z z [ ... ]

Will do, too.  Which is in many more convenient if you want to do a more
complex keystroke for more than two times...

cheers
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[Richard Stallman]

    > I don't think it is worth using up a key for that.
    > You can do this now with negative args to `enlarge-window',
    > and I think that is good enough for a command tha's not used
    > all that often.

    Sorry to insist on this, but Emacs has also these two keybindings:

      C-x {  shrink-window-horizontally
      C-x }  enlarge-window-horizontally

So what?

    I find it weird to have a keybinding for `shrink-window-horizontally'
    and not for `shrink-window', which is more fundamental.

These things don't run exactly parallel.  { and } are opposites
in a way that ^ and _ are not.

However, your point is valid to the extent that we might consider
reusing C-x { and C-x } for something else, if there is an obvious
something else to use them for.

Re: New keybinding suggestion: C-x _ for `shrink-window'

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I find it weird to have a keybinding for `shrink-window-horizontally'
>     and not for `shrink-window', which is more fundamental.
>
> These things don't run exactly parallel.  { and } are opposites
> in a way that ^ and _ are not.

Well, if you are writing with TeX, they are.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum