From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: New keybinding suggestion: C-x _ for `shrink-window' Date: Sat, 17 Nov 2007 02:36:15 +0100 Message-ID: <473E458F.80009@gmail.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195263466 17888 80.91.229.12 (17 Nov 2007 01:37:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Nov 2007 01:37:46 +0000 (UTC) Cc: Bastien , "Richard M. Stallman" , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 17 02:37:50 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 1ItCd3-0002ca-78 for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2007 02:37:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItCcq-0001J2-4c for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2007 20:37:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItCc5-0000jB-QJ for emacs-devel@gnu.org; Fri, 16 Nov 2007 20:36:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItCc5-0000iw-28 for emacs-devel@gnu.org; Fri, 16 Nov 2007 20:36:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItCc4-0000it-W9 for emacs-devel@gnu.org; Fri, 16 Nov 2007 20:36:49 -0500 Original-Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ItCby-0006jD-2A; Fri, 16 Nov 2007 20:36:42 -0500 Original-Received: from c83-254-148-228.bredband.comhem.se ([83.254.148.228]:61457 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1ItCbk-0006QO-6A; Sat, 17 Nov 2007 02:36:29 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: X-Antivirus: avast! (VPS 071116-0, 2007-11-16), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.148.228 X-Scan-Result: No virus found in message 1ItCbk-0006QO-6A. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1ItCbk-0006QO-6A 2bb706e741451ed0793402f56ac61b31 X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) 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:83396 Archived-At: Drew Adams wrote: >> 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. It serves a purpose, it shows that Emacs is now doing something different with the input you give. And changing the colors of the borders seems adequate since this is what you are currently working with, moving and/or deleting them. But I made this optional ;-) > 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). I thought the same myself, but I was not sure, since the selected window normally have another mode color. I made this an option to for that. > 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. Maybe, but wouldn't it be confusing when you exit window resizing, at least if you have choosen to not have any background color for the selected window (in this case Juri's proposal is better). > 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. Didn't I tell that it looked impossible to use the fringes for this? > 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. If it were possible, yes. > 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. Is not that tied to the buffer text? That means you can not position it were you want. You have more freedom with the mouse pointer. >>>> 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. I did comment on that, didn't I? I can see that this is a problem for you since you use popup frames. An alternative to end it as I do now would be to pause it and resume it when switching back to the other frame. (That was actually one of the reasons I choosed to have other colors for the mode lines during resizing, at least as a possibility.) >>>> 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), Oh, yes, there is a reason. When you are trying to arrange the window borders to your taste I believe it would be irritating to get this destroyed by some help function tampering with the window layout. > and when I hit `q' the entire frame is deleted. Eh, sorry ;-) It is not supposed to do that. It should restore the window layout you had before you asked for help. There must be something I have missed about the handling of popup windows. I do not know very much about them since I do not use them myself. (I maximize all windows ...) > Also, the *Help* buffer is currently not read-only. Oh. The help functions are not easy. Fixed. Thanks. > Please use (with-output-to-temp-buffer "*Help*"...) or equivalent. It will > solve the problem. You always do that with the normal help functions. > [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.] I wonder what happens. The only thing I do to make exit help resume the window resizing is to set `view-exit-action' to the function winsize-restore-after-help. Could you please look at that function and see if you can find anything suspicious there. I can not see anything myself. Which version of winsize.el are you using? I just uploaded a new version with the help buffer read-only problem fixed. > `!' 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. Doesn't it also mean "I like this!"? > 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. Thanks, added. > 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. It is actually used to indicate the border while resizing w32 windows from the keyboard. In that case the mouse is moved back to where it was before resizing, but since we might to more here when resizing several windows, maybe splitting and deleting to I did not find it meaningful to put back the mouse where it was. It would probably instead be more confusing. > 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. This is the way the function fit-window-to-buffer-works. Maybe I should use shrink-window-if-larger-than-buffer instead? Or = fit-window-to-buffer-works - shrink-window-if-larger-than-buffer > BUG: Sometimes, when I hit `C-g', all windows but one disappear. That is, > from, say, 5 windows I end up with only one. C-g should quit window resizing and go back to the configuration you started with. There might be some bug if help was quitted in an unexpected way. Some example would help. > Suggestion: Bind `q' also to `winsize-quit'. Currently, it is > self-inserting. I have tried to avoid using alphabetic characters so that it is easy that all just quits resizing and self-insert. But this is one of the points were I am not sure. The current use of key bindings during resizing is maybe inconsistent. > 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? Just because I was not sure which one is used for choosing window. > 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. I do not think it is a good idea personally. Here are some reasons: - What would it mean to increase or decrease the window? Don't you care if it is done horizontally or vertically? - If you do then why not use the arrow keys and move the border in the desired direction? That behaviour would be consistent with what most users expect I believe. - Mixing different ways to do resizing might be very confusing. - At least users on w32 are used to reszing with the arrow keys (if they use the keyboard for that). > HTH. Thanks for thinking about it. I am not writing this for myself (only ;-)