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 16:44:53 +0100 Message-ID: <473F0C75.1020705@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 1195314330 2535 80.91.229.12 (17 Nov 2007 15:45:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Nov 2007 15:45:30 +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 16:45:35 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 1ItPrT-0001y2-0N for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2007 16:45:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItPrF-0006YN-EY for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2007 10:45:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItPrB-0006Xy-CI for emacs-devel@gnu.org; Sat, 17 Nov 2007 10:45:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItPrA-0006WF-0i for emacs-devel@gnu.org; Sat, 17 Nov 2007 10:45:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItPr9-0006Vx-T1 for emacs-devel@gnu.org; Sat, 17 Nov 2007 10:45:15 -0500 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ItPr5-0000TB-73; Sat, 17 Nov 2007 10:45:11 -0500 Original-Received: from c83-254-148-228.bredband.comhem.se ([83.254.148.228]:63917 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1ItPr2-0007d0-7O; Sat, 17 Nov 2007 16:45:09 +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 1ItPr2-0007d0-7O. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1ItPr2-0007d0-7O 41df2999b9fe6c307745adbed3ea6f46 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:83451 Archived-At: Drew Adams wrote: > The highlighting of all mode lines doesn't change depending on your input > (aside from the highlighting of the selected window's mode line). It is a > constant, and just represents noise - it doesn't indicate anything (except > that you are using `resize-windows'). It indicates just that (that you are using `resize-windows' at the moment). You might for example leave the computer for a while and come back. Isn't it good then to know that you are using `resize-windows'? You may have forgotten, but Emacs knows - and behaves a bit differently ;-) > Sorry, I don't understand, again. Changing the mode line of the selected > window is not needed to simply show that the window is selected - you > already change the window background to show that. Those two are alternatives that you can turn on/off with two defcustoms. > No, you said that you didn't know, and you thought that fringe was not > window-specific - but it is, AFAIK. You are right. > What is the impossibility you see? Changing the colors of one of the fringes in a window. >> You have more freedom with the mouse pointer. > > I don't know what freedom I have with it, You can position the mouse pointer wherever you want. > but the mouse pointer is a bad > idea. It is either unnoticeable (if you aren't currently using the mouse) or > it is plain wrong (if you are using the mouse). As I said in the portion you are replying to here I do not think that is wrong to use the mouse pointer to give feedback when you are working from the keyboard. That is the way the window manager in w32 sometimes does it. (It does exactly that when resizing a window from the keyboard.) Of course one can have different opinions wheter this is good or bad, but "plain wrong" is a bit to strong here in my taste. > Help in a separate frame does not tamper with the window layout. It is a good point and I have already said that if it is desireable I could add support for it. It is however not quite as simple as one might expect in this case. > If you maximize all windows, then you will certainly have difficulty > implementing and testing a command for resizing windows. ;-) ;-) >>> Please use (with-output-to-temp-buffer "*Help*"...) or >>> equivalent. It will solve the problem. >> You always do that with the normal help functions. > > I don't know what that means. The above problems (popup frame, self-insert > keys, `q' etc.) should be solved if you just use that form. The *Help* > buffer should then be in help-mode. I am afraid that you might be misunderstanding the problem here. What I have been trying to do is to temporary show the help and after this return to resizing for those people that do not normally use popup frames for help. At the moment I have not taken care of popup help. I can do that if it is desireable, but it requires some careful thought about how to do it in this case. You are welcome with suggestions. (In fact I hoped that you would have some thoughts about this.) But please then try to answer the following questions: - When showing help in a popup frame the popup frame should of course not be in a resizing state. Should resizing be resumed when quitting help? - If yes how should that be indicated to the user? - If no, when should resizing be resumed? >> = fit-window-to-buffer-works >> - shrink-window-if-larger-than-buffer > > I don't know. I'm unfamiliar with those commands. I only know that the > behavior I see doesn't correspond to anything I can make sense of or find > useful (in the cases I mentioned). If the functions you use don't do what's > right for this context, then you might want to use something else. I decided to give the user the choice (= fit, - shrink). >> C-g should quit window resizing and go back to the configuration you >> started with. > > Yes, it should. Thanks. > emacs -Q > (setq pop-up-frames t) > M-x resize-windows > 3 2 3 2 > C-g > > Bam! > > I used the last version you had posted before my reply: 0.94. Please try the latest version instead. > That responds to what you just wrote. Why not have a standard way to exit > and stick to it? No problem. I actually wanted some feedback on this. The current way try to mimick how isearch exits, but that might be a bad choice in this case. > `mouse-1' is the usual binding for `mouse-set-point'. That should be fine. Thanks. > See Bastien's code. There is no mixing. There are two possible modes. The > default mode is border movement. The alternate mode is window resizing. It > should be the other way around: simple as default, complex as alternate; > gross tuning as default, fine-tuning as alternate. Unfortunately I think it is (or rather was) utterly confusing for more complex window layouts even though the intention to simply was nice. (For simple layouts it was fine.) > My main suggestions are (1) simplify the UI, and (2) find a good way to > indicate which border is active (for border movement). (1) can't be done without (2) here. The problem is really that it is hard to find a good way to do (2). That was what I tried to explain from the beginning. Coloring the relevant vertical border or fringe would IMO opinion be the best solution. (An additional possibility is to change the mouse pointer shape, but that is a lot of work.)