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: Bastien
Subject: Re: New keybinding suggestion: C-x _ for `shrink-window'
Date: Sun, 18 Nov 2007 00:10:30 +0000
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.0 (gnu/linux)

"Drew Adams" <address@hidden> writes:

>> Unless lots of people complain about this, I think it's ok to make the
>> move-borders method the default.  If the user just wants to shrink or
>> enlarge the window, she might just use the already available keys.
>
> You may disagree about the common use case (though you agreed before). I
> don't use Emacs windows much, but I did for decades. I cannot imagine that
> someone would typically be interested in border movement and not simply
> resizing. My guess is that the reasons you and Lennart concentrate on border
> movement are (1) that it has been more fun (more of a challenge)
> implementing and (2) it is more general.

Yes, you may be right.  As you pointed out, I have no steady opinion on
what should be the default.  Let's wait and see what other people think.

>> Any suggestion on making the prompt persistent while in a major mode?
>
> It doesn't need to be repeated. It is the initial prompt that lets you know
> that there are many possibilities, that this is a command that lets you
> perform various operations on windows. Either the prompt should be somewhat
> general or there should be none (or perhaps just "`?' for help"). This is
> akin to Dired and Buffer Edit, which have no such prompt. Currently, the
> prompt tells you only about border movement (and `?').

The initial prompt is:

  "Use the arrow keys to resize windows (`?' for more)"

I think it is general.  Suggestion?

>> "Less is better."  There is feedback when no move is possible.  What
>> feedback are you really missing?
>
> Window resizing. I'm talking about window resizing, not border movement. The
> feedback telling you that the window cannot be resized is now missing (but I
> did see it pop up in one such situation, however, so I said "almost").
>
> You've concentrated so much on border movement, perhaps to match Lennart's
> bells and whistles, that you've lost sight of the common use case - simple
> resizing.

I added more feedback for normal resizing.

>> > With pop-up-frames non-nil, at least, `q' in *Help* quits resizing,
>> > not *Help* (a second `q' then quits help), and it deletes one of the
>> > windows of the initial config. And so on.
>>
>> I think this is an issue with `overriding-terminal-local-map'.  I might
>> find a workaround later.
>
> Again, this was fixed and working before - regression.

I used the same workaround, namely disabling windresize-mode if
pop-up-frames is `t' and the user wants to display the help.

> If the goal is to let people manipulate windows in various ways: their
> number, size, and relative positions (including borders), then I
> disagree.  It was better before. In terms of implementation, it might
> be better to use a keymap and mode than a read-event loop, but it is
> only better if the behavior is at least as good. The latest changes
> sacrifice the user experience (so far).

Yes.  Please consider that switching from the loop to the mode was quite
an amount of work; i couldn't implement all features from window-edit.el
at the same time and didn't want to spent time on features that I wasn't
sure people would need.

If your patience can suffer this, let me know about windresize.el 0.4 :)

> I've been testing this and Lennart's, even though I hardly ever
> resize, split etc. Emacs windows (I use frames) anymore. I too will
> give it a rest, as my input seems to be less effective now.

Thanks again for the feedback!  I guess it's more rewarding for me (or
Lennart) to try to fiddle with the code than for you to comment in the
hope that all your comments will be useful... 

'doing my best, though.

-- 
Bastien




reply via email to

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