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

[Drew Adams]

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

Sorry, I don't understand what you are saying here. Something different from
what with what input you give? Changing the colors of which borders seems
adequate? I don't understand your last sentence at all.

The highlighting of all mode lines doesn't change depending on your input
(aside from the highlighting of the selected window's mode line). It is a
constant, and just represents noise - it doesn't indicate anything (except
that you are using `resize-windows').

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

Sorry, I don't understand, again. Changing the mode line of the selected
window is not needed to simply show that the window is selected - you
already change the window background to show 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).

You have chosen to highlight the selected window's background, no? Why would
highlighting the border to be moved be confusing when you exit resizing? I
really do not follow you, sorry.

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

No, you said that you didn't know, and you thought that fringe was not
window-specific - but it is, AFAIK. What is the impossibility you see 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.

What is the impossibility you see?

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

Yes, but there is some buffer text in the window, presumably. You need only
some line of text (preferably mid-window). This is not as good as using
fringe, admittedly, but it is better than abusing the mouse pointer.

> You have more freedom with the mouse pointer.

I don't know what freedom I have with it, but the mouse pointer is a bad
idea. It is either unnoticeable (if you aren't currently using the mouse) or
it is plain wrong (if you are using the mouse). It should reflect the mouse
position.

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

Help in a separate frame does not tamper 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 ...)

If you maximize all windows, then you will certainly have difficulty
implementing and testing a command for resizing 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.

I don't know what that means. The above problems (popup frame, self-insert
keys, `q' etc.) should be solved if you just use that form. The *Help*
buffer should then be in help-mode.

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

No way I'm going to dive into view-exit-action - sorry. The
help-mode/view-mode code is quick-sand. Again, (with-output-to-temp-buffer
"*Help*"...) should take care of these things - try it.

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

I used the last version you had posted before my reply: 0.94.

> > `!' 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!"?

Not to me. In some international signage, `!' means "Danger!". But I don't
really care which keys you use; it was just a suggestion.

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

Well, add my vote to those who don't care for it, whether MS Windows uses it
or not. For pointing out the selected border, it's useless here - unless you
already know to look for it. And if you click mouse-1 yourself, it is
downright confusing, since the pointer then doesn't correspond to where you
click.

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

I don't know. I'm unfamiliar with those commands. I only know that the
behavior I see doesn't correspond to anything I can make sense of or find
useful (in the cases I mentioned). If the functions you use don't do what's
right for this context, then you might want to use something else.

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

Yes, it should.

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

It has nothing to do with using help.

emacs -Q
(setq pop-up-frames t)
M-x resize-windows
3 2 3 2
C-g

Bam!

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

That responds to what you just wrote. Why not have a standard way to exit
and stick to it?

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

`mouse-1' is the usual binding for `mouse-set-point'. That should be fine.

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

See Bastien's alternate mode (which was the default mode before, and should
be again), which resizes the selected window. Both horizontal and vertical
resizing are available. Please give his code a try, to see what it does.

There is no reason to start with the complex if the simple does the job.
Most of the time, a user will just want to resize a window or two, not
necessarily move particular borders.

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

If a user wants only (horiz or vert) resizing, then it doesn't matter which
border moves, as long as the window is resized (horiz or vert).

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

See Bastien's code. There is no mixing. There are two possible modes. The
default mode is border movement. The alternate mode is window resizing. It
should be the other way around: simple as default, complex as alternate;
gross tuning as default, fine-tuning as alternate.

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

How many Windows users use the keyboard to resize frames? And does that
matter here? And you're talking about resizing frames anyway, in that case.

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

My main suggestions are (1) simplify the UI, and (2) find a good way to
indicate which border is active (for border movement).