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: Sun, 11 Nov 2007 00:42:45 -0800 Message-ID: References: <87ejexwf4m.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 1194770613 14386 80.91.229.12 (11 Nov 2007 08:43:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2007 08:43:33 +0000 (UTC) To: "Bastien" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 11 09:43:36 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 1Ir8Pn-0006V4-3l for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2007 09:43:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ir8Pb-0000DX-8q for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2007 03:43:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ir8PW-0000AI-36 for emacs-devel@gnu.org; Sun, 11 Nov 2007 03:43:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ir8PU-00008q-VK for emacs-devel@gnu.org; Sun, 11 Nov 2007 03:43:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ir8PU-00008U-P1 for emacs-devel@gnu.org; Sun, 11 Nov 2007 03:43:16 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ir8PU-0007g3-3n for emacs-devel@gnu.org; Sun, 11 Nov 2007 03:43:16 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ir8PM-0003at-Cp for emacs-devel@gnu.org; Sun, 11 Nov 2007 03:43:08 -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 lAB8gtZa005719; Sun, 11 Nov 2007 02:42:55 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lAB8gsNj005702; Sun, 11 Nov 2007 01:42:55 -0700 Original-Received: from 141.144.89.9 by acsmt350.oracle.com with ESMTP id 3358916301194770561; Sun, 11 Nov 2007 00:42:41 -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: <87ejexwf4m.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 mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:82934 Archived-At: > 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.