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, 16 Nov 2007 15:49:53 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195257075 3106 80.91.229.12 (16 Nov 2007 23:51:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2007 23:51:15 +0000 (UTC) Cc: Bastien , "Richard M. Stallman" , emacs-devel@gnu.org To: "Lennart Borgman \(gmail\)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 17 00:51:19 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 1ItAxy-0002hQ-Cx for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2007 00:51:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItAxl-000616-CM for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2007 18:51:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItAxh-0005yC-59 for emacs-devel@gnu.org; Fri, 16 Nov 2007 18:51:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItAxf-0005vq-OW for emacs-devel@gnu.org; Fri, 16 Nov 2007 18:51:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItAxf-0005vh-LD for emacs-devel@gnu.org; Fri, 16 Nov 2007 18:50:59 -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 1ItAxb-0004uO-PW; Fri, 16 Nov 2007 18:50:56 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lAGNomoC025366; Fri, 16 Nov 2007 17:50:49 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lAG84RcI032578; Fri, 16 Nov 2007 16:50:48 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3371557801195256989; Fri, 16 Nov 2007 15:49:49 -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: 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:83391 Archived-At: > > > 4. No need to highlight the mode lines of all windows. It would > > > be helpful to highlight only the border to be moved - perhaps > > > by showing the corresponding fringe specially temporarily > > > (left/right) or highlighting the appropriate mode line (only). > > > > Thanks, I did not think about fringes. But I wonder if it is possible. > > First it looks like there are not window specific fringes - or are > > there? Then I am not sure there are any usable fringes defined > > currently - or? > > I don't know much about fringes. My main point was that there is > no need to highlight any mode line except possibly the one along > the border to be moved. The rest is just distraction. I'm not > against highlighting, but only if it serves a purpose. I see that this has not changed. I reiterate the following suggestions: 1. There is no need to highlight the mode lines of the windows that are *not* being resized - that serves only to distract. 2. The window being resized is already highlighted using the background overlay. There is no reason to also highlight its mode line - *unless* the mode-line highlighting indicates that that particular border is being moved (which it does not, for the moment). 3. It would be very helpful if the mode line of the border being moved were highlighted. That would not help with the top border of a window at the top of the frame, and it would not help with a vertical border, but at least it would help with the other borders. 4. For vertical borders, you can, I think, use something in the fringe to indicate the border being moved. Again, I'm not an expert on fringe, but this should be possible. IIUC, fringe is window-specific, and the left and right can be manipulated separately. 5. For consistency, the mode-line indication for moving a horizontal border could be (a temporary display that is) similar to whatever you use in the fringe. 6. If you can't use fringe, then consider using the so-called "overlay arrow". Or a temporary `display' property. Or something else. (Fringe would be much better, however.) There should be some indication of which border is the subject. > > > 6. You should not exit window resizing just because you click > > > somewhere outside the frame that has the windows to be resized, > > > or even outside Emacs (the latter happens only sometimes). > > > > The implementation uses overriding-terminal-local-map during resizing. > > That means that there are two alternatives when switching frame: Either > > resize on that frame too or stop resizing when switching frame. I have > > chosen the latter. > > I can't speak to the problem of implementation - my comment was as a user. The problem is still there. > > > 7. I hit `?' for help. I got no help, and all of the windows > > > were blown away except one. I tried it other times, and the > > > frame itself was blown away. The latter effect is from my > > > code, but it indicates that `delete-window' was > > > called for the last remaining window. > > > > Thanks I will try to fix it. Probably something with popup frames. > > Yes, probably. Bastien had a similar problem. The solution was to use > (with-output-to-temp-buffer "*Help*"...). This problem remains. Now, the help text replaces all windows in the frame (no reason for that), and when I hit `q' the entire frame is deleted. Also, the *Help* buffer is currently not read-only. Please use (with-output-to-temp-buffer "*Help*"...) or equivalent. It will solve the problem. [The reason that the frame is deleted in my case is no doubt because I have redefined `delete-window' to delete the frame also if the window is `one-window-p'. Without that redefinition, a call to `delete-window' will do nothing if `one-window-p' - it just raises an error that you can't delete the sole window. That is not TRT either.] > > > 8. Some way to save and restore window configs would be nice. > > > > I think Bastien had the idea of using a kill ring for that. Is that > > useful? Maybe some convenient way to choose from that then? > > He uses a ring (but not the kill-ring). Yes, it's useful and convenient, > IMO. It's likely that a user will fiddle with resizing only a > relatively few > times during an Emacs session (or during a particular work task). S?he is > likely to want to return to a configuration s?he already had, rather than > fine-tuning sizes again from scratch. `!' is not the best choice for config saving, IMO. It usually indicates something that requires care or has a non-reversible effect. Saving a window config is entirely benign. Consider using `s' or `C-x C-s' or similar. > > > 9. Sometimes, I need to press M-left (or right etc) to get it to take > > > effect - the first press does nothing. > > > > M-left etc first switches border and then window. Is that what happens? > > I don't know. As a user, it seems that there is an unnecessary (extra) > keystroke. But there is no feedback for what it does, so I can't tell you > what it's doing. You provided some feedback; thanks. Still, it would be better if the feedback mentioned *which* border was selected, especially if you don't show that visually. > > > 11. `=' in lower left window (configuration 3 2 3 2), causes > > the two windows > > > above it to have the same width. What does "Make current window > > siblings the > > > same height or width." mean? Does it mean make the siblings the same > > > height/width as each other or the same as the selected window? > > Sometimes it > > > seems to be one, sometimes the other. > > > > It works the same way as balance-windows, but only for siblings. The > > concept is actually a tree where the siblings in each node get equal > > amounts of space. > > Equal to what? That's the question. Sometimes they seem to be > equal only to > each other; sometimes they seem to be equal to each other and to the > selected window. New problems I noticed: Please don't use the mouse pointer to try to indicate the selected border. That's not what it is for. Also, it is misleading and annoying if you just click a window to select it - the mouse pointer should, well, point out the mouse position. And, before clicking mouse-1 to select a window, I would not even have noticed this (mis-)feature if I had not read the email thread. BUG: Configuration 3 2 3 2; cursor in lower-left window; hit `='. All windows along the left side are replaced by a single window. With cursor in top-middle window, the windows is extended to full frame height, and one of the windows on the left side is deleted. None of this behavior seems comprehensible or right. BUG: Sometimes, when I hit `C-g', all windows but one disappear. That is, from, say, 5 windows I end up with only one. Suggestion: Bind `q' also to `winsize-quit'. Currently, it is self-inserting. I don't understand why you have (define-key [t] 'winsize-stop-and-execute). Why allow any keys to (exit and) self-insert? Why not make the user explicitly exit first? That's not hard for the user to do. Otherwise, they will get some surprises. Why `4' for `other-window'? If a binding for this is really needed (not IMO), `o' is better. Why bind both `mouse-1' and `down-mouse-1' to the same command? Please take a look at the behavior of Bastien's code and perhaps my feedback that led to some of the changes he made. IMO, some of his UI is more natural than yours. But I like the idea of highlighting the selected window (but please also highlight the selected border). Please think about adding simple window-resizing as the default behavior. I really think that 90% of the time a user will need and use only that; s?he will not bother to move a particular border. To me, it is overly complex to make a user reason in terms of border movement, if all s?he wants to do is increase or decrease the size of a window. Border movement is fine tuning that will rarely be needed, IMO. HTH.