From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jun 2010 19:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 6385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 6385@debbugs.gnu.org X-Debbugs-Original-To: Emacs Bugs Received: via spool by submit@debbugs.gnu.org id=B.127611024511774 (code B ref -1); Wed, 09 Jun 2010 19:05:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Jun 2010 19:04:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQZI-00033r-Oy for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:04:05 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQYF-000339-B5 for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:04:03 -0400 Received: from lists.gnu.org ([199.232.76.165]:57758) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OMQY4-0006cT-2l for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:02:48 -0400 Received: from [140.186.70.92] (port=52189 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMQXy-0007tG-MS for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMQXe-0006ta-8q for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:23 -0400 Received: from mail-yw0-f187.google.com ([209.85.211.187]:43045) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQXe-0006tR-1d for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:22 -0400 Received: by ywh17 with SMTP id 17so1330526ywh.1 for ; Wed, 09 Jun 2010 12:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=cNYg/gvBs38agYKCxW7DZlvUcMkH5G7eUpztxgVzzIs=; b=CEnh+3ajv4x9xgObt7Qw3QZWJorw8Vkr7suY1E32MYp0Q88RlR26sOIKCK16bCaCuz E0+Rvb5XS30jsjH9JnR15l4865GnO67rZbTaiyPenVOhwwjjrJDsZTW2egod/cpU950+ uID1whdBtHWR9JE+SPs7FGYlF/N3g/W8AQfZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fQh0sw0a7qdO1E2Ti63kBqQe/3BWxBHo/TYlZwLSTvmq0NpU5R/QHEOKuizuJLXJOx Z1WgwTwSNaJMQVx60uS7iBHwV8I4fvzS8p+JTIT8a1OK1fmuhZiPcmjUp53TyMOcj8sE lrvYJreldSfkiFR6avgzXVKQHLGPURlqpQqeI= Received: by 10.101.5.40 with SMTP id h40mr2567827ani.133.1276109832955; Wed, 09 Jun 2010 11:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Wed, 9 Jun 2010 11:56:51 -0700 (PDT) From: Lennart Borgman Date: Wed, 9 Jun 2010 20:56:51 +0200 Message-ID: Content-Type: multipart/mixed; boundary=001636c5c01149a85e04889d7937 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.6 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.6 (----) --001636c5c01149a85e04889d7937 Content-Type: text/plain; charset=UTF-8 I believe fit-window-to-buffer has become a bit upset and unnecessary aggressive because of visual lines. It looks like it need a bit more feedback from the display system to be really sure that the buffer is entirely visible. The attached patch is something I have used to get around the problem. I am not sure it is the right thing but I am rather sure it does not hurt. Too see the problem it tries to fix just call the function with a buffer larger than window and point below the window bottom (you have to write a bit elisp code for that). Of course we need a non-killing version of fit-window-to-buffer, but for the moment this patch might be useful. --001636c5c01149a85e04889d7937 Content-Type: text/x-patch; charset=US-ASCII; name="windows-less-aggressive-fit-1.diff" Content-Disposition: attachment; filename="windows-less-aggressive-fit-1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga8is68f0 PT09IG1vZGlmaWVkIGZpbGUgJ2xpc3Avd2luZG93LmVsJw0KLS0tIHRydW5rL2xpc3Avd2luZG93 LmVsCTIwMTAtMDYtMDcgMTg6Mjg6MDIgKzAwMDANCisrKyBwYXRjaGVkL2xpc3Avd2luZG93LmVs CTIwMTAtMDYtMDkgMTg6NDg6MzcgKzAwMDANCkBAIC0xNTAyLDEwICsxNTAyLDEyIEBADQogCQkJ ICAgICAoZm9yd2FyZC1saW5lIDApKQ0KIAkJCSAgIChwb2ludCkpKSkNCiAJCShzZXQtd2luZG93 LXZzY3JvbGwgd2luZG93IDApDQorICAgICAgICAgICAgICAgIChyZWRpc3BsYXkgdCkNCiAJCSh3 aGlsZSAoYW5kICg8IGRlc2lyZWQtaGVpZ2h0IG1heC1oZWlnaHQpDQogCQkJICAgICg9IGRlc2ly ZWQtaGVpZ2h0ICh3aW5kb3ctaGVpZ2h0KSkNCiAJCQkgICAgKG5vdCAocG9zLXZpc2libGUtaW4t d2luZG93LXAgZW5kKSkpDQogCQkgIChlbmxhcmdlLXdpbmRvdyAxKQ0KKyAgICAgICAgICAgICAg ICAgIChyZWRpc3BsYXkgdCkNCiAJCSAgKHNldHEgZGVzaXJlZC1oZWlnaHQgKDErIGRlc2lyZWQt aGVpZ2h0KSkpKQ0KIAkgICAgICA7OyBSZXR1cm4gbm9uLW5pbCBvbmx5IGlmIG5vdGhpbmcgImJh ZCIgaGFwcGVuZWQuDQogCSAgICAgIChzZXRxIHZhbHVlIHQpKSkNCg0K --001636c5c01149a85e04889d7937-- From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Fri, 11 Jun 2010 13: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: To: Lennart Borgman Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127626247728238 (code B ref 6385); Fri, 11 Jun 2010 13:22:01 +0000 Received: (at 6385) by debbugs.gnu.org; 11 Jun 2010 13:21:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON4Af-0007LP-Gt for submit@debbugs.gnu.org; Fri, 11 Jun 2010 09:21:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ON4Ac-0007LI-KS for 6385@debbugs.gnu.org; Fri, 11 Jun 2010 09:21:16 -0400 Received: (qmail invoked by alias); 11 Jun 2010 13:21:08 -0000 Received: from 62-47-33-63.adsl.highway.telekom.at (EHLO [62.47.33.63]) [62.47.33.63] by mail.gmx.net (mp066) with SMTP; 11 Jun 2010 15:21:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19r2uAX899rSmqjS9WN3XOK9yvuLNG54lFMw2/fHs b/monI1B9nobhE Message-ID: <4C12383E.5030405@gmx.at> Date: Fri, 11 Jun 2010 15:21:02 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.4 (--) > I believe fit-window-to-buffer has become a bit upset and unnecessary > aggressive because of visual lines. It looks like it need a bit more > feedback from the display system to be really sure that the buffer is > entirely visible. > > The attached patch is something I have used to get around the problem. > I am not sure it is the right thing but I am rather sure it does not > hurt. IIUC your change defeats the whole point of `pos-visible-in-window-p', namely to calculate a position without doing a redisplay. Worse even, you might end up doing multiple redisplays within a loop. TRT would be to handle the various line cases within `pos_visible_p'. And obviously get rid of resizing windows within a loop. > Of course we need a non-killing version of fit-window-to-buffer, but > for the moment this patch might be useful. What is a "non-killing version of fit-window-to-buffer"? martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2010 17:16: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: To: martin rudalics Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12762765542656 (code B ref 6385); Fri, 11 Jun 2010 17:16:02 +0000 Received: (at 6385) by debbugs.gnu.org; 11 Jun 2010 17:15:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON7pi-0000gn-9g for submit@debbugs.gnu.org; Fri, 11 Jun 2010 13:15:54 -0400 Received: from mail-yw0-f197.google.com ([209.85.211.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON7pg-0000gi-8v for 6385@debbugs.gnu.org; Fri, 11 Jun 2010 13:15:52 -0400 Received: by ywh35 with SMTP id 35so1159668ywh.29 for <6385@debbugs.gnu.org>; Fri, 11 Jun 2010 10:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=VaXEgD++jQljCHng3afkPzlA/Jx7iti4GE2Z90OKFTo=; b=UDRJx+D2TcCxV1X6LQWQ2W3iVZVj7cgz047f2YfuIfGXMni0puhY7p0FEl/ALmIFl7 l0Uf5vbawUvy/IVG4x3frfmK0QZqybD7kgyJs4URiJDmQuby4Ew+9avg5x/IoSI3uHfR 4e1GGnwyBbSpHswa+r7oZhoLEq2EQbEd8m1bA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=IbB3pBHjIUTt9PFvFxL9MT8tB7sEBC2B1z51dUboDAIDtVsEyrFgxTtkU3wV51rDyj Ceg0wYfBwMjjoQfv8OJWGNHXsne2R4J3WQzkcTc/9MlLC2kIo6LtCLAHIrTpDsCHLWru /WnbARQz+T+QEgouiRoJY3roSew3yxrITbf6o= Received: by 10.101.182.2 with SMTP id j2mr1942828anp.210.1276276545137; Fri, 11 Jun 2010 10:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Fri, 11 Jun 2010 10:15:25 -0700 (PDT) In-Reply-To: <4C12383E.5030405@gmx.at> References: <4C12383E.5030405@gmx.at> From: Lennart Borgman Date: Fri, 11 Jun 2010 19:15:25 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Fri, Jun 11, 2010 at 3:21 PM, martin rudalics wrote: >> I believe fit-window-to-buffer has become a bit upset and unnecessary >> aggressive because of visual lines. It looks like it need a bit more >> feedback from the display system to be really sure that the buffer is >> entirely visible. >> >> The attached patch is something I have used to get around the problem. >> I am not sure it is the right thing but I am rather sure it does not >> hurt. > > IIUC your change defeats the whole point of `pos-visible-in-window-p', > namely to calculate a position without doing a redisplay. Yes, I know. I hoped someone had a better idea long term idea. Doing a redisplay is just a quick fix. What I saw was the even 2 lines high buffer made fit-window-to-buffer delete sibling windows. All the time - but... I thought I knew how to reproduce it. So I did not write any test procedures, I was just a bit irritated. A mistake. > Worse even, > you might end up doing multiple redisplays within a loop. Yes, I know. Maybe the first redisplay was all that was needed. > TRT would be to handle the various line cases within `pos_visible_p'. Thanks, I will leave this for the moment, but keep it in mind. > And obviously get rid of resizing windows within a loop. > >> Of course we need a non-killing version of fit-window-to-buffer, but >> for the moment this patch might be useful. > > What is a "non-killing version of fit-window-to-buffer"? This function killed all other siblings even if it just actually needs two lines if certain conditions are met. (Those I tried to describe.) So this was just a desperate attempt to stop that. I do not know what to do at the moment. I will try to reproduce this and look a bit closer at it later. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Sat, 12 Jun 2010 08:02: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: To: Lennart Borgman Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127632966827045 (code B ref 6385); Sat, 12 Jun 2010 08:02:01 +0000 Received: (at 6385) by debbugs.gnu.org; 12 Jun 2010 08:01:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONLeO-00072A-HM for submit@debbugs.gnu.org; Sat, 12 Jun 2010 04:01:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONLeM-00071o-20 for 6385@debbugs.gnu.org; Sat, 12 Jun 2010 04:01:07 -0400 Received: (qmail invoked by alias); 12 Jun 2010 08:01:01 -0000 Received: from 62-47-40-208.adsl.highway.telekom.at (EHLO [62.47.40.208]) [62.47.40.208] by mail.gmx.net (mp020) with SMTP; 12 Jun 2010 10:01:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/7YNRHgE/7tL5SXivHYVnAyQvm+q/QXtUXzegaDy pVlCy33iWiwp8g Message-ID: <4C133EBB.5090702@gmx.at> Date: Sat, 12 Jun 2010 10:00:59 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > What I saw was the even 2 lines high buffer made fit-window-to-buffer > delete sibling windows. All the time - but... I thought I knew how to > reproduce it. So I did not write any test procedures, I was just a bit > irritated. A mistake. [...] > This function killed all other siblings even if it just actually needs > two lines if certain conditions are met. (Those I tried to describe.) > > So this was just a desperate attempt to stop that. I do not know what > to do at the moment. I will try to reproduce this and look a bit > closer at it later. Deleting other windows when resizing was a misguided feature. I don't do that any more for quite some time and didn't miss it yet ;-) In any case, the issue whether a position is visible in a window is a priori not related to the issue whether resizing is allowed to delete any windows. You patch might handle a few cases, accidentally ... martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Jun 2010 13:04: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: To: martin rudalics Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12763478315547 (code B ref 6385); Sat, 12 Jun 2010 13:04:02 +0000 Received: (at 6385) by debbugs.gnu.org; 12 Jun 2010 13:03:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONQNK-0001RQ-Bk for submit@debbugs.gnu.org; Sat, 12 Jun 2010 09:03:50 -0400 Received: from mail-yw0-f197.google.com ([209.85.211.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONQNI-0001RI-45 for 6385@debbugs.gnu.org; Sat, 12 Jun 2010 09:03:48 -0400 Received: by ywh35 with SMTP id 35so1976317ywh.29 for <6385@debbugs.gnu.org>; Sat, 12 Jun 2010 06:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sm+nEO8VyNHXRSa79O2ZG1WpahxZJZ0t+QAdgzqoplY=; b=W+tZItl0rmvq/Of6JkCwgGuI8Z8hXoc+dR6MeQzkHJiPX/wNMrIiIDGgCyY6FnLk3s sl2Ll83YX/XPbxtG6tk+iaC8G/kV6H30QssRsbG22mCOGpt+nqBNVJXluAripf3ctHhj y2xEf3epJHCdr/4kNnFRY4Oo81MaJx6ITvaco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LKSQu9OHmomGh88PZ9FFKCF7hz8X+98BAeRO6T2Icx5ddSsP/eBE0RWIR9Ve1MgwpU HlKh+0v+fx5PdN6iYL/kZFkCRrBA/KpM0ZKy4+/1YjdCoThIAg43PMvD3ufqXYG5SkSq D4+WH+YAlXW9peYsXKkaTGlUFd4ub8j22jXcg= Received: by 10.100.245.35 with SMTP id s35mr2825560anh.71.1276347822263; Sat, 12 Jun 2010 06:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Sat, 12 Jun 2010 06:03:22 -0700 (PDT) In-Reply-To: <4C133EBB.5090702@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> From: Lennart Borgman Date: Sat, 12 Jun 2010 15:03:22 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Sat, Jun 12, 2010 at 10:00 AM, martin rudalics wrote: >> What I saw was the even =C2=A02 lines high buffer made fit-window-to-buf= fer >> delete sibling windows. All the time - but... I thought I knew how to >> reproduce it. So I did not write any test procedures, I was just a bit >> irritated. A mistake. > [...] >> This function killed all other siblings even if it just actually needs >> two lines if certain conditions are met. (Those I tried to describe.) >> >> So this was just a desperate attempt to stop that. I do not know what >> to do at the moment. I will try to reproduce this and look a bit >> closer at it later. > > Deleting other windows when resizing was a misguided feature. =C2=A0I don= 't > do that any more for quite some time and didn't miss it yet ;-) Did you rewrite fit-window-to-buffer or do you have another function for th= is? > In any case, the issue whether a position is visible in a window is a > priori not related to the issue whether resizing is allowed to delete > any windows. =C2=A0You patch might handle a few cases, accidentally ... Yes, but what it handled was that it prevented a window to grow over the buffers size. But I do not know why the window grow bigger than the buffer. It is just that after it happened to me ten times or so I throw in this quick fix - and hoped that you had something more to say about it. If I just had calmed down a bit and investigated it instead... ;-) From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Sat, 12 Jun 2010 14:17: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: To: Lennart Borgman Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12763521967536 (code B ref 6385); Sat, 12 Jun 2010 14:17:01 +0000 Received: (at 6385) by debbugs.gnu.org; 12 Jun 2010 14:16:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONRVj-0001xV-Sn for submit@debbugs.gnu.org; Sat, 12 Jun 2010 10:16:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONRVh-0001xM-5k for 6385@debbugs.gnu.org; Sat, 12 Jun 2010 10:16:34 -0400 Received: (qmail invoked by alias); 12 Jun 2010 14:16:26 -0000 Received: from 62-47-60-120.adsl.highway.telekom.at (EHLO [62.47.60.120]) [62.47.60.120] by mail.gmx.net (mp054) with SMTP; 12 Jun 2010 16:16:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19gEAkiYVFgbAgu9S0k7Q+PVrqN3PVKi67ya/kXVp L7qv5R6XAD5C8G Message-ID: <4C1396B9.6080705@gmx.at> Date: Sat, 12 Jun 2010 16:16:25 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> Deleting other windows when resizing was a misguided feature. I don't >> do that any more for quite some time and didn't miss it yet ;-) > > Did you rewrite fit-window-to-buffer or do you have another function for this? I wrote my own windows resizing functions mostly in Elisp. > Yes, but what it handled was that it prevented a window to grow over > the buffers size. If your concern is that enlarging the window of a temporary buffer can delete other windows then doing what you propose would handle just a few cases. > But I do not know why the window grow bigger than the buffer. The while loop at the end of `fit-window-to-buffer' is not sane. Here I still have it wrapped in a `condition-case' because in some pathological cases it can throw an error. martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Jun 2010 14:25: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: To: martin rudalics Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12763526947767 (code B ref 6385); Sat, 12 Jun 2010 14:25:02 +0000 Received: (at 6385) by debbugs.gnu.org; 12 Jun 2010 14:24:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONRdk-00021E-FI for submit@debbugs.gnu.org; Sat, 12 Jun 2010 10:24:54 -0400 Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONRdi-000217-SE for 6385@debbugs.gnu.org; Sat, 12 Jun 2010 10:24:51 -0400 Received: by gwj16 with SMTP id 16so1557313gwj.3 for <6385@debbugs.gnu.org>; Sat, 12 Jun 2010 07:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/EehAMe6NDGFXg07zwQNJYBbOp69sGYDe3wb9zFe+hs=; b=g8urKFVgMzUGuK32QMrGiAWPhK2tDXroKi8FZW8mFTDX3vTtblhxfq+e6IgmsGw2am EUO9KnnLoGBanyk8HT+6x+tjis5Vhysu6BPPgqFOI2l95m99vHrqPMnC6PRoEaXkejPa zYwVUmLIEJNPsfYfiP6uLFxjNEjUxHj/rp1rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RuKwN9v2F2VfFkeb2AxC3b0UhLo9Ks9hDUGGzLw5xkceWjs2o68uqB2WPiW41JQ92N tvCR1T69tpklDy1KMm9fYRDZjyRXIeK/IrgG9INxfnoOOhKT/LJ/2nHdpRz75Wshgak5 CnR0fqcoFRGWziLqQLY91KV6lJt+GQdzbeCMQ= Received: by 10.101.191.4 with SMTP id t4mr2909086anp.214.1276352685599; Sat, 12 Jun 2010 07:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Sat, 12 Jun 2010 07:24:25 -0700 (PDT) In-Reply-To: <4C1396B9.6080705@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C1396B9.6080705@gmx.at> From: Lennart Borgman Date: Sat, 12 Jun 2010 16:24:25 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On Sat, Jun 12, 2010 at 4:16 PM, martin rudalics wrote: >>> Deleting other windows when resizing was a misguided feature. =C2=A0I d= on't >>> do that any more for quite some time and didn't miss it yet ;-) >> >> Did you rewrite fit-window-to-buffer or do you have another function for >> this? > > I wrote my own windows resizing functions mostly in Elisp. > >> Yes, but what it handled was that it prevented a window to grow over >> the buffers size. > > If your concern is that enlarging the window of a temporary buffer can > delete other windows then doing what you propose would handle just a few > cases. > >> But I do not know why the window grow bigger than the buffer. > > The while loop at the end of `fit-window-to-buffer' is not sane. =C2=A0He= re I > still have it wrapped in a `condition-case' because in some pathological > cases it can throw an error. Can't we just throw in a better code instead of fit-window-to-buffer? (And rename fit-window-to-buffer to killing-window-fit-to-buffer if someone really wants it.) It does not have to be perfect. Just good enough. We can surely make it better later if we need to. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Sat, 12 Jun 2010 15:23: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: To: "'martin rudalics'" , "'Lennart Borgman'" Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12763561779432 (code B ref 6385); Sat, 12 Jun 2010 15:23:02 +0000 Received: (at 6385) by debbugs.gnu.org; 12 Jun 2010 15:22:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONSXw-0002S5-8A for submit@debbugs.gnu.org; Sat, 12 Jun 2010 11:22:56 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONSXu-0002Rx-BP for 6385@debbugs.gnu.org; Sat, 12 Jun 2010 11:22:54 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CFMlVf025545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 15:22:48 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5C29E8E017506; Sat, 12 Jun 2010 15:22:46 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 341274441276356062; Sat, 12 Jun 2010 08:21:02 -0700 Received: from dradamslap1 (/141.144.64.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 08:21:01 -0700 From: "Drew Adams" References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> Date: Sat, 12 Jun 2010 08:21:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C133EBB.5090702@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsKCT3rREUXkFq+Q8OAPMM3DFR11QAJ8IIQ X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C13A649.000B:SCFMA922111,ss=1,fgs=0 X-Spam-Score: -6.2 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > Deleting other windows when resizing was a misguided feature. I'm very glad to hear you say that, sincerely. > I don't do that any more for quite some time and didn't > miss it yet ;-) FWIW, I still see it happening in: GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-06-07 on 3249CTO 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. Is there a simple way to prevent deletion of other windows when using `fit-window-to-buffer'? So far, I've just been let-binding `min-window-height' to 1 around the call. Other suggestions welcome. The use case of wanting to show as much of a buffer as possible without deleting other windows in the frame, and also shrinking the window to the buffer size when it can all be shown, has got to be a common use case. Also, for the same type of buffer/window (typically a pop-up window such as *Completions*), it would be good to have a simple way to make scrolling not show half a window of blank space after the buffer text, when you scroll near the buffer bottom. IOW, be able to have the end of the buffer act similarly to the beginning: not have the window go beyond eob. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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 07:52: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: To: Lennart Borgman Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12764155045879 (code B ref 6385); Sun, 13 Jun 2010 07:52:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 07:51:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONhyq-0001Wm-8r for submit@debbugs.gnu.org; Sun, 13 Jun 2010 03:51:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONhym-0001Wg-MF for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 03:51:42 -0400 Received: (qmail invoked by alias); 13 Jun 2010 07:51:36 -0000 Received: from 62-47-39-237.adsl.highway.telekom.at (EHLO [62.47.39.237]) [62.47.39.237] by mail.gmx.net (mp032) with SMTP; 13 Jun 2010 09:51:36 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/CL3sjh3PC43PpW9Q840GyQSAtY5d9e4K/bAHfW7 r0O23taP5ugFfO Message-ID: <4C148E06.2040308@gmx.at> Date: Sun, 13 Jun 2010 09:51:34 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C1396B9.6080705@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Can't we just throw in a better code instead of fit-window-to-buffer? > (And rename fit-window-to-buffer to killing-window-fit-to-buffer if > someone really wants it.) > > It does not have to be perfect. Just good enough. We can surely make > it better later if we need to. I suppose there's no need for a `killing-window-fit-to-buffer'. Writing a non-killing one with Emacs 23 means can be done in a number of ways: (1) Use `adjust-window-trailing-edge'. IIRC that's what you already did when you wrote your window balancing algorithm so you know how to do that. (2) Save the window configuration and the number of windows around the `enlarge-window' call in `fit-window-to-buffer' and restore the configuration when a window got deleted. That's more or less what `adjust-window-trailing-edge' does internally. (3) Adjust enlarge_window so it doesn't delete windows. Since I don't understand enlarge_window any more I can't give you advice on (3). If you want to try (1) or (2) ask me if you encounter problems. martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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 07:52: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: To: Drew Adams Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.12764155085890 (code B ref 6385); Sun, 13 Jun 2010 07:52:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 07:51:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONhyu-0001Ww-5N for submit@debbugs.gnu.org; Sun, 13 Jun 2010 03:51:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONhys-0001Wh-7c for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 03:51:46 -0400 Received: (qmail invoked by alias); 13 Jun 2010 07:51:41 -0000 Received: from 62-47-39-237.adsl.highway.telekom.at (EHLO [62.47.39.237]) [62.47.39.237] by mail.gmx.net (mp018) with SMTP; 13 Jun 2010 09:51:41 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1834m8xECM3ZiUZXxg+MIRkxIxVuPUe7/hcRQSVgo U0Eidf2ixyFBLr Message-ID: <4C148E0C.7000201@gmx.at> Date: Sun, 13 Jun 2010 09:51:40 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Is there a simple way to prevent deletion of other windows when using > `fit-window-to-buffer'? So far, I've just been let-binding `min-window-height' > to 1 around the call. Other suggestions welcome. 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. martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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 12:41: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: To: "'martin rudalics'" Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127643280915896 (code B ref 6385); Sun, 13 Jun 2010 12:41:01 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 12:40:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONmTw-00048L-P9 for submit@debbugs.gnu.org; Sun, 13 Jun 2010 08:40:09 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONmTv-000483-71 for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 08:40:07 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DCdxw4005040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Jun 2010 12:40:01 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5DBcLo2010364; Sun, 13 Jun 2010 12:39:59 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 342089211276432764; Sun, 13 Jun 2010 05:39:24 -0700 Received: from dradamslap1 (/10.175.241.236) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 05:39:23 -0700 From: "Drew Adams" References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> Date: Sun, 13 Jun 2010 05:39:26 -0700 Message-ID: <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4C148E0C.7000201@gmx.at> Thread-Index: AcsKzUTbSA3RZGPcQMWRqCJnxaRmawAJ8/6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090207.4C14D1A1.011F:SCFMA922111,ss=1,fgs=0 X-Spam-Score: -6.2 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > Is there a simple way to prevent deletion of other windows > > when using `fit-window-to-buffer'? So far, I've just been > > let-binding `min-window-height' to 1 around the call. > > Other suggestions welcome. > > 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. 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? What are your thoughts about let-binding `min-window-height'? What are the cases where that won't fix the problem? Thx. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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 14:35: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: To: Drew Adams Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127643966819500 (code B ref 6385); Sun, 13 Jun 2010 14:35:01 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 14:34:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONoGZ-00054T-WC for submit@debbugs.gnu.org; Sun, 13 Jun 2010 10:34:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONoGX-00054N-EA for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 10:34:27 -0400 Received: (qmail invoked by alias); 13 Jun 2010 14:34:19 -0000 Received: from 62-47-32-13.adsl.highway.telekom.at (EHLO [62.47.32.13]) [62.47.32.13] by mail.gmx.net (mp072) with SMTP; 13 Jun 2010 16:34:19 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+sfzErhuOsv4S8nApTxGVqMLRdhlipQ41/UMHCmh DfQ2nZqFJc6NgK Message-ID: <4C14EC69.5000608@gmx.at> Date: Sun, 13 Jun 2010 16:34:17 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> In-Reply-To: <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 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. > 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) 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. 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. martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman 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 15:21: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: To: martin rudalics Cc: 6385@debbugs.gnu.org, Drew Adams Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127644243820850 (code B ref 6385); Sun, 13 Jun 2010 15:21:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 15:20:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONozG-0005QF-5b for submit@debbugs.gnu.org; Sun, 13 Jun 2010 11:20:38 -0400 Received: from mail-yw0-f197.google.com ([209.85.211.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONozD-0005QA-DR for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 11:20:35 -0400 Received: by ywh35 with SMTP id 35so2602926ywh.29 for <6385@debbugs.gnu.org>; Sun, 13 Jun 2010 08:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=4+VX6FATdJXJkRfGT/oCmz1GUokcad5LUEyvAj2utiY=; b=Fxs39lNQmHxnl2RHWdn6YSIBWoa8wN6PVA0XeAcWsun1Gv70Zkrfpn3bsqX3cikFMo v6QllG8wFLr4RKeLXwIe64YIUf7SAgc+eB1uSzQn0MtsHo9I7bMElQtg3k0bBGIHE1Xg kgr85YgxzCafpcyMmtdlYvFCiBoona9MtfFHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=a7O4zOBR267mba0V6AW4z5cahVGFtNKZAlJJoJ+k8ajaFjJU/mdUxIRkscO2LfUfNr 6QBLp9O4rMkO6vgPxBhyL2xIx4/WufK3zXZXjIFhEWQwmyCcjK4jNbdQJiXUGcNFIHbI 7VXGruSWNhBQTy3O8hUaT1S59d5qRlQHCad3s= Received: by 10.101.160.30 with SMTP id m30mr3760821ano.192.1276442430297; Sun, 13 Jun 2010 08:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Sun, 13 Jun 2010 08:20:09 -0700 (PDT) In-Reply-To: <4C14EC69.5000608@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> From: Lennart Borgman Date: Sun, 13 Jun 2010 17:20:09 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Sun, Jun 13, 2010 at 4:34 PM, martin rudalics wrote: > > Please post a recipe for reproducing the problem. =C2=A0I never had any > problem with this in practice so I can't tell. > >> What are your thoughts about let-binding `min-window-height'? What are t= he >> cases >> where that won't fix the problem? > > Let-binding `window-min-height' (I suppose that's the variable you mean) > can be used to make a window less than `window-min-height' high. =C2=A0Do= ing > this can eventually cause the deletion of that window after the binding > has been exited. =C2=A0This 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. I am currently let-binding window-min-height to something smaller than window-min-height, but I have never seen any problem because of that. I think it is very practical to be able to do let-bind window-min-height this way. I can look at the code of course and found out, but where is is possible deleting of small height windows done? Is there a thought behind it or is it a bug? From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman 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 15:25: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: To: martin rudalics Cc: 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127644266020965 (code B ref 6385); Sun, 13 Jun 2010 15:25:01 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 15:24:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONp2p-0005S6-49 for submit@debbugs.gnu.org; Sun, 13 Jun 2010 11:24:20 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONp2m-0005Rz-AO for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 11:24:16 -0400 Received: by gyh4 with SMTP id 4so2019452gyh.3 for <6385@debbugs.gnu.org>; Sun, 13 Jun 2010 08:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Jljfzr8L4IsushgrCFmvEKhXv5OTjyPr/EVvFv4ZeMQ=; b=a/qLtKDE9CdPk51m1y2pO9wtn2TiLDpb0tIunkssUcN5o7DDmySuv52YkBu0VVwT2T euLodAWfVBEJ77qUhyoLU0e4oaQiWFuvt+/TC3VlW7RA2AzPHGDeDYIARaMPuHKEXYpJ B8QCafD+UTADdH9YftzAk0GW0fN0qaPoM/KJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cwsVk6+5GnxliRkJT/ovKfhbuit+u+u8dXR3PkPGpcaGm0uygnXCMJauhpAMorIWKq mUEY0inz3WcSuWgGMA5i+sc/9D77E8CgY8EFveF9eSrQVaJCLNyYD4HCh1cJ+D3jM3Lf VJkjupG7aWEITPvtpZTsh92jvX+M0ZmfFYTT8= Received: by 10.101.132.15 with SMTP id j15mr3663484ann.124.1276442651114; Sun, 13 Jun 2010 08:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Sun, 13 Jun 2010 08:23:51 -0700 (PDT) In-Reply-To: <4C148E06.2040308@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C1396B9.6080705@gmx.at> <4C148E06.2040308@gmx.at> From: Lennart Borgman Date: Sun, 13 Jun 2010 17:23:51 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Sun, Jun 13, 2010 at 9:51 AM, martin rudalics wrote: >> Can't we just throw in a better code instead of fit-window-to-buffer? >> (And rename fit-window-to-buffer to killing-window-fit-to-buffer if >> someone really wants it.) >> >> It does not have to be perfect. Just good enough. We can surely make >> it better later if we need to. > > I suppose there's no need for a `killing-window-fit-to-buffer'. =C2=A0Wri= ting > a non-killing one with Emacs 23 means can be done in a number of ways: > > (1) Use `adjust-window-trailing-edge'. =C2=A0IIRC that's what you already= did > =C2=A0 =C2=A0when you wrote your window balancing algorithm so you know h= ow to do > =C2=A0 =C2=A0that. > > (2) Save the window configuration and the number of windows around the > =C2=A0 =C2=A0`enlarge-window' call in `fit-window-to-buffer' and restore = the > =C2=A0 =C2=A0configuration when a window got deleted. =C2=A0That's more o= r less what > =C2=A0 =C2=A0`adjust-window-trailing-edge' does internally. > > (3) Adjust enlarge_window so it doesn't delete windows. > > Since I don't understand enlarge_window any more I can't give you advice > on (3). =C2=A0If you want to try (1) or (2) ask me if you encounter probl= ems. Thanks. Writing the code is probably not a big problem, keeping another patch in my patched Emacs is. So I will write a new version and send it here. (I wonder if I had not written it already and threw it away to avoid keeping another patch.) From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: To: "'martin rudalics'" Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127644695922905 (code B ref 6385); Sun, 13 Jun 2010 16:36:01 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 16:35:59 +0000 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 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 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 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 Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 320932781276446835; Sun, 13 Jun 2010 09:33:55 -0700 Received: from dradamslap1 (/10.175.241.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 09:33:54 -0700 From: "Drew Adams" References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> Date: Sun, 13 Jun 2010 09:33:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -4.9 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > 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. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: To: Lennart Borgman Cc: 6385@debbugs.gnu.org, Drew Adams Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645111424906 (code B ref 6385); Sun, 13 Jun 2010 17:46:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 17:45:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONrFC-0006Te-0h for submit@debbugs.gnu.org; Sun, 13 Jun 2010 13:45:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONrF9-0006TV-CK for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 13:45:12 -0400 Received: (qmail invoked by alias); 13 Jun 2010 17:45:04 -0000 Received: from 62-47-51-219.adsl.highway.telekom.at (EHLO [62.47.51.219]) [62.47.51.219] by mail.gmx.net (mp061) with SMTP; 13 Jun 2010 19:45:04 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18CgT8Wf2sCNebScq/8F85ektdCyEv+8samKEJB59 f/vtq8Qeu3om/h Message-ID: <4C15191A.50009@gmx.at> Date: Sun, 13 Jun 2010 19:44:58 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > I think it is very practical to be able to do let-bind > window-min-height this way. I can look at the code of course and found > out, but where is is possible deleting of small height windows done? With the first call to delete_window in enlarge_window. This deletes the argument window if its new size is less than `window-min-height'. And size_window calls delete_window on any window whose size has become too small when (virtually) resizing a parent window back to its original size. > Is there a thought behind it or is it a bug? The thought behind it was probably that anyone who wants to enlarge a window also accepts that other windows may get deleted in the process. I suppose "collateral damage" has become the terminus technicus for such behavior. martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: To: Drew Adams Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645111824920 (code B ref 6385); Sun, 13 Jun 2010 17:46:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 17:45:18 +0000 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 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 Received: (qmail invoked by alias); 13 Jun 2010 17:45:10 -0000 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 Message-ID: <4C151921.3090903@gmx.at> Date: Sun, 13 Jun 2010 19:45:05 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> 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 From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Lennart Borgman 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:49: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: To: martin rudalics Cc: 6385@debbugs.gnu.org, Drew Adams Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645134025018 (code B ref 6385); Sun, 13 Jun 2010 17:49:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 17:49:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONrIp-0006VT-U7 for submit@debbugs.gnu.org; Sun, 13 Jun 2010 13:49:00 -0400 Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONrIo-0006VO-4q for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 13:48:58 -0400 Received: by gwj16 with SMTP id 16so2076762gwj.3 for <6385@debbugs.gnu.org>; Sun, 13 Jun 2010 10:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sUpjQyJPSnE3W41wXJ+UchQzlbhs/vNqB3larBF1J6Q=; b=JO3T9iNj2vsMh6uPapCs4IQ1ty3jkFcEbwRDBJiScHIiUs7H8pyYhdjObMvSzygf+Q rG1tL18S7fwm3H7SXWaNENINZlcT8HXiCQtS5NqV+hIV/hNdlWnWdA8XTjcHOwfFobbc d+dJS5eKD6KniTagXQxYXfphv9yG+LBU8QZro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EarAz47h++oTf3KW6D3KwJ3iw3MqncyyTP7QS1xEqF4rmyfmfGT4LQ09fIWoZyvqIZ RFkVcs+75uj5KfcOBSK+c/09hcontOwwIUe5QSELTCFgsYKiqwThAP0nRzqdgoJ++mYy 5ms50VbFADAHewz4LnW65nFYNQjVjZg3xT2ws= Received: by 10.101.11.20 with SMTP id o20mr3839241ani.4.1276451333179; Sun, 13 Jun 2010 10:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Sun, 13 Jun 2010 10:48:33 -0700 (PDT) In-Reply-To: <4C15191A.50009@gmx.at> References: <4C12383E.5030405@gmx.at> <4C133EBB.5090702@gmx.at> <4C148E0C.7000201@gmx.at> <7F2242DF262349D8A22BB9285AAADE85@us.oracle.com> <4C14EC69.5000608@gmx.at> <4C15191A.50009@gmx.at> From: Lennart Borgman Date: Sun, 13 Jun 2010 19:48:33 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On Sun, Jun 13, 2010 at 7:44 PM, martin rudalics wrote: >> I think it is very practical to be able to do let-bind >> window-min-height this way. I can look at the code of course and found >> out, but where is is possible deleting of small height windows done? > > With the first call to delete_window in enlarge_window. =C2=A0This delete= s > the argument window if its new size is less than `window-min-height'. > And size_window calls delete_window on any window whose size has become > too small when (virtually) resizing a parent window back to its original > size. Thanks. >> Is there a thought behind it or is it a bug? > > The thought behind it was probably that anyone who wants to enlarge a > window also accepts that other windows may get deleted in the process. > I suppose "collateral damage" has become the terminus technicus for such > behavior. ;-) Is there consensus that we should get rid of this kind deleting of windows with height less than window-min-height? From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: To: "'martin rudalics'" Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645329426049 (code B ref 6385); Sun, 13 Jun 2010 18:22:01 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 18:21:34 +0000 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 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 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 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 Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 321005671276453277; Sun, 13 Jun 2010 11:21:17 -0700 Received: from dradamslap1 (/10.175.241.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 11:21:17 -0700 From: "Drew Adams" 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> Date: Sun, 13 Jun 2010 11:21:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -6.2 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > >> 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. From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer Resent-From: Stefan Monnier 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 20:06: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: To: "Drew Adams" Cc: 'martin rudalics' , 6385@debbugs.gnu.org Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127645950529065 (code B ref 6385); Sun, 13 Jun 2010 20:06:02 +0000 Received: (at 6385) by debbugs.gnu.org; 13 Jun 2010 20:05:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONtQW-0007Yj-M5 for submit@debbugs.gnu.org; Sun, 13 Jun 2010 16:05:04 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONtQU-0007YM-VQ for 6385@debbugs.gnu.org; Sun, 13 Jun 2010 16:05:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFPWFExMCoQR/2dsb2JhbACed3K9doUaBI0C X-IronPort-AV: E=Sophos;i="4.53,411,1272859200"; d="scan'208";a="67958074" Received: from 76-10-132-17.dsl.teksavvy.com (HELO pastel.home) ([76.10.132.17]) by ironport2-out.pppoe.ca with ESMTP; 13 Jun 2010 16:04:58 -0400 Received: by pastel.home (Postfix, from userid 20848) id D3EDE80BC; Sun, 13 Jun 2010 16:04:57 -0400 (EDT) From: Stefan Monnier 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> Date: Sun, 13 Jun 2010 16:04:57 -0400 In-Reply-To: (Drew Adams's message of "Sun, 13 Jun 2010 11:21:11 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.2 (--) > "Allow deleting windows less than this tall.... > Emacs honors settings of this variable when enlarging > or shrinking windows vertically." [...] >> 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? If you read the above docstring carefully, you'll see that it doesn't say "don't make windows smaller than that" but just that if a window gets smaller it'll be deleted. I do think it's a misfeature, but it's not one that's trivial to fix. IIUC Martin has worked on a fix, but he hasn't submitted it yet, so I guess it's not quite ready for prime time. Stefan From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Mon, 14 Jun 2010 06:51: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: To: Drew Adams Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127649821014642 (code B ref 6385); Mon, 14 Jun 2010 06:51:02 +0000 Received: (at 6385) by debbugs.gnu.org; 14 Jun 2010 06:50:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO3Uo-0003o7-Hz for submit@debbugs.gnu.org; Mon, 14 Jun 2010 02:50:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OO3Ul-0003nm-Le for 6385@debbugs.gnu.org; Mon, 14 Jun 2010 02:50:09 -0400 Received: (qmail invoked by alias); 14 Jun 2010 06:50:02 -0000 Received: from 62-47-63-155.adsl.highway.telekom.at (EHLO [62.47.63.155]) [62.47.63.155] by mail.gmx.net (mp007) with SMTP; 14 Jun 2010 08:50:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+yMcxxQReykVQ+LWsJeqJsK0zpJWl7jm7pn+vOxT I/lsQ8uDxX/A42 Message-ID: <4C15D117.4020203@gmx.at> Date: Mon, 14 Jun 2010 08:49:59 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 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. So far I don't have the slightest idea what "the problem" is. I don't even know which window gets deleted: The one showing the buffer whose window shall be fit (in which case it would be interesting to know whether the window shall be shrunk or enlarged), or another 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. > > That sounds like a bug - it contradicts the doc. Why shouldn't enlargement be > prevented instead, in that case? It's prevented in `adjust-window-trailing-edge'. For `enlarge-window' there's no such rule. The latter's doc-string clearly states: "This function can delete windows if they get too small." martin From unknown Fri Aug 15 16:18:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6385: A slightly less aggressive fit-window-to-buffer 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: Mon, 14 Jun 2010 06:58: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: To: "'martin rudalics'" Cc: 6385@debbugs.gnu.org, 'Lennart Borgman' Received: via spool by 6385-submit@debbugs.gnu.org id=B6385.127649866414832 (code B ref 6385); Mon, 14 Jun 2010 06:58:02 +0000 Received: (at 6385) by debbugs.gnu.org; 14 Jun 2010 06:57:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO3c7-0003rB-Q5 for submit@debbugs.gnu.org; Mon, 14 Jun 2010 02:57:44 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO3c6-0003r6-GH for 6385@debbugs.gnu.org; Mon, 14 Jun 2010 02:57:43 -0400 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 o5E6vag9017721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jun 2010 06:57:38 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5E6vZXZ008342; Mon, 14 Jun 2010 06:57:36 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 321772861276498653; Sun, 13 Jun 2010 23:57:33 -0700 Received: from dradamslap1 (/141.144.224.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jun 2010 23:57:33 -0700 From: "Drew Adams" 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> <4C15D117.4020203@gmx.at> Date: Sun, 13 Jun 2010 23:57:07 -0700 Message-ID: <8487E05A2D9D4FE28731964A960F901E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C15D117.4020203@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsLjdJ+1FCKqOxXTKmtbkMAxm0ZAQAAHB5Q X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090204.4C15D2E2.00FF:SCFMA4539811,ss=1,fgs=0 X-Spam-Score: -6.2 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > which window gets deleted: The one showing the buffer whose > window shall be fit (in which case it would be interesting to know > whether the window shall be shrunk or enlarged), or another window. I thought I made it clear that another window is deleted from the window being fit: "I want that window to fit its buffer as much as possible, but without deleting any other windows." From unknown Fri Aug 15 16:18:38 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Lennart Borgman Subject: bug#6385: closed (Re: A slightly less aggressive fit-window-to-buffer) Message-ID: References: <4E940CD5.5070800@gmx.at> X-Gnu-PR-Message: they-closed 6385 X-Gnu-PR-Package: emacs Reply-To: 6385@debbugs.gnu.org Date: Tue, 11 Oct 2011 09:32:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1318325522-32254-1" This is a multi-part message in MIME format... ------------=_1318325522-32254-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #6385: A slightly less aggressive fit-window-to-buffer which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 6385@debbugs.gnu.org. --=20 6385: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D6385 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1318325522-32254-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 6385-done) by debbugs.gnu.org; 11 Oct 2011 09:31:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RDYgM-0008NL-Lj for submit@debbugs.gnu.org; Tue, 11 Oct 2011 05:31:31 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RDYgK-0008N7-Bv for 6385-done@debbugs.gnu.org; Tue, 11 Oct 2011 05:31:29 -0400 Received: (qmail invoked by alias); 11 Oct 2011 09:31:02 -0000 Received: from 62-47-40-241.adsl.highway.telekom.at (EHLO [62.47.40.241]) [62.47.40.241] by mail.gmx.net (mp061) with SMTP; 11 Oct 2011 11:31:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+c62ZHLWOcM3A4o6QLxjXLCZ8d23UIH5OTHKNi9U 4jVn5WkSSqse7R Message-ID: <4E940CD5.5070800@gmx.at> Date: Tue, 11 Oct 2011 11:31:01 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6385-done@debbugs.gnu.org Subject: Re: A slightly less aggressive fit-window-to-buffer Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 6385-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Of course we need a non-killing version of fit-window-to-buffer, but > for the moment this patch might be useful. `fit-window-to-buffer' doesn't kill windows any more so this issue should have been resolved. martin ------------=_1318325522-32254-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Jun 2010 19:04:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQZI-00033r-Oy for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:04:05 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQYF-000339-B5 for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:04:03 -0400 Received: from lists.gnu.org ([199.232.76.165]:57758) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OMQY4-0006cT-2l for submit@debbugs.gnu.org; Wed, 09 Jun 2010 15:02:48 -0400 Received: from [140.186.70.92] (port=52189 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMQXy-0007tG-MS for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMQXe-0006ta-8q for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:23 -0400 Received: from mail-yw0-f187.google.com ([209.85.211.187]:43045) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMQXe-0006tR-1d for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 15:02:22 -0400 Received: by ywh17 with SMTP id 17so1330526ywh.1 for ; Wed, 09 Jun 2010 12:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=cNYg/gvBs38agYKCxW7DZlvUcMkH5G7eUpztxgVzzIs=; b=CEnh+3ajv4x9xgObt7Qw3QZWJorw8Vkr7suY1E32MYp0Q88RlR26sOIKCK16bCaCuz E0+Rvb5XS30jsjH9JnR15l4865GnO67rZbTaiyPenVOhwwjjrJDsZTW2egod/cpU950+ uID1whdBtHWR9JE+SPs7FGYlF/N3g/W8AQfZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fQh0sw0a7qdO1E2Ti63kBqQe/3BWxBHo/TYlZwLSTvmq0NpU5R/QHEOKuizuJLXJOx Z1WgwTwSNaJMQVx60uS7iBHwV8I4fvzS8p+JTIT8a1OK1fmuhZiPcmjUp53TyMOcj8sE lrvYJreldSfkiFR6avgzXVKQHLGPURlqpQqeI= Received: by 10.101.5.40 with SMTP id h40mr2567827ani.133.1276109832955; Wed, 09 Jun 2010 11:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.15 with HTTP; Wed, 9 Jun 2010 11:56:51 -0700 (PDT) From: Lennart Borgman Date: Wed, 9 Jun 2010 20:56:51 +0200 Message-ID: Subject: A slightly less aggressive fit-window-to-buffer To: Emacs Bugs Content-Type: multipart/mixed; boundary=001636c5c01149a85e04889d7937 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.6 (----) --001636c5c01149a85e04889d7937 Content-Type: text/plain; charset=UTF-8 I believe fit-window-to-buffer has become a bit upset and unnecessary aggressive because of visual lines. It looks like it need a bit more feedback from the display system to be really sure that the buffer is entirely visible. The attached patch is something I have used to get around the problem. I am not sure it is the right thing but I am rather sure it does not hurt. Too see the problem it tries to fix just call the function with a buffer larger than window and point below the window bottom (you have to write a bit elisp code for that). Of course we need a non-killing version of fit-window-to-buffer, but for the moment this patch might be useful. --001636c5c01149a85e04889d7937 Content-Type: text/x-patch; charset=US-ASCII; name="windows-less-aggressive-fit-1.diff" Content-Disposition: attachment; filename="windows-less-aggressive-fit-1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga8is68f0 PT09IG1vZGlmaWVkIGZpbGUgJ2xpc3Avd2luZG93LmVsJw0KLS0tIHRydW5rL2xpc3Avd2luZG93 LmVsCTIwMTAtMDYtMDcgMTg6Mjg6MDIgKzAwMDANCisrKyBwYXRjaGVkL2xpc3Avd2luZG93LmVs CTIwMTAtMDYtMDkgMTg6NDg6MzcgKzAwMDANCkBAIC0xNTAyLDEwICsxNTAyLDEyIEBADQogCQkJ ICAgICAoZm9yd2FyZC1saW5lIDApKQ0KIAkJCSAgIChwb2ludCkpKSkNCiAJCShzZXQtd2luZG93 LXZzY3JvbGwgd2luZG93IDApDQorICAgICAgICAgICAgICAgIChyZWRpc3BsYXkgdCkNCiAJCSh3 aGlsZSAoYW5kICg8IGRlc2lyZWQtaGVpZ2h0IG1heC1oZWlnaHQpDQogCQkJICAgICg9IGRlc2ly ZWQtaGVpZ2h0ICh3aW5kb3ctaGVpZ2h0KSkNCiAJCQkgICAgKG5vdCAocG9zLXZpc2libGUtaW4t d2luZG93LXAgZW5kKSkpDQogCQkgIChlbmxhcmdlLXdpbmRvdyAxKQ0KKyAgICAgICAgICAgICAg ICAgIChyZWRpc3BsYXkgdCkNCiAJCSAgKHNldHEgZGVzaXJlZC1oZWlnaHQgKDErIGRlc2lyZWQt aGVpZ2h0KSkpKQ0KIAkgICAgICA7OyBSZXR1cm4gbm9uLW5pbCBvbmx5IGlmIG5vdGhpbmcgImJh ZCIgaGFwcGVuZWQuDQogCSAgICAgIChzZXRxIHZhbHVlIHQpKSkNCg0K --001636c5c01149a85e04889d7937-- ------------=_1318325522-32254-1--