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

[Bastien]

"Lennart Borgman (gmail)" <address@hidden> 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