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

[Drew Adams]

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

I have a window config created by `window-edit 3 2 3 2'. I start with the
cursor in the middle window at the left of the frame.

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.

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.

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

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

a.  Bug (?): Cursor in middle-left window. `down' increases the window size,
as does ` `up': both move the upper border up.

b. Bug (?): Arrows with cursor in bottom-left window affect only the
middle-left window above it (and not even the common border): `up' moves
that window's top border down; `down' moves it up. And `down' moves the
cursor (focus) to that middle window (but `up' does not).

c. Bug (?): Similarly, try to use `left' arrow on the rightmost window. That
doesn't move either of its borders; instead, it moves the left border of the
middle-top window to the right. The `right' arrow correctly moves the right
window's left border to the right. One can work around this by negating the
increment with `~' (because the problem/bug is then reversed). But the
behavior is wrong, IMO.

d. Bug (?): Increase middle-left window to its max size, so you get the
[can't move up] message. Then put cursor in middle-top window and use
`down'. That moves the cursor to the middle-left window and tries to
increase it. There is no [can't move...] message, and the arrow in that
window has no effect. What should happen is the top-left window should grow
along with the bottom border moving down. Or at least something intuitive
should happen. Or at least the user should get some feedback about what is
going wrong.

e. Bug (?): Increase middle-left window to its max size, so you get the
[can't move up] message. Then try to move the lower border `down'. Nothing
happens - no feedback, no movement. The border (common to middle-top window)
should be moved down.

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.

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.

6. In general, border-movement mode seems inconsistent - or at least it is
unclear to me what the arrows do: which border is moved which way. Please
have a look a this again.

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?

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

9. The prompt is still not general enough, IMO. Consider moving the feedback
regarding (1) the current mode (resize vs border-movement) and (2) error
messages to the mode line as a temporary display. The prompt can include
"[023=+-~srq? (S-)arrows]" as a reminder. I know you are most interested in
border movement, but that is the least likely thing users will use this for,
IMO - the prompt should emphasize 0, 2, 3, and = as much as the arrows, and
it should definitely mention `q' and `?'.

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.

11. Let the arrows resize instead of move borders, by default. Resizing is
much easier to understand and works for 80% of what someone wants to do.
Consider border movement as an "advanced" mode. It is a mistake to dump a
user directly into border-movement mode, IMO.

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.

13. Apparently, the cursor position within a window determines which window
to move to with `S-<arrow>'. That's a bonus. However, for that to be
worthwhile, you need to allow `mouse-1' to set point. Example. With cursor
in right window below midline window divider, `S-left' sends cursor to
lower-left window. With cursor above midline, it sends it to middle-top
window. That's good, but you should be able, with cursor below midline, to
click mouse-1 above midline and then do `S-left' to move to middle-top
window.

14. Yes, that is not very important, because if you can click above then you
can also click in the window you want. However, you might want to let `C-b',
`C-f', `C-p', and `C-n' move point to enable control over `S-<arrow>'. That
can be useful when there are multiple windows. For example, depending on
where the cursor is and the line length of where it is moved to by `S-down',
if you move from the middle-top window to the left-bottom window and then
back up by `S-up', you might end up in the middle-left window or the
middle-top window.

15. At the very least, this behavior needs to be explained to the user -
s?he needs to know that the cursor position wrt the window divider
determines the destination window. And s?he needs to know about the
line-length thing: if the cursor position in the frame is to the right of
the line length of the middle line in the destination window, then it will
be moved to the middle-line end, which might move it across the window
divider.

> > * Use `case' (compile-time require cl) to simplify code.
>
> I didn't use it yet.

It's simple:

(case e
  (left (if...)
  (right (if...)
  (up (if...)
  (down (if...))

(case e
  (?0 (delete-other-windows))
  (?2 ...)
  (?3 ...)
  (?o ...)
  ...
  (S-right ...)
  (S-down ...)
  ...
  ((?h ??) (let...)))

You might have to juggle a couple of pieces that aren't just constant
comparisons, but `case' will otherwise make the code more readable, IMO. (To
juggle them, you can use `case's `otherwise' clause with a `cond' of `if'.)

> Yes.  Window configurations are now stored into a ring, so pressing `r'
> twice will call back wcf2 then wcf1 if wcf1 and wcf2 were stored.  The
> first config in this ring is the initial one.

Please make this clearer in the doc string and help. It's there, but it's
not obvious.

> > * When window reaches a minimum, trying to reduce it
> >   more either moves it instead or deletes it instead.
> >   Maybe do something different (e.g. nothing?).
>
> Fixed.  Hence the ugly part of the defun.  I couldn't figure out how to
> factorize all this a bit yet.  Suggestions welcome.

See above. It still doesn't seem fixed to me.

> > * Maybe let Shift always navigate - up/down/left/right,
> >   and use something else (`+' and `-'?) to
> >   increment/decrement ARG.
>
> Right. S-<arrow> now navigates through windows direction-wise.
>
> > * And maybe let C-N (N an integer) set ARG absolutely?
>
> Done.

Please document it. The doc string and `?' help say nothing about the prefix
arg.

> > * Maybe let mouse-1 select a window also.
>
> Done.

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

> > * Maybe use mouse wheel also (if direction is known)?
>
> Not done yet.   Don't know if this is really useful.

Probably not.

> > * The prompt doesn't express much of what is possible.
> >   In particular, if `one-window-p', the prompt makes
> >   no sense (but `2' and `3' still make sense).
>
> Fixed, even though there is room for improvement.

Yes, see above. The prompt should indicate the most useful/common
keystrokes, and it should definitely indicate `q' and `?'. Other helpful
info that is now in the prompt could be moved to the mode-line (as a
temporary display).

> > * Maybe let unrecognized events (keys, at least) quit
> >   instead of being ignored. And then perhaps be
> >   applied? So, e.g., `RET' would quit (and insert a
> >   newline?).
>
> Not done.  Will work on this later.  Depends on feedback about this
> defun.

Looking good, IMO. The most important thing to take care of is the behavior
of arrows for moving borders: it's not understandable and is apparently
somewhat inconsistent (bugged).

HTH & thx.