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.