[Top][All Lists]
[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.
- New keybinding suggestion: C-x _ for `shrink-window', Bastien, 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Lennart Borgman (gmail), 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Bastien, 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Lennart Borgman (gmail), 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Bastien, 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window',
Lennart Borgman (gmail) <=
- Re: New keybinding suggestion: C-x _ for `shrink-window', Bastien, 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Lennart Borgman (gmail), 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Lennart Borgman (gmail), 2007/10/28
- Re: New keybinding suggestion: C-x _ for `shrink-window', Bastien, 2007/10/29
Re: New keybinding suggestion: C-x _ for `shrink-window', Richard Stallman, 2007/10/28