emacs-devel
[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 12:21:49 +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:
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.




reply via email to

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