[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lennart Borgman (gmail)
Subject: Re: New keybinding suggestion: C-x _ for `shrink-window'
Date: Sat, 17 Nov 2007 16:44:53 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

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.


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


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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]