help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lennart Borgman (gmail)
Subject: Re: New keybinding suggestion: C-x _ for `shrink-window'
Date: Sun, 28 Oct 2007 21:20:26 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666

Bastien wrote:
"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'

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]