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

["Lennart Borgman (gmail)" <lennart.borgman@gmail.com>]

Drew Adams wrote:
>> I have worked a bit with bw-interactive.el along the ideas that have
>> surfaced here (and some I had before). I have renamed it to winsize.el.
>>
>> It is mainly restructured for more flexibility. And some bugs have
>> probably been fixed + the features are more worked through.
>>
>> The resizing is done with the arrow keys. Switching borders and windows
>> are done with META-arrow keys. For more info see the help (just type ?
>> for that).
> 
> Some feedback from very quick testing - I used the config given by M-x
> resize-windows 3 2 3 2.

Thanks for testing.

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

> 2. M-left/right does not let you get to all windows (but you can click
> mouse-1 to get there). Actually, the problem seems to be the same as for
> window-edit: the cursor must be on a line that is adjacent to the window to
> select.

I think both Bastien and I use windmove for moving between the windows. 
(Using windmove makes it more consistent for the users, I hope.)

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

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

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

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

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

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

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

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

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


> HTH.

It does.