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

[Drew Adams]

> >> window-resize.el 0.3:
> >> http://www.cognition.ens.fr/~guerry/u/window-resize.el
> >
> > I'm sorry to see that much of what you had improved at one point is now
> > lost.
>
> No problem.
>
> And it is not entirely lost for everyone, it's still here:
>
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el

OK, not lost but abandoned. It's there if someone wants to pick it up and
work with it.

> > Window resizing is no longer the default.
>
> Unless lots of people complain about this, I think it's ok to make the
> move-borders method the default.  If the user just wants to shrink or
> enlarge the window, she might just use the already available keys.

If there is an argument for bundling all of this (0 1 2 3, resize,
border-move, and all the rest) together in one command (key), and I think
there is, then that argument applies equally to window resizing and border
movement. With such a bundle, it makes sense for the default behavior to be
the behavior that is most common (80%) rather than least common.

You may disagree about the common use case (though you agreed before). I
don't use Emacs windows much, but I did for decades. I cannot imagine that
someone would typically be interested in border movement and not simply
resizing. My guess is that the reasons you and Lennart concentrate on border
movement are (1) that it has been more fun (more of a challenge)
implementing and (2) it is more general.

Neither of those is a good reason to make it the default. It should be the
default only if it is a more common task.

> > The prompt doesn't say anything about the possibilities.
>
> This is because we're not in a loop anymore.  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 `?').

> > There is (almost) no feedback during window resizing.
>
> "Less is better."  There is feedback when no move is possible.  What
> feedback are you really missing?

Window resizing. I'm talking about window resizing, not border movement. 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").

You've concentrated so much on border movement, perhaps to match Lennart's
bells and whistles, that you've lost sight of the common use case - simple
resizing.

> > Shrinking a window can make it disappear.
>
> I somehow tend to think this is an issue with `shrink-window' itself.
> It doesn't quite respect `window-min-height'.

That's not an argument. If `shrink-window' doesn't do what you need by
itself, then compensate in the code. This was working 100% well before, BTW:
you had previously corrected this bug; this is a regression. It seems to
work in the horizontal direction, BTW; I think it is only vertical resizing
that is broken.

> > C-g doesn't quit ("Key `^G' not bound").
>
> Right, fixed.

Thx, one should always respect C-g.

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

> > Too bad. You appear to have "improved" it to the point of regress. ;-)
>
> No.  I think windresize.el (was window-resize.el) fits more its goal.  I
> will give it a rest for a while, and see what people think.

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

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.