From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#12419: Mouse click changes layout Date: Fri, 14 Sep 2012 21:14:13 +0200 Message-ID: <50538205.1040900@gmx.at> References: <504FB55D.5030405@t-online.de> <5050432C.4060203@gmx.at> <5052450F.8030001@t-online.de> <5052F242.4060303@gmx.at> <83a9wsvqk6.fsf@gnu.org> <50533344.2030000@gmx.at> <831ui4veny.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347650121 29675 80.91.229.3 (14 Sep 2012 19:15:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2012 19:15:21 +0000 (UTC) Cc: occitan@esperanto.org, 12419@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 14 21:15:23 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TCbMC-00073q-Hw for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Sep 2012 21:15:16 +0200 Original-Received: from localhost ([::1]:43763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCbM8-00061Y-Jr for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Sep 2012 15:15:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCbM1-0005ty-CH for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 15:15:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCbM0-00059V-2d for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 15:15:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCbLz-00058i-Vw for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 15:15:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TCbMw-0001RU-6x for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 15:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Sep 2012 19:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12419-submit@debbugs.gnu.org id=B12419.13476501245485 (code B ref 12419); Fri, 14 Sep 2012 19:16:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 14 Sep 2012 19:15:24 +0000 Original-Received: from localhost ([127.0.0.1]:34168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCbMK-0001QP-80 for submit@debbugs.gnu.org; Fri, 14 Sep 2012 15:15:24 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:59296) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TCbMH-0001QH-1E for 12419@debbugs.gnu.org; Fri, 14 Sep 2012 15:15:22 -0400 Original-Received: (qmail invoked by alias); 14 Sep 2012 19:14:21 -0000 Original-Received: from 62-47-60-224.adsl.highway.telekom.at (EHLO [62.47.60.224]) [62.47.60.224] by mail.gmx.net (mp072) with SMTP; 14 Sep 2012 21:14:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/pScIDEKfpxZZv7YGLmSnjEpZoeLwBx04+UV1tGl mO7Mpx0wnzboT/ In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64306 Archived-At: >> Wouldn't using the "asymmetric" resizing do the job here? I don't >> think the symmetric variant is ever TRT when triggered by resizing the >> minibuffer window. > > I think asymmetric would be a better choice, indeed. > > IIUC the difference between "asymmetric" and the old "miniwindow-resize" > behavior is that if the lowest window needs to be shrunk below the > minimum height, the "miniwindow-resize" just gave up, whereas the > "asymmetric" will try to resize further windows. Asymmetric is what shrink_window_lowest_first did in Emacs 23. It could shrink all windows down to their safe minimum height. But there's no enlarge_window_lowest_first for the obvious reason. You can't undo the effect of shrink_window_lowest_first easily. So Emacs 23 saved the sizes of windows at the beginning of growing the minibuffer and restored them, if possible, when shrinking the minibuffer back. That's also why the default of `resize-mini-windows' is `grow-only'. You can't implement `t' with this method. And that's also why the echo area usually gets cleared and sized back immediately. > I think The Right Thing(tm) lies somewhere between the two: > - OT1H it's generally a good idea not to grow the miniwindow larger than > other windows), hence the old "miniwindow-resize". > - OTOH, if the window just above the minibuffer is a special tiny window > displaying some auxiliary-info, it sometimes makes sense to treat it > as a kind of "attachment to the modeline" and to resize the other > window instead. This is a case that must be handled. Anything else would be a regression. > So maybe tweaking the asymmetric behavior so it only resizes 1 window > (typically the window immediately above the modeline, but if that one > is marked window-size-fixed, then the one above) would be ideal. > > In the mean time, I suggest we try to use asymmetric. This would enlarge a one line window at the bottom of the frame whenever the minibuffer is shrunk back. Not a feasible option. What I have to do is to save the state (in the window structure to avoid the extra allocations) before growing the minibuffer and restore it (if the heights still match) when shrinking the minibuffer back. This is cumbersome but I see no other way. > PS: BTW, I've several times wished that when dragging modelines (and > vertical dividers), dragging them back would also bring back the other > dividers. I had implemented that initially. It's disconcerting (but I could make it optional easily). > OTOH, I haven't had the chance to use an Emacs that would > behave like that, so maybe if it did I'd often wish that the dividers > don't move back. Indeed. martin