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#6385: A slightly less aggressive fit-window-to-buffer Date: Sun, 13 Jun 2010 19:45:05 +0200 Message-ID: <4C151921.3090903@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> 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: dough.gmane.org 1276451924 11476 80.91.229.12 (13 Jun 2010 17:58:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Jun 2010 17:58:44 +0000 (UTC) Cc: 6385@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 13 19:58:42 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 1ONrSC-0005UW-7x for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 19:58:40 +0200 Original-Received: from localhost ([127.0.0.1]:34581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONrSB-0003Zl-8v for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 13:58:39 -0400 Original-Received: from [140.186.70.92] (port=57662 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONrS0-0003YS-VU for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 13:58:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONrRz-00080a-HZ for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 13:58:28 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59758) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONrRz-00080V-Dh for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 13:58:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ONrFy-0006UL-Ge; Sun, 13 Jun 2010 13:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics 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 17:46:02 +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.127645111824920 (code B ref 6385); Sun, 13 Jun 2010 17:46:02 +0000 Original-Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 17:45:18 +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 1ONrFG-0006Tt-9R for submit@debbugs.gnu.org; Sun, 13 Jun 2010 13:45:18 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONrFE-0006TY-Al for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 13:45:16 -0400 Original-Received: (qmail invoked by alias); 13 Jun 2010 17:45:10 -0000 Original-Received: from 62-47-51-219.adsl.highway.telekom.at (EHLO [62.47.51.219]) [62.47.51.219] by mail.gmx.net (mp044) with SMTP; 13 Jun 2010 19:45:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/0w55Avdf0N4NGymnIjpPZShVg63gg/7LI7XCTpw lzCl3F0apjZera User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 13 Jun 2010 13:46:02 -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:37748 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. 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. > I have not seen that problem arise in releases before Emacs 23, personally. The > code (e.g. for `fit-window-to-buffer') was changed considerably in Emacs 23. I > have supposed that at least part of that code change introduced this "misguided > feature". Perhaps I'm mistaken about that, but as I say, I do see no such > problem prior to Emacs 23. > > Were you involved with the code changes for this from Emacs 22 to 23? Did those > changes in fact introduce this "misguided feature", or was it already present? > > As I say, I myself see no such "misguided feature" manifest itself prior to 23. > Even if the "misguided feature" is theoretically present also before 23, in my > own, practical experience it shows up only with Emacs 23. I can answer these questions as soon as you tell me your 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 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. 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. > 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. martin