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

[Lennart Borgman (gmail)]

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

It indicates just that (that you are using `resize-windows' at the 
moment). You might for example leave the computer for a while and come 
back. Isn't it good then to know that you are using `resize-windows'? 
You may have forgotten, but Emacs knows - and behaves a bit differently ;-)

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

Those two are alternatives that you can turn on/off with two defcustoms.

> No, you said that you didn't know, and you thought that fringe was not
> window-specific - but it is, AFAIK.

You are right.

> What is the impossibility you see?

Changing the colors of one of the fringes in a window.

> > You have more freedom with the mouse pointer.
>
> I don't know what freedom I have with it,

You can position the mouse pointer wherever you want.

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

As I said in the portion you are replying to here I do not think that is 
 wrong to use the mouse pointer to give feedback when you are working 
from the keyboard. That is the way the window manager in w32 sometimes 
does it. (It does exactly that when resizing a window from the keyboard.)

Of course one can have different opinions wheter this is good or bad, 
but "plain wrong" is a bit to strong here in my taste.

> Help in a separate frame does not tamper with the window layout.

It is a good point and I have already said that if it is desireable I 
could add support for it. It is however not quite as simple as one might 
expect in this case.

> If you maximize all windows, then you will certainly have difficulty
> implementing and testing a command for resizing windows. ;-)

;-)

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

I am afraid that you might be misunderstanding the problem here. What I 
have been trying to do is to temporary show the help and after this 
return to resizing for those people that do not normally use popup 
frames for help.

At the moment I have not taken care of popup help. I can do that if it 
is desireable, but it requires some careful thought about how to do it 
in this case. You are welcome with suggestions. (In fact I hoped that 
you would have some thoughts about this.) But please then try to answer 
the following questions:

- When showing help in a popup frame the popup frame should of course 
not be in a resizing state. Should resizing be resumed when quitting help?

- If yes how should that be indicated to the user?

- If no, when should resizing be resumed?

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

I decided to give the user the choice (= fit, - shrink).

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

Thanks.

> emacs -Q
> (setq pop-up-frames t)
> M-x resize-windows
> 3 2 3 2
> C-g
>
> Bam!
>
> I used the last version you had posted before my reply: 0.94.

Please try the latest version instead.

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

No problem. I actually wanted some feedback on this. The current way try 
to mimick how isearch exits, but that might be a bad choice in this case.

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

Thanks.

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

Unfortunately I think it is (or rather was) utterly confusing for more 
complex window layouts even though the intention to simply was nice. 
(For simple layouts it was fine.)

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

(1) can't be done without (2) here. The problem is really that it is 
hard to find a good way to do (2). That was what I tried to explain from 
the beginning. Coloring the relevant vertical border or fringe would IMO 
opinion be the best solution. (An additional possibility is to change 
the mouse pointer shape, but that is a lot of work.)