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

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:

>> 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'

[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'

[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.

My real concern was that I need `shrink-window' more often than the 
`shrink-window-if-larger-than-buffer' command (`C-x -')

Even if I don't use these two commands that often, using one more than
another made me propose this.  But from people replies, I deduce it is
just my way of resizing windows.

-- 
Bastien

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