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

[Bastien]

"Drew Adams" <address@hidden> writes:

>> I tried to implement Drew suggestions into one single function.
>> See my comments below.  Any feedback is very welcome.
>
> Thanks for working some more on this. I didn't expect that you would
> implement most of what I suggested - they were just some ideas that occurred
> to me. Anyway, here is some more feedback to think about:

Please check the latest window-edit.el here:

  http://www.cognition.ens.fr/~guerry/u/window-edit.el

Window shrinking/enlarging is okay.  

Borders moving might be somewhat inconsistent, but I could find any easy
way to predict the changes made by `shrink-window' and `enlarge-window'
in all possible window configurations.  Anyway, this should be accurate
in 95% of the real-life cases, and I do agree that the resize-mode will
be the most useful anyway.

> 1. When I use `?', I get a new frame *window-edit help* (I use non-nil
> `pop-up-frames'). If I click mouse-1 in that frame, then the frame
> disappears. That's no good. I need to be able to go to the help frame, move
> around, select text, etc.

I'm not sure about this.  The help window is now quite big, and people
using window-edit with a lot of windows might prefer not to loose their
configuration just by displaying the help window.

Hitting `?' once will first show a small help message, depending on 
the mode you're on.  Then hitting `?' again will display the window 
help.

> 2. When help is shown, the window configuration should be left as is, if
> `pop-up-frames' is non-nil. That is, there is no need to change it to a
> single window.

Fixed.

> 3. Need more help in the help window. For instance, what do the arrows do,
> by default? What does the prefix arg do?

I tried to improve this.

> 4. Window resizing with arrows works fine. I see problems with border
> movement, however:

Most of the bugs should be fixed now.

> f. Whenever an arrow key cannot move a border for some reason, the user
> should get feedback explaining why. For instance, in a window that is
> full-frame height, you cannot move a border up or down, but there is no
> message.

Fixed.  Let me know what you think.

> g. There is still the problem that moving a border can make windows
> disappear because they get too small. To me, that's not the right behavior.
> They should respect `window-min-width' and `window-min-height' - you should
> get a "can't move..." message if the requested movement tries to undercut
> these limits.

Fixed.

> 7. The binding of `echo-keystrokes' is not working. If I move the focus to
> another window-manager window (e.g. this mail message, outside Emacs), then
> I see a long string of keystrokes filling the echo area. Maybe move the
> binding higher up?

I already set (echo-keystrokes 0) - what can I do?

> 8. +/- should go directly from 1 to -1, skipping 0, since 0 is a no-op for
> resizing and border movement.

Fixed.

> 9. The prompt is still not general enough, IMO. 

Please comment the new prompt.

> 10. Change "negate argument" to "negate increment". Change ARG everywhere to
> "INCREMENT", for clarity. And put ~ next to +/- in the help and the doc
> string, so it's clearer that they all apply to the increment.

Done.

> 11. Let the arrows resize instead of move borders, by default. 

Done.

> 12. Cursor in right window, `S-down' - no message. Instead, cursor moves to
> bottom-left window. Another `S-down' - still no message - and no more cursor
> movement.

Fixed.

> However, you might want to let `C-b', `C-f', `C-p', and `C-n' move
> point to enable control over `S-<arrow>'.

Added.

> It's simple:
>
> (case e
>   (left (if...)
>   (right (if...)
>   (up (if...)
>   (down (if...))

Done.

> `mouse-1' should set point, in whatever window.

Not yet done.  I will do this if the new window-edit.el if I have more
feedback on window-edit.el, I need to be sure this is going somewhere.

Thanks,

-- 
Bastien