From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: New keybinding suggestion: C-x _ for `shrink-window' Date: Fri, 9 Nov 2007 17:09:58 -0800 Message-ID: References: <87bqa4bvnn.fsf@bzg.ath.cx> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1194657077 12011 80.91.229.12 (10 Nov 2007 01:11:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2007 01:11:17 +0000 (UTC) To: "Bastien" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 10 02:11:20 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IqesY-0005UI-SB for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2007 02:11:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqesN-0003fC-2s for ged-emacs-devel@m.gmane.org; Fri, 09 Nov 2007 20:11:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IqesJ-0003f7-MG for emacs-devel@gnu.org; Fri, 09 Nov 2007 20:11:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IqesH-0003ev-PK for emacs-devel@gnu.org; Fri, 09 Nov 2007 20:11:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqesH-0003es-I9 for emacs-devel@gnu.org; Fri, 09 Nov 2007 20:11:01 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IqesG-0003MT-W0 for emacs-devel@gnu.org; Fri, 09 Nov 2007 20:11:01 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lAA1Ao64021115; Fri, 9 Nov 2007 19:10:50 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lA9C73gs023891; Fri, 9 Nov 2007 18:10:49 -0700 Original-Received: from 141.144.90.13 by acsmt351.oracle.com with ESMTP id 3358118291194656997; Fri, 09 Nov 2007 17:09:57 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87bqa4bvnn.fsf@bzg.ath.cx> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82893 Archived-At: > I tried to implement Drew suggestions into one single function. > See my comments below. Any feedback is very welcome. Thanks for working some more on this. I didn't expect that you would implement most of what I suggested - they were just some ideas that occurred to me. Anyway, here is some more feedback to think about: I have a window config created by `window-edit 3 2 3 2'. I start with the cursor in the middle window at the left of the frame. 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. 2. When help is shown, the window configuration should be left as is, if `pop-up-frames' is non-nil. That is, there is no need to change it to a single window. 3. Need more help in the help window. For instance, what do the arrows do, by default? What does the prefix arg do? 4. Window resizing with arrows works fine. I see problems with border movement, however: a. Bug (?): Cursor in middle-left window. `down' increases the window size, as does ` `up': both move the upper border up. b. Bug (?): Arrows with cursor in bottom-left window affect only the middle-left window above it (and not even the common border): `up' moves that window's top border down; `down' moves it up. And `down' moves the cursor (focus) to that middle window (but `up' does not). c. Bug (?): Similarly, try to use `left' arrow on the rightmost window. That doesn't move either of its borders; instead, it moves the left border of the middle-top window to the right. The `right' arrow correctly moves the right window's left border to the right. One can work around this by negating the increment with `~' (because the problem/bug is then reversed). But the behavior is wrong, IMO. d. Bug (?): Increase middle-left window to its max size, so you get the [can't move up] message. Then put cursor in middle-top window and use `down'. That moves the cursor to the middle-left window and tries to increase it. There is no [can't move...] message, and the arrow in that window has no effect. What should happen is the top-left window should grow along with the bottom border moving down. Or at least something intuitive should happen. Or at least the user should get some feedback about what is going wrong. e. Bug (?): Increase middle-left window to its max size, so you get the [can't move up] message. Then try to move the lower border `down'. Nothing happens - no feedback, no movement. The border (common to middle-top window) should be moved down. 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. 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. 6. In general, border-movement mode seems inconsistent - or at least it is unclear to me what the arrows do: which border is moved which way. Please have a look a this again. 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? 8. +/- should go directly from 1 to -1, skipping 0, since 0 is a no-op for resizing and border movement. 9. The prompt is still not general enough, IMO. Consider moving the feedback regarding (1) the current mode (resize vs border-movement) and (2) error messages to the mode line as a temporary display. The prompt can include "[023=+-~srq? (S-)arrows]" as a reminder. I know you are most interested in border movement, but that is the least likely thing users will use this for, IMO - the prompt should emphasize 0, 2, 3, and = as much as the arrows, and it should definitely mention `q' and `?'. 10. Change "negate argument" to "negate increment". Change ARG everywhere to "INCREMENT", for clarity. And put ~ next to +/- in the help and the doc string, so it's clearer that they all apply to the increment. 11. Let the arrows resize instead of move borders, by default. Resizing is much easier to understand and works for 80% of what someone wants to do. Consider border movement as an "advanced" mode. It is a mistake to dump a user directly into border-movement mode, IMO. 12. Cursor in right window, `S-down' - no message. Instead, cursor moves to bottom-left window. Another `S-down' - still no message - and no more cursor movement. 13. Apparently, the cursor position within a window determines which window to move to with `S-'. That's a bonus. However, for that to be worthwhile, you need to allow `mouse-1' to set point. Example. With cursor in right window below midline window divider, `S-left' sends cursor to lower-left window. With cursor above midline, it sends it to middle-top window. That's good, but you should be able, with cursor below midline, to click mouse-1 above midline and then do `S-left' to move to middle-top window. 14. Yes, that is not very important, because if you can click above then you can also click in the window you want. However, you might want to let `C-b', `C-f', `C-p', and `C-n' move point to enable control over `S-'. That can be useful when there are multiple windows. For example, depending on where the cursor is and the line length of where it is moved to by `S-down', if you move from the middle-top window to the left-bottom window and then back up by `S-up', you might end up in the middle-left window or the middle-top window. 15. At the very least, this behavior needs to be explained to the user - s?he needs to know that the cursor position wrt the window divider determines the destination window. And s?he needs to know about the line-length thing: if the cursor position in the frame is to the right of the line length of the middle line in the destination window, then it will be moved to the middle-line end, which might move it across the window divider. > > * Use `case' (compile-time require cl) to simplify code. > > I didn't use it yet. It's simple: (case e (left (if...) (right (if...) (up (if...) (down (if...)) (case e (?0 (delete-other-windows)) (?2 ...) (?3 ...) (?o ...) ... (S-right ...) (S-down ...) ... ((?h ??) (let...))) You might have to juggle a couple of pieces that aren't just constant comparisons, but `case' will otherwise make the code more readable, IMO. (To juggle them, you can use `case's `otherwise' clause with a `cond' of `if'.) > Yes. Window configurations are now stored into a ring, so pressing `r' > twice will call back wcf2 then wcf1 if wcf1 and wcf2 were stored. The > first config in this ring is the initial one. Please make this clearer in the doc string and help. It's there, but it's not obvious. > > * When window reaches a minimum, trying to reduce it > > more either moves it instead or deletes it instead. > > Maybe do something different (e.g. nothing?). > > Fixed. Hence the ugly part of the defun. I couldn't figure out how to > factorize all this a bit yet. Suggestions welcome. See above. It still doesn't seem fixed to me. > > * Maybe let Shift always navigate - up/down/left/right, > > and use something else (`+' and `-'?) to > > increment/decrement ARG. > > Right. S- now navigates through windows direction-wise. > > > * And maybe let C-N (N an integer) set ARG absolutely? > > Done. Please document it. The doc string and `?' help say nothing about the prefix arg. > > * Maybe let mouse-1 select a window also. > > Done. `mouse-1' should set point, in whatever window. > > * Maybe use mouse wheel also (if direction is known)? > > Not done yet. Don't know if this is really useful. Probably not. > > * The prompt doesn't express much of what is possible. > > In particular, if `one-window-p', the prompt makes > > no sense (but `2' and `3' still make sense). > > Fixed, even though there is room for improvement. Yes, see above. The prompt should indicate the most useful/common keystrokes, and it should definitely indicate `q' and `?'. Other helpful info that is now in the prompt could be moved to the mode-line (as a temporary display). > > * Maybe let unrecognized events (keys, at least) quit > > instead of being ignored. And then perhaps be > > applied? So, e.g., `RET' would quit (and insert a > > newline?). > > Not done. Will work on this later. Depends on feedback about this > defun. Looking good, IMO. The most important thing to take care of is the behavior of arrows for moving borders: it's not understandable and is apparently somewhat inconsistent (bugged). HTH & thx.