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

[Lennart Borgman (gmail)]

Drew Adams wrote:
> > 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.

It serves a purpose, it shows that Emacs is now doing something 
different with the input you give. And changing the colors of the 
borders seems adequate since this is what you are currently working 
with, moving and/or deleting them.

But I made this optional ;-)


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

I thought the same myself, but I was not sure, since the selected window 
normally have another mode color. I made this an option to for that.


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

Maybe, but wouldn't it be confusing when you exit window resizing, at 
least if you have choosen to not have any background color for the 
selected window (in this case Juri's proposal is better).


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

Didn't I tell that it looked impossible to use the fringes for this?


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

If it were possible, yes.


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

Is not that tied to the buffer text? That means you can not position it 
were you want. You have more freedom with the mouse pointer.


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

I did comment on that, didn't I? I can see that this is a problem for 
you since you use popup frames. An alternative to end it as I do now 
would be to pause it and resume it when switching back to the other 
frame. (That was actually one of the reasons I choosed to have other 
colors for the mode lines during resizing, at least as a possibility.)


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

Oh, yes, there is a reason. When you are trying to arrange the window 
borders to your taste I believe it would be irritating to get this 
destroyed by some help function tampering with the window layout.

> and when I hit `q' the entire frame is deleted. 

Eh, sorry ;-) It is not supposed to do that. It should restore the 
window layout you had before you asked for help.

There must be something I have missed about the handling of popup 
windows. I do not know very much about them since I do not use them 
myself. (I maximize all windows ...)

> Also, the *Help* buffer is currently not read-only.

Oh. The help functions are not easy. Fixed. Thanks.

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

You always do that with the normal help functions.

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

I wonder what happens. The only thing I do to make exit help resume the 
window resizing is to set `view-exit-action' to the function 
winsize-restore-after-help. Could you please look at that function and 
see if you can find anything suspicious there. I can not see anything 
myself.

Which version of winsize.el are you using? I just uploaded a new version 
with the help buffer read-only problem fixed.

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

Doesn't it also mean "I like this!"?

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

Thanks, added.

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

It is actually used to indicate the border while resizing w32 windows 
from the keyboard. In that case the mouse is moved back to where it was 
before resizing, but since we might to more here when resizing several 
windows, maybe splitting and deleting to I did not find it meaningful to 
put back the mouse where it was. It would probably instead be more 
confusing.

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

This is the way the function fit-window-to-buffer-works. Maybe I should 
use shrink-window-if-larger-than-buffer instead? Or

  =   fit-window-to-buffer-works
  -   shrink-window-if-larger-than-buffer

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

C-g should quit window resizing and go back to the configuration you 
started with.

There might be some bug if help was quitted in an unexpected way. Some 
example would help.

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

I have tried to avoid using alphabetic characters so that it is easy 
that all just quits resizing and self-insert.

But this is one of the points were I am not sure. The current use of key 
bindings during resizing is maybe inconsistent.

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

Just because I was not sure which one is used for choosing window.

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

I do not think it is a good idea personally. Here are some reasons:

- What would it mean to increase or decrease the window? Don't you care 
if it is done horizontally or vertically?

- If you do then why not use the arrow keys and move the border in the 
desired direction? That behaviour would be consistent with what most 
users expect I believe.

- Mixing different ways to do resizing might be very confusing.

- At least users on w32 are used to reszing with the arrow keys (if they 
use the keyboard for that).

> HTH.

Thanks for thinking about it. I am not writing this for myself (only ;-)