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

["Drew Adams" <drew.adams@oracle.com>]

> >> Any suggestion on making the prompt persistent while in a major mode?
> >
> > It doesn't need to be repeated. It is the initial prompt that
> > lets you know that there are many possibilities, that this is
> > a command that lets you perform various operations on windows.
> > Either the prompt should be somewhat general or there should
> > be none (or perhaps just "`?' for help"). This is akin to
> > Dired and Buffer Edit, which have no such prompt. Currently,
> > the prompt tells you only about border movement (and `?').
>
> The initial prompt is: "Use the arrow keys to resize windows
> (`?' for more)"  I think it is general.  Suggestion?

I offered a suggestion many moon ago:

>> 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 `?'.

That would now be something like "[0123sr +-~=?], arrows, RET/q". You want
to let users know that there are several things they can do with this.

The command is not only (or even primarily?) about window resizing. To me,
it is about editing window configs: splitting, deleting, resizing, saving,
restoring. The command name would preferably indicate that. Likewise, the
prompt. If you need a single verb for what it does, it is "configure" - it
configures windows. An alternative is "edit". Resizing is only one of
several ways you can configure the windows.

> >> "Less is better."  There is feedback when no move is possible.  What
> >> feedback are you really missing?
> >
> > The feedback telling you that the window cannot be resized is now
> > missing (but I did see it pop up in one such situation, however,
> > so I said "almost").
>
> I added more feedback for normal resizing.

Thanks. But it is still missing for resizing with `down' when a window is
the full frame height - no feedback.

> >> > With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
> >> > not *Help* (a second `q' then quits help), and it deletes one of the
> >> > windows of the initial config. And so on.
> >>
> >> I think this is an issue with `overriding-terminal-local-map'.  I might
> >> find a workaround later.
> >
> > Again, this was fixed and working before - regression.
>
> I used the same workaround, namely disabling windresize-mode if
> pop-up-frames is `t' and the user wants to display the help.

In version 0.4, `q' in *Help* still exits the modal command, not *Help*. And
because `q' now restores the last saved or the original config, this can
blow away multiple windows that you added etc.

> > If the goal is to let people manipulate windows in various ways: their
> > number, size, and relative positions (including borders), then I
> > disagree.  It was better before. In terms of implementation, it might
> > be better to use a keymap and mode than a read-event loop, but it is
> > only better if the behavior is at least as good. The latest changes
> > sacrifice the user experience (so far).
>
> Yes.  Please consider that switching from the loop to the mode was quite
> an amount of work; i couldn't implement all features from window-edit.el
> at the same time and didn't want to spent time on features that I wasn't
> sure people would need.

I understand that it is a lot of work, and we all appreciate your efforts
and responsiveness. I can only comment on what I see, however, in hopes that
it helps.

> If your patience can suffer this, let me know about windresize.el 0.4 :)

See above. Also:

1. Consider letting the last mode (resizing or moving border) be the default
mode for the next time (i.e. save it for the user). Whatever you use most is
then available most easily (and the design choice of the default mode
becomes less important).

2. `?' says that M-<arrow> does this: "move opposite border inwards". I
don't see that at all. To me, M-<arrow> reverses the direction of border
movement; it does not move a different border. Also, both "opposite border"
and "inwards" are unclear here.

3. C-<arrow> does nothing at all when I use it. `?' says that it negates the
increment. Depending on what you mean by "negate the increment", C-<arrow>
would seem to be a bad choice for that (negating is just negating - why
several different arrows for that?).

4. `?' - missing the final `n': "restore window configuratio". Also, "in"
the arrow direction, not "into".

5. Consider adding some kind of visual indication of what is being acted
upon - perhaps something similar to what Lennart does. Currently, the way I
can tell that the command is still active is that the window buffers are
made read-only (but if they were already so, then this wouldn't help).

> > I've been testing this and Lennart's, even though I hardly ever
> > resize, split etc. Emacs windows (I use frames) anymore. I too will
> > give it a rest, as my input seems to be less effective now.
>
> Thanks again for the feedback!  I guess it's more rewarding for me (or
> Lennart) to try to fiddle with the code than for you to comment in the
> hope that all your comments will be useful...
>
> 'doing my best, though.

I'm sure it's appreciated, and the result (yours, Lennart's, both, or a
merger) will be useful for Emacs users. Thx.