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

[Drew Adams]

> > > 4. No need to highlight the mode lines of all windows. It would
> > > be helpful to highlight only the border to be moved - perhaps
> > > by showing the corresponding fringe specially temporarily
> > > (left/right) or highlighting the appropriate mode line (only).
> >
> > Thanks, I did not think about fringes. But I wonder if it is possible.
> > First it looks like there are not window specific fringes - or are
> > there? Then I am not sure there are any usable fringes defined
> > currently - or?
>
> I don't know much about fringes. My main point was that there is
> no need to highlight any mode line except possibly the one along
> the border to be moved. The rest is just distraction. I'm not
> against highlighting, but only if it serves a purpose.

I see that this has not changed. I reiterate the following suggestions:

1. There is no need to highlight the mode lines of the windows that are
*not* being resized - that serves only to distract.

2. The window being resized is already highlighted using the background
overlay. There is no reason to also highlight its mode line - *unless* the
mode-line highlighting indicates that that particular border is being moved
(which it does not, for the moment).

3. It would be very helpful if the mode line of the border being moved were
highlighted. That would not help with the top border of a window at the top
of the frame, and it would not help with a vertical border, but at least it
would help with the other borders.

4. For vertical borders, you can, I think, use something in the fringe to
indicate the border being moved. Again, I'm not an expert on fringe, but
this should be possible. IIUC, fringe is window-specific, and the left and
right can be manipulated separately.

5. For consistency, the mode-line indication for moving a horizontal border
could be (a temporary display that is) similar to whatever you use in the
fringe.

6. If you can't use fringe, then consider using the so-called "overlay
arrow". Or a temporary `display' property. Or something else. (Fringe would
be much better, however.) There should be some indication of which border is
the subject.

> > > 6. You should not exit window resizing just because you click
> > > somewhere outside the frame that has the windows to be resized,
> > > or even outside Emacs (the latter happens only sometimes).
> >
> > The implementation uses overriding-terminal-local-map during resizing.
> > That means that there are two alternatives when switching frame: Either
> > resize on that frame too or stop resizing when switching frame. I have
> > chosen the latter.
>
> I can't speak to the problem of implementation - my comment was as a user.

The problem is still there.

> > > 7. I hit `?' for help. I got no help, and all of the windows
> > > were blown away except one. I tried it other times, and the
> > > frame itself was blown away. The latter effect is from my
> > > code, but it indicates that `delete-window' was
> > > called for the last remaining window.
> >
> > Thanks I will try to fix it. Probably something with popup frames.
>
> Yes, probably. Bastien had a similar problem. The solution was to use
> (with-output-to-temp-buffer "*Help*"...).

This problem remains. Now, the help text replaces all windows in the frame
(no reason for that), and when I hit `q' the entire frame is deleted. Also,
the *Help* buffer is currently not read-only.

Please use (with-output-to-temp-buffer "*Help*"...) or equivalent. It will
solve the problem.

[The reason that the frame is deleted in my case is no doubt because I have
redefined `delete-window' to delete the frame also if the window is
`one-window-p'. Without that redefinition, a call to `delete-window' will do
nothing if `one-window-p' - it just raises an error that you can't delete
the sole window. That is not TRT either.]

> > > 8. Some way to save and restore window configs would be nice.
> >
> > I think Bastien had the idea of using a kill ring for that. Is that
> > useful? Maybe some convenient way to choose from that then?
>
> He uses a ring (but not the kill-ring). Yes, it's useful and convenient,
> IMO. It's likely that a user will fiddle with resizing only a
> relatively few
> times during an Emacs session (or during a particular work task). S?he is
> likely to want to return to a configuration s?he already had, rather than
> fine-tuning sizes again from scratch.

`!' is not the best choice for config saving, IMO. It usually indicates
something that requires care or has a non-reversible effect. Saving a window
config is entirely benign. Consider using `s' or `C-x C-s' or similar.

> > > 9. Sometimes, I need to press M-left (or right etc) to get it to take
> > > effect - the first press does nothing.
> >
> > M-left etc first switches border and then window. Is that what happens?
>
> I don't know. As a user, it seems that there is an unnecessary (extra)
> keystroke. But there is no feedback for what it does, so I can't tell you
> what it's doing.

You provided some feedback; thanks. Still, it would be better if the
feedback mentioned *which* border was selected, especially if you don't show
that visually.

> > > 11. `=' in lower left window (configuration 3 2 3 2), causes
> > the two windows
> > > above it to have the same width. What does "Make current window
> > siblings the
> > > same height or width." mean? Does it mean make the siblings the same
> > > height/width as each other or the same as the selected window?
> > Sometimes it
> > > seems to be one, sometimes the other.
> >
> > It works the same way as balance-windows, but only for siblings. The
> > concept is actually a tree where the siblings in each node get equal
> > amounts of space.
>
> Equal to what? That's the question. Sometimes they seem to be
> equal only to
> each other; sometimes they seem to be equal to each other and to the
> selected window.

New problems I noticed:

Please don't use the mouse pointer to try to indicate the selected border.
That's not what it is for. Also, it is misleading and annoying if you just
click a window to select it - the mouse pointer should, well, point out the
mouse position. And, before clicking mouse-1 to select a window, I would not
even have noticed this (mis-)feature if I had not read the email thread.

BUG: Configuration 3 2 3 2; cursor in lower-left window; hit `='. All
windows along the left side are replaced by a single window. With cursor in
top-middle window, the windows is extended to full frame height, and one of
the windows on the left side is deleted. None of this behavior seems
comprehensible or right.

BUG: Sometimes, when I hit `C-g', all windows but one disappear. That is,
from, say, 5 windows I end up with only one.

Suggestion: Bind `q' also to `winsize-quit'. Currently, it is
self-inserting.

I don't understand why you have (define-key [t] 'winsize-stop-and-execute).
Why allow any keys to (exit and) self-insert? Why not make the user
explicitly exit first? That's not hard for the user to do. Otherwise, they
will get some surprises.

Why `4' for `other-window'? If a binding for this is really needed (not
IMO), `o' is better.

Why bind both `mouse-1' and `down-mouse-1' to the same command?

Please take a look at the behavior of Bastien's code and perhaps my feedback
that led to some of the changes he made. IMO, some of his UI is more natural
than yours. But I like the idea of highlighting the selected window (but
please also highlight the selected border).

Please think about adding simple window-resizing as the default behavior. I
really think that 90% of the time a user will need and use only that; s?he
will not bother to move a particular border. To me, it is overly complex to
make a user reason in terms of border movement, if all s?he wants to do is
increase or decrease the size of a window. Border movement is fine tuning
that will rarely be needed, IMO.

HTH.