From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12419: Mouse click changes layout Date: Fri, 14 Sep 2012 09:18:04 -0700 Message-ID: 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> <1455E2776C3F46FCB324B5562F718569@us.oracle.com> <5053485E.70801@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347639554 2842 80.91.229.3 (14 Sep 2012 16:19:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2012 16:19:14 +0000 (UTC) Cc: occitan@esperanto.org, 12419@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 14 18:19:17 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 1TCYbq-0003pf-Us for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Sep 2012 18:19:15 +0200 Original-Received: from localhost ([::1]:40913 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCYbn-0004Vg-2K for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Sep 2012 12:19:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCYbh-0004VH-II for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 12:19:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCYbg-00014T-99 for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 12:19:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCYbg-00014P-6F for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 12:19:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TCYcc-0004ph-1x for bug-gnu-emacs@gnu.org; Fri, 14 Sep 2012 12:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Sep 2012 16:20: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.134763955518503 (code B ref 12419); Fri, 14 Sep 2012 16:20:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 14 Sep 2012 16:19:15 +0000 Original-Received: from localhost ([127.0.0.1]:34025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCYbq-0004oO-KF for submit@debbugs.gnu.org; Fri, 14 Sep 2012 12:19:15 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:48182) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCYbn-0004oG-Sg for 12419@debbugs.gnu.org; Fri, 14 Sep 2012 12:19:12 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8EGIAcb009744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Sep 2012 16:18:11 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8EGI9xF027939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2012 16:18:10 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8EGI97h005301; Fri, 14 Sep 2012 11:18:09 -0500 Original-Received: from dradamslap1 (/10.159.182.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Sep 2012 09:18:08 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5053485E.70801@gmx.at> Thread-Index: Ac2SispAFrmR1esESISuHDVebgu1wwAB6PHg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:64294 Archived-At: > >> When dragging a divider, windows are resized asymmetrically, > >> that is we enlarge only the window we drag away from and > >> shrink the windows on the other side. > > > > That sounds normal, but what is the alternative - how > > could it be otherwise? > > That all windows on the other side get resized proportionally. How is that different from "shrink the windows on the other side"? I'm guessing that shrink them, but not proportionately? > >> Asymmetric resizing is not reversible, that is, dragging the > >> divider back by the same amount will not necessarily reproduce the > >> inital configuration. > > > > I don't think that is what I see. But I guess I don't > > understand what you're saying. Can you give an example, > > and contrast what happens in earlier Emacs releases? > > Try with three windows above each other and drag one > modeline until both windows in the direction you drag to > are at their minimum height. Then drag the divider back. > The outermost window is not sized back. I see. In previous releases when you drag one mode line, only the adjacent window shrinks. And that corresponds exactly (AFAICT) to the opposite action of dragging the mode line back again. So previously the opposite drag action was symmetric to the initial drag action. Now it is not. Can we (and then should we) make this change in behavior optional (for the user)? > Now set `resize-mini-windows' to nil and drag the bottom modeline. > All windows get resized proportionally in both directions. Not with a standalone minibuffer frame. At least I see no change in behavior, whatever the value of `resize-mini-windows'. > In Emacs 23.3 automatically resizing the minibuffer resizes the lowest > window first. That's what people want. But IIRC this > doesn't work with `resize-mini-windows' t and `resize-mini-windows' > nil doesn't work when the lowest window is at its minimum height. OK, thanks for the explanation. Consider proposing something for emacs-devel to discuss. Was the change in behavior from Emacs 23 to 24 (the change made so far) ever discussed? Personally I don't care much, since I don't split windows that much. But this sounds like something that affects lots of users, and perhaps there should be some discussion about it.