From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command Date: Wed, 23 Mar 2016 09:09:05 +0100 Message-ID: <56F24F21.4040107@gmx.at> References: <87fuviigpw.fsf@gmail.com> <83k2ku4bb5.fsf@gnu.org> <8737riibq2.fsf@gmail.com> <837fgu49m1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458720622 32753 80.91.229.3 (23 Mar 2016 08:10:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 08:10:22 +0000 (UTC) Cc: 23092@debbugs.gnu.org To: Eli Zaretskii , "N. Jackson" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 23 09:10:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aidrl-0005v2-Eu for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 09:10:09 +0100 Original-Received: from localhost ([::1]:41760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aidrk-0002dV-Bd for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 04:10:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aidrh-0002cL-5D for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 04:10:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aidrd-0006QD-UW for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 04:10:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aidrd-0006Q9-Qt for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 04:10:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aidrd-0006CQ-Lq for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 04:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Mar 2016 08:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23092 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23092-submit@debbugs.gnu.org id=B23092.145872056223762 (code B ref 23092); Wed, 23 Mar 2016 08:10:01 +0000 Original-Received: (at 23092) by debbugs.gnu.org; 23 Mar 2016 08:09:22 +0000 Original-Received: from localhost ([127.0.0.1]:60740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aidqz-0006BC-Od for submit@debbugs.gnu.org; Wed, 23 Mar 2016 04:09:21 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:52036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aidqy-0006B0-HE for 23092@debbugs.gnu.org; Wed, 23 Mar 2016 04:09:20 -0400 Original-Received: from [192.168.1.102] ([212.95.7.7]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MVNDK-1aGYsQ1nFW-00YliT; Wed, 23 Mar 2016 09:09:12 +0100 In-Reply-To: <837fgu49m1.fsf@gnu.org> X-Provags-ID: V03:K0:syG7lc9CNrJoTBA+YZI6/mZvWmbPn20SNGGsQbAlR7PLp1kZaxv HpN9DCAWvBlQvyAWZEuY4bLEyb92eeDz9RMWGx5UTiw83/OjygGz03ylEZ9mQGLh7nQA3Xv /BVW1DZd/kq+GMRzBhUN/a58qdfp9b5Tpkj5YtITZwETT0i5VVfpWnXtfq0BId7JbnZ2sH3 ihjGICZr7mGSXt1rsLZrg== X-UI-Out-Filterresults: notjunk:1;V01:K0:uhH8j8wo850=:whNQ9U7bWxOoZkS5leRXyz PNhaPk6z9oL7iJrmSL8ZU7l62+yizeVWHT60d9pBXoyp+BX1iCBUrlx56IiAt4kyl0l7RwlZz C0OIZydiKmUTWP999+D7ZsZ9JQYO7ERlpQ7968zuq3JsJ1HRDJq/1JXe7GZtrnAIP2+ivzSfu cN5Z0+q0kopBaBfRT1g/yzRRkDpHphkpWT0Ya5HzpppmH2prDRPLGJ6Hdk6mkxn0TnyxKi7s/ dE2vyefMCdiGeapCCfdPV3FL+f80SYQKXRE0udHCt+/Cp1AY6+myq46h96+6YkKV9LiGtVoAi yG+S8o1Yxo4cMBzquGdYau4BVMrwtYy44+aa+GvKGdjZ7XsqADYRSfuGDLE+c6Aujpd2Wz6pn vDNlB1vGcdM+bkBKzP8GsWx/wTkRes/k0pFTGqO8jJZYMNKuArdsn/qozfm291Tmpq3w4CghO b+/mITEfCEF0BW64oCsoZruN7MylI8GylMZq+z9jtugXgu/WsTI8pkO//WyPlo7T/x4Xrmyax BRos+tYgLdr5+WovnqonVUZ+cZ6uLH57ZtL2bj0+xacOYecSShsRwlTzvE++nzRt+wBrEnp4O +apEzU9m8f4c6THBpMRu33uubqdv6JeBS1x+ruRarZl4s6v+lFd47XNmJ9CizYu2lC3Thiefi aTl931gY93Mw/AaPMchbgQrWeg0IYT5+bRR68ySdR2QxXmQL2SoNnbxwepmUP/AKgS3smgB/l J8hWRAeMDO1TtzTDQQICA1SvH9hTl1/1Qe7500E1BgKp0Vv7kwrOV4KnCLB6u2VNMLGVtX4h X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115380 Archived-At: >> However, it's interesting that with the recipe reversed, the completi= ons >> window _does_ get resized.: >> >> src/emacs -Q >> >> C-x C-f ; find-file >> lib/s TAB ; A largish completions window is shown. >> v TAB ; Completions window shrinks. >> >> So it seems that the existing implementation has logic in it for >> resizing the completions window to fit the completions but it just is= n't >> working quite right. Unless the design is that the completions window= >> can only be "shrunk" but not "grown". > > I'm sure Martin will be able to explain this ;-) I never worked in this area but will try to do my best ;-) The behavior is due to the following form in =E2=80=98minibuffer-completion-help=E2=80= =99: ,(if temp-buffer-resize-mode '(window-height . resize-temp-buffer-window) '(window-height . shrink-window-if-larger-than-buffer)) The first branch of the =E2=80=98if=E2=80=99 means that if =E2=80=98temp-= buffer-resize-mode=E2=80=99 is enabled, this function will always try to fit the window to the buffer. The second branch means that if =E2=80=98temp-buffer-resize-mode=E2=80=99= is not enabled, the window may only shrink to occupy less space. Obviously, the second branch is based on the assumption that a user will "refine" her completions in the sense that she starts with a large number of possible completions and, by typing characters in the minibuffer, reduces the number of possible completions until she found the right one. Apparently, the OP works in the opposite direction - he starts with few suggestions and removes characters from the minibuffer ending up with more and more suggestions. martin