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: Sun, 28 Oct 2007 23:05:35 +0100 Message-ID: <472507AF.1080602@gmail.com> References: <87r6jfed61.fsf@bzg.ath.cx> <4724674B.1090404@gmail.com> <87d4uza1f0.fsf@bzg.ath.cx> <472470CD.8060806@gmail.com> <87sl3v2th3.fsf@bzg.ath.cx> <4724EF0A.8050909@gmail.com> <87fxzuud0x.fsf@bzg.ath.cx> 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 1193609173 20453 80.91.229.12 (28 Oct 2007 22:06:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2007 22:06:13 +0000 (UTC) Cc: emacs-devel To: Bastien Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 28 23:06:14 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 1ImGGf-00048R-Ql for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 23:06:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImGGW-0002Fp-Kf for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 18:05:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ImGGT-0002FT-IL for emacs-devel@gnu.org; Sun, 28 Oct 2007 18:05:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ImGGP-0002Ef-CW for emacs-devel@gnu.org; Sun, 28 Oct 2007 18:05:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImGGP-0002EZ-3i for emacs-devel@gnu.org; Sun, 28 Oct 2007 18:05:45 -0400 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 1ImGGO-0000i2-EZ for emacs-devel@gnu.org; Sun, 28 Oct 2007 18:05:44 -0400 Original-Received: from c83-254-148-228.bredband.comhem.se ([83.254.148.228]:61977 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1ImGGI-0006P7-5V; Sun, 28 Oct 2007 23:05:39 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 In-Reply-To: <87fxzuud0x.fsf@bzg.ath.cx> X-Antivirus: avast! (VPS 071028-0, 2007-10-28), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.148.228 X-Scan-Result: No virus found in message 1ImGGI-0006P7-5V. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1ImGGI-0006P7-5V 3516b12eb253086bd1042e2023bc4bf1 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:81996 Archived-At: Bastien wrote: > "Lennart Borgman (gmail)" writes: > >>> C-x + `balance-windows' >>> C-x ^ `enlarge-window' >> This is not well defined. There may be 4 different borders to move. > > It is well-defined: `enlarge-window' means implicitely enlarge-window > vertically (since enlarge-window-horizontally is a separate function). > > And having four borders in a window doesn't mean you can always act on > this four borders. Actually, in most of the cases, you can vertically > act on only one border, and horizontally act on only one border. > > This is why `enlarge-window' and `shrink-window' are well defined IMHO: > it's pretty rare to have a window with two movable vertical borders or > two movable horizontal borders. Yes, you are right in that the case where there is only one border to move is the most common. It makes sense to add code for that I think. >>> C-x - `shrink-window-if-larger-than-buffer' >> Same as above. > > Why? Please show me an example when it doesn't behave as the user would > expect. When the bottom border and top border both could be moved. >>> My point is precisely that C-x + is fine as it is. >> And mine is that resizing windows should not occupy more human memory >> and key binding space if possible. "C-x + +" is nearly as easy as "C-x >> +" to type. > > Don't get me wrong: I do think bw-interactive.el is useful when you need > to do complex resizing. But we more often need to do simple resizing so > simply adjusting the window size with the native keybindings is fine. > > And `C-x + +' uses more human memory than `C-x +', no? I believe human memory comes in chunks of three bytes ... ;-) >>> Again, it's more intuitive to me that C-x + increase the >>> vertical size of the window immediately. >> See above. You have to decide which border to act on first. > > But can't you make the arrow key be at the same time the decision > (resize from the left border) *and* the action (move left)? Would not that mean that the border might be moved in the wrong direction. > And drop the > action in case it has no sense in the current window configuration? Currently any key that makes no sense exits the minor mode. But maybe it is better to make the arrow keys give some message if the action is not possible. >> I tried to explain above. Is it clear now? (Or have I perhaps missed >> something?) > > Sorry but it's not clearer... any example would perhaps be useful. > Maybe I just miss something very obvious myself. I think I missed that the special case with just one border to move is the most common. Maybe that is where we miscommunicated?