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#6385: A slightly less aggressive fit-window-to-buffer Date: Sun, 13 Jun 2010 11:21:11 -0700 Message-ID: References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> <4C151921.3090903@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276453716 17327 80.91.229.12 (13 Jun 2010 18:28:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Jun 2010 18:28:36 +0000 (UTC) Cc: 6385@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 13 20:28:35 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ONrv8-0008Oj-Gk for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 20:28:35 +0200 Original-Received: from localhost ([127.0.0.1]:53795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONrv7-0001ch-7Y for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 14:28:33 -0400 Original-Received: from [140.186.70.92] (port=36791 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONrv1-0001cH-1Q for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 14:28:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONruz-0003Oy-Qq for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 14:28:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45046) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONruz-0003Ou-N5 for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 14:28:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ONron-0006mO-SK; Sun, 13 Jun 2010 14:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2010 18:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645329426049 (code B ref 6385); Sun, 13 Jun 2010 18:22:01 +0000 Original-Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 18:21:34 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONroM-0006m6-5e for submit@debbugs.gnu.org; Sun, 13 Jun 2010 14:21:34 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONroK-0006ly-6e for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 14:21:32 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DILPwp027785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Jun 2010 18:21:26 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DILNXo032503; Sun, 13 Jun 2010 18:21:24 GMT Original-Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 321005671276453277; Sun, 13 Jun 2010 11:21:17 -0700 Original-Received: from dradamslap1 (/10.175.241.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 11:21:17 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4C151921.3090903@gmx.at> Thread-Index: AcsLIC4SeMvct9m7TAu9Og7QA3fgxgAAsyyw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090201.4C1521A7.003F:SCFMA4539811,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 13 Jun 2010 14:22:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37749 Archived-At: > >> Please post a recipe for reproducing the problem. I never had any > >> problem with this in practice so I can't tell. > > > > Huh? You yourself said this: > > > >>> I don't know of a simple way to prevent deletion of > >>> windows when using `enlarge-window'. The problems with > >>> `fit-window-to-buffer' are just a special case of that. > > > > Any you said this: > > > >>>> Deleting other windows when resizing was a misguided feature. > > > > That "misguided feature" is precisely the problem. You > > recognize it, so you must have sufficient recipes to produce it. > > This "misguided feature" is in Emacs ever since I know it. I believe you. But I've never come across it before. > But you said that ... > > > And unfortunately, I need my code to work in multiple > > Emacs versions. It is only for Emacs 23 (.1 and .2 and more > > recent) that this is a problem - I do not see it happening > > before 23. So even if you might have a more recent version with > > a fix I will still need a workaround for use with Emacs 23. > > ... and that's what I want a recipe for: A reproducible problem that > does _not_ exist in prior Emacs versions. Sorry, I cannot take the time to try to pare things down to a single small case. Suffice it to say that I have never run into the problem before Emacs 23. In my case, this is about `fit-window-to-buffer' - that is where I see the problem. > > Also, if you have some private code that removes this > > "misguided feature", why does vanilla Emacs itself still suffer > > from it? Is your fix not applicable in general? Does it have > > a downside that prevents you from applying it to vanilla Emacs? > > Yes. It's a complete rewrite of window resizing in Elisp. > I hardly changed `fit-window-to-buffer', if at all. I guess you are saying that that prevents your applying it to Emacs. Or perhaps that you don't yet think it is ready for that. > > I guess you are confirming that, so long as the binding > > (e.g. to 1) is in effect, it will effectively always prevent > > window deletion? > > No. The let-binding just allows to make a window as small as one line > in the first place. But it does not prevent deleting a window. Hm. The doc indicates that windows with fewer lines will not be deleted. And a window cannot have fewer than 1 line (including the mode line). Perhaps the doc needs to be corrected. "Allow deleting windows less than this tall.... Emacs honors settings of this variable when enlarging or shrinking windows vertically." Admittedly, saying that it allows deleting windows less than this tall is not _exactly_ the same as saying that it disallows deleting windows taller than this. Still, the description strongly suggests something that is apparently untrue. > If you have a one line window and an nine lines window in a ten > lines frame and you want to enlarge the nine lines window by one > line Emacs 23 will probably delete the one line window. That sounds like a bug - it contradicts the doc. Why shouldn't enlargement be prevented instead, in that case? > > So my question still is: if `window-min-height' is 1, then > > is deletion (due to enlarging or shrinking another window) > > always prevented? > > No. > > > If not, what are the situations where such a binding is > > not enough to prevent deletion? And is there, for such > > situations, another good prevention recipe? > > > > I'm looking for good ways to deal practically with this > > "misguided feature" as it manifests itself in > > `fit-window-to-buffer'. Thx. > > You can try to replace calls to `enlarge-window' by (appropriately > configured) calls to `adjust-window-trailing-edge'. Look at > the window balancing code to see how that can be done. That's hardly what I would call a "good prevention recipe" or a "good way to deal with this practically". But thanks for the info. At least I now know that I'm not missing some simple solution.