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 09:33:47 -0700 Message-ID: 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="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276448322 385 80.91.229.12 (13 Jun 2010 16:58:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Jun 2010 16:58:42 +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 18:58:40 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 1ONqW8-0001VM-5N for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 18:58:40 +0200 Original-Received: from localhost ([127.0.0.1]:37480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONqW7-0008Fp-AC for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 12:58:39 -0400 Original-Received: from [140.186.70.92] (port=36291 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONqVv-0008DE-OD for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 12:58:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONqVt-00081o-VZ for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 12:58:27 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60718) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONqVt-00081j-Sw for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 12:58:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ONqAE-0005xc-0Q; Sun, 13 Jun 2010 12:36:02 -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 16:36: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.127644695922905 (code B ref 6385); Sun, 13 Jun 2010 16:36:01 +0000 Original-Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 16:35:59 +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 1ONqAA-0005xO-Qs for submit@debbugs.gnu.org; Sun, 13 Jun 2010 12:35:59 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONqA8-0005xI-Ee for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 12:35:57 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DGZncB016845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Jun 2010 16:35:50 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DGZmhu025674; Sun, 13 Jun 2010 16:35:48 GMT Original-Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 320932781276446835; Sun, 13 Jun 2010 09:33:55 -0700 Original-Received: from dradamslap1 (/10.175.241.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 09:33:54 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4C14EC69.5000608@gmx.at> Thread-Index: AcsLBYQldLvrr0icSOGRovaGUGE6dwADC18A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090208.4C1508E7.00AB: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 12:36: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:37744 Archived-At: > > There doesn't seem to be a problem before Emacs 23. Maybe > > there is a problem, theoretically, but I haven't > > encountered one. What about returning to the pre-23 code? > > 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. 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. 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? > > What are your thoughts about let-binding > > `min-window-height'? What are the cases > > where that won't fix the problem? > > Let-binding `window-min-height' (I suppose that's the variable you mean) Yes, that's the variable I meant. > can be used to make a window less than `window-min-height' > high. Doing this can eventually cause the deletion of that > window after the binding has been exited. Obviously, if it is only that binding that prevents its deletion, then when the binding is no longer in effect nothing will prevent its deletion. As I said, I'm interested in the context of a popup window such as *Completions*. I want that window to fit its buffer as much as possible, but without deleting any other windows. Such a window has limited lifespan; when it is deleted the other windows will naturally reclaim the space, and the variable will no longer be bound (e.g. to 1). 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? That was my question. I wondered if this was always the case or if there were some cases where it did not hold. > This is not a speciality of `fit-window-to-buffer' but > a consequence of the fact that Emacs can delete windows that > are smaller than `window-min-height' high. It is the prevention that I'm interested in. Whether the code causing the problem is in `fit-window-to-buffer' itself or elsewhere is not very important to me. The problem manifests itself for me when I use `fit-window-to-buffer'. It might also manifest itself for others in other contexts (dunno), but it is `fit-window-to-buffer' that is, in effect, problematic for me (in Emacs 23+). So my question still is: if `window-min-height' is 1, then is deletion (due to enlarging or shrinking another window) always prevented? 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.