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

[Drew Adams]

> > 1. In addition to the test frame, I had also another frame
> showing the same
> > file (your file). The latter frame was scrolled down to show command
> > resize-windows. I put the cursor in one of the windows on the
> other frame
> > and used M-x resize-windows. The second frame was scrolled to the top.
> > That's a bug, IMO: Other frames should not be affected, and no
> window should
> > be scrolled, just because I'm resizing windows. I had to copy
> the code to
> > another buffer, just to be able to continue seeing it while executing
> > resize-windows.
>
> That is very strange. I can see nothing like that happening.

I no longer see it now either; sorry. Don't know what caused it
(repeatedly), but since I can't reproduce it now, please ignore the noise.

> > 3. So allow C-n, C-f, etc. to move the cursor without exiting.
> That way, you
> > can use M-<arrow> to get to any window you want, using just the
> keyboard.
>
> I can not find any window configuration where I see the problem. If
> however it does happen then I think it is a bug in windmove.

The config I gave: 3 2 3 2. And the example I gave Bastien before.
Basically, the cursor position determines the destination window to the left
(for example), when there is more than one such window. You need to be able
to move the cursor to put it next to the window you want to move to.

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

> > 5. Highlighting the window background is not a great way to indicate the
> > border that will be moved. But it does help show which window
> has the focus.
> > IMO, it would be better to not reuse face
> `secondary-selection', but define
> > a new one just for this.
>
> I am a bit hesitating that this is worth the trouble of defining a new
> face. What is the drawbacks of using secondary-selection? (or maybe
> highlight?)

I'm probably alone on this - for some reason, people (mistakenly, IMO) want
to reuse faces in unrelated contexts.

My point is that the purpose of the face is not the same as the use you make
of it. A user might well want to change the face for just this use. A user
might think a yellow background is great for secondary selection (or
highlight or whatever), but s?he might not think it is so great to fill the
entire window for resizing - s?he might instead prefer a light gray or
pastel shading (or dark shading, for a dark background) for that - or
`default', to get no such highlighting at all.

There is zero connection between the meaning and use of the
`secondary-selection' face and the highlighting you are doing here. But, as
I said, I'm probably a lone voice on this matter.

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

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

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

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

> > 10. There is no feedback when resizing is not possible - the
> keys just seem
> > not to work.
>
> Ok, I will think about catching the error messages and showing them.

Some feedback for each keystroke isn't a bad idea here. If a window visibly
changes size, that's sufficient feedback; otherwise, something should be
echoed.

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

> I can find no good and short way to express that though.
>
> > 12. `-' seems to do nothing.
>
> It only shrinks vertically and if the buffer height is smaller than the
> window height. There should be some feedback when that is not the case,
> I will add it.

Not just feedback, but doc. There is no doc for it, beyond the function
name, and that just tells you that it shrinks the window. So far, I don't
see the value of (use case for) this option.

HTH.