emacs-devel
[Top][All Lists]
Advanced

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

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


From: Drew Adams
Subject: RE: New keybinding suggestion: C-x _ for `shrink-window'
Date: Sun, 11 Nov 2007 00:42:45 -0800

> Please check the latest window-edit.el here:
>   http://www.cognition.ens.fr/~guerry/u/window-edit.el
>
> > 1. When I use `?', I get a new frame *window-edit help* (I use non-nil
> > `pop-up-frames'). If I click mouse-1 in that frame, then the frame
> > disappears. That's no good. I need to be able to go to the help
> > frame, move around, select text, etc.
>
> I'm not sure about this.  The help window is now quite big, and people
> using window-edit with a lot of windows might prefer not to loose their
> configuration just by displaying the help window.

I cannot see all of the text in the pop-up frame, and if I try to use the
mouse to resize the frame, the frame disappears - very user unfriendly.

To handle this for users with `pop-up-frames' non-nil as well as other
users, just use (with-output-to-temp-buffer "*Help*" ...), and don't read an
event to delete the buffer/window/frame. Users can use `q' in *Help* to get
rid of it, as usual. You can use `princ' to insert text in *Help*. The code
is also simpler that way - no switch-to-buffer-other-window, no
get-buffer-create, etc.

BTW, I don't see where you ever use `display-help-window', but you set
`last-command' to it - why? Is that a typo for `display-help-message'?

> Hitting `?' once will first show a small help message, depending on
> the mode you're on.

It doesn't tell you about SPC to switch mode.

> Then hitting `?' again will display the window help.

If you try the *Help* window suggested above, I don't think you'll need two
levels of help.

> > 3. Need more help in the help window. For instance, what do the
> arrows do,
> > by default? What does the prefix arg do?
>
> I tried to improve this.

Dunno, I can't see it (see above) ;-).

Well, I can read it in the source code. Looks OK. Perhaps "toggle" instead
of "switch". Perhaps "next window in arrow direction" instead of "jump
to..." Be consistent with letter case for "INCREMENT". "quit" is sufficient.
`other-window' is clearer for `o'. "C-f C-b" should be "C-f, C-b" to avoid
confusion with a two-key sequence. And "moving a border", not "moving its
borders" (only one is moved).

> > f. Whenever an arrow key cannot move a border for some reason, the user
> > should get feedback explaining why. For instance, in a window that is
> > full-frame height, you cannot move a border up or down, but there is no
> > message.
>
> Fixed.  Let me know what you think.

No, still no message for not being able to move border down in full-height
window.

And I still see the problem that trying to move a border of one window
instead moves a border of another window. E.g. window-edit 3 2 3 2, as
before, then put cursor in middle-top window and try to move border `down'.
The border between the top-left and middle-left window is instead moved
`up' - no relation to what is requested.

Also, in move-border mode, with cursor in right window, `left' moves both
the window's left border left (correct) and the other two vertical borders,
between top-left/middle-left and middle-left.

I think the border movement generally still has some some problems.

> > g. There is still the problem that moving a border can make windows
> > disappear because they get too small. To me, that's not the
> right behavior.
> > They should respect `window-min-width' and `window-min-height'
> - you should
> > get a "can't move..." message if the requested movement tries
> to undercut
> > these limits.
>
> Fixed.

I still see the problem: With cursor in bottom-left window, use `up'
repeatedly. Eventually, the top-left window disappears (there is no "can't
move" message).

> > 7. The binding of `echo-keystrokes' is not working. If I move
> the focus to
> > another window-manager window (e.g. this mail message, outside
> Emacs), then
> > I see a long string of keystrokes filling the echo area. Maybe move the
> > binding higher up?
>
> I already set (echo-keystrokes 0) - what can I do?

Move the binding to your first `let' - that takes care of it.

Also, C-N works only for positive N, not negative N. I tried C- - 1, and it
just removed all windows (like C-x 1), because the C- - was ignored. That's
OK, but if if that's the way it is, then the doc should say "N > 0".

> > 9. The prompt is still not general enough, IMO.
>
> Please comment the new prompt.

OK by me.

You might need to require `cl' at compile time, for macro `case' (but there
was some talk of adding that to Emacs - maybe that was already done).

Possibility: When you restore the last window config, first save the current
config at the end of the ring. That way, `s'.changes.`r'.`r' will bring back
the config before the first restoration.

It would be helpful if the feedback told you which window config was
saved/restored. E.g. saved config #2, restored config #4 etc. That gives you
an idea where you are in the ring.

> > `mouse-1' should set point, in whatever window.
>
> Not yet done.  I will do this if the new window-edit.el if I have more
> feedback on window-edit.el, I need to be sure this is going somewhere.

Looks good to me. Hope you get input from others. Thanks for making the
changes.






reply via email to

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