From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1291: 23.0.60; 1) resize-mini-windows: customizable, 2) if grow mini, grow Completions Date: Sun, 2 Nov 2008 12:27:02 -0800 Message-ID: <008701c93d29$5dbc3a20$0200a8c0@us.oracle.com> References: <005b01c93c80$436e6ac0$0200a8c0@us.oracle.com> <490DB544.9000003@gmx.at> <007201c93cfd$5d33d440$0200a8c0@us.oracle.com> <490DEE1F.1090700@gmx.at> <008101c93d1d$fc93a450$0200a8c0@us.oracle.com> <490E035D.3050104@gmx.at> Reply-To: Drew Adams , 1291@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1225659024 15303 80.91.229.12 (2 Nov 2008 20:50:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2008 20:50:24 +0000 (UTC) Cc: 1291@emacsbugs.donarmstrong.com To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 21:51:26 2008 connect(): Connection refused Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kwjuv-0001Mb-5R for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2008 21:51:25 +0100 Original-Received: from localhost ([127.0.0.1]:57137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kwjto-0005zN-3w for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2008 15:50:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kwjtk-0005yv-Gx for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2008 15:50:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kwjti-0005yQ-P4 for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2008 15:50:12 -0500 Original-Received: from [199.232.76.173] (port=51796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kwjti-0005yJ-IU for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2008 15:50:10 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:51572) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kwjth-00005z-Qh for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2008 15:50:10 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mA2Ko4iA025117; Sun, 2 Nov 2008 12:50:04 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id mA2KZ31P021432; Sun, 2 Nov 2008 12:35:03 -0800 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 02 Nov 2008 20:35:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1291 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1291-submit@emacsbugs.donarmstrong.com id=B1291.122565763720132 (code B ref 1291); Sun, 02 Nov 2008 20:35:03 +0000 Original-Received: (at 1291) by emacsbugs.donarmstrong.com; 2 Nov 2008 20:27:17 +0000 Original-Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mA2KREvf020126 for <1291@emacsbugs.donarmstrong.com>; Sun, 2 Nov 2008 12:27:15 -0800 Original-Received: from rgminet15.oracle.com (mail-router.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA2KQp5Q022083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Nov 2008 20:26:52 GMT Original-Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA2KQg8w030335; Sun, 2 Nov 2008 20:26:43 GMT Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 Nov 2008 20:26:39 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <490E035D.3050104@gmx.at> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Ack9JDOQa5SWeyfDSyq8Q3+JC8vFtQAARlMw X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.490E0D01.01C5:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sun, 02 Nov 2008 15:50:12 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:22106 Archived-At: > From: martin rudalics Sent: Sunday, November 02, 2008 11:46 AM > > The problem is not that the *Completions* window is not > > fit properly by Electric-pop-up-window - it is. The problem > > is that after fitting it the minibuffer expansion reduces > > the *Completions* window. It should not. > > There's nothing special about the *Completions* window once > it has been handled by `fit-window-to-buffer', so resizing the > minibuffer won't care about it specially. It should care about it specially. There _is_ something special about *Completions* wrt the minibuffer. The only reason for *Completions* to exist during minibuffer completion is to serve the minibuffer - it is made for the minibuffer. And the minibuffer should play well with *Completions* during minibuffer completion. They should work hand in hand. If our treatment of the minibuffer is ignoring *Completions* and whatever we do to benefit *Completions* display, such as make its window fit the current (minibuffer) completions, then something is wrong with our treatment of the minibuffer. It is a mistake to think that the minibuffer and *Completions* should be treated independently, should be treated as just any old buffers and windows. They are not independent during minibuffer completion; they belong together. Both of them are special, in several respects. That is not to say that the minibuffer display can never override whatever is decided for the *Completions* display, but it should not do so gratuitously. It should take the *Completions* display into account. > > There ought to be a way to respect the *Completions* > > window size that we go to the trouble of creating by > > calling `fit-window-to-buffer'. > > We could fix the window's height (but I don't want to think of the > complaints). So maybe, we should provide additional values for > `window-size-fixed' like 'lax-height and 'lax-weight thus Emacs > would try to shrink some other window first. I don't really follow that (I'm not familiar with `window-size-fixed'), and I can't necessarily speak to how this should be implemented in any case. I'm just reporting a (minor) bug. But I don't think this should be fixed in some general way, treating the *Completions* or minibuffer window in the same way as any other window. If that's what you're suggesting wrt `window-size-fixed', then I think that's probably not the best approach. These are somewhat special windows/buffers - they should be dealt with together (during minibuffer completion). This is a particular problem for minibuffer completion, I think, not a problem for windows in general or even other windows whenever the minibuffer is active. Minibuffer + *Completions* is a special case. To me, it doesn't make sense for Peter to resize the *Completions* window and Paul to then resize the minibuffer without taking into account what Peter has just tried to do. If Paul takes Peter's intention and action into account and then overrides Peter's action according to some more important consideration, that's OK. But Paul should not just ignore Peter's good work.