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 19:53:59 +0100 Message-ID: <56F2E647.7040400@gmx.at> References: <87fuviigpw.fsf@gmail.com> <83k2ku4bb5.fsf@gnu.org> <8737riibq2.fsf@gmail.com> <837fgu49m1.fsf@gnu.org> <56F24F21.4040107@gmx.at> <878u19gn38.fsf@gmail.com> 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 1458759326 27783 80.91.229.3 (23 Mar 2016 18:55:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 18:55:26 +0000 (UTC) Cc: 23092@debbugs.gnu.org To: "N. Jackson" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 23 19:55:10 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 1ainvx-0007a2-Ns for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 19:55:09 +0100 Original-Received: from localhost ([::1]:45482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ainvx-0004QU-69 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 14:55:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ainvt-0004P1-Pg for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 14:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ainvq-0004IE-IB for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 14:55:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ainvq-0004I7-EP for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 14:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ainvq-00028K-2O for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 14:55:02 -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 18:55:02 +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.14587592578143 (code B ref 23092); Wed, 23 Mar 2016 18:55:02 +0000 Original-Received: (at 23092) by debbugs.gnu.org; 23 Mar 2016 18:54:17 +0000 Original-Received: from localhost ([127.0.0.1]:34754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ainv7-00027H-6F for submit@debbugs.gnu.org; Wed, 23 Mar 2016 14:54:17 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:65090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ainv5-000274-Dz for 23092@debbugs.gnu.org; Wed, 23 Mar 2016 14:54:15 -0400 Original-Received: from [192.168.1.102] ([212.95.7.65]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LyVpm-1Zf83M3Aj0-015t6b; Wed, 23 Mar 2016 19:54:06 +0100 In-Reply-To: <878u19gn38.fsf@gmail.com> X-Provags-ID: V03:K0:pKnP75WHSVpvY6fcozxvRRiQkfCP9iaUgn+dXGz1/fgr3PZmetN MmLJ7WvmrtCXm1bdPUrmB5XZNich49CB+FP8J17qh7+AlhE9G63S2rZZWpnFgPwy4cfQCl+ 1ReG9Fn50eXcjMb83nwO5E0bRniTcZSMzxnKRoLChCt5Xv17vofoH1z63clgTqRTHdGA5Md 69a8H5UY/izUjfyiKTJSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KGJP97Lj6CM=:EZgzuhsNm6zSXByucf3A71 NOewleCuwNR4F1ZTDlMlWmzLr11QcBY/kwee2KZ/o4zpQvRz9A/XAikxFpLJeeGolENuDEGwS gDyws+ZxtbkRb98/qMeSGdAV8/tPXxy85+ENcXWct88fpxWn8fDykeqXmLY4+3C8WOV5cqY0U RCFEE18tD34Sn1cGx86mrap9nk8zYu8qemPG/uOKBSANCK13v4iREUSsXtwK9Xyo8qk8ebNms 4zV4h6DfG8H2VOoPI9ZcTrnNDzOknBu6Y1gemYx4LqKl13Sy7RCvnVFcxVrD/7Gjxqe8LrIJQ FEAw5sZfW3XFvVpRqxweQJeUDgd/+Tuw6Vlqs2M7k0zPQ1LrsD/Kg94G+KdDpxDIbdgQBf+Vo D9uTOjvuDiM5NkV0dcTqz1l72DicLAYRQMP3YV4CFrH+gLq9tt5bkZgdMpgXAIFWWO9yQa6Rx rid/VZ0Z0OVeI8dq3AMKkyAuQluhGLSRKEFegoI4f+hjsLoJZ86gzP2l8CjDPlEtYNVTtz0XC vvNVnKn/w5j2Uxlzoxc9sxNbJWNqG3y6rfqGJt3InucPkUjC+qIAgPmacXsXV5JV6Qzj75mmM u8EPHlpkJWl9q+K8HnXU90eeIBFuil1mRl/H9ox7492xaJwJJJUzyYEnYMcZTbc7/+x64j/Hb IPZTD2xySD15VwDhoyT1ihTZsmNzIYOnpzaYOtxKUlgmpb4g1NQOTBZO0BFK6kClF2m8jXr+l hzMbmFFjJ60tdngQvZeyhkE+KTPvwatY+5I3s4TZG0FqCpkL1v74WMvvfR5THJkbzhTC6Rps 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:115405 Archived-At: >> Obviously, the second branch is based on the assumption that a user w= ill >> "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 foun= d >> the right one. > > This is a valid assumption and basis of design when the completion is = of > something like a command or a function name, because then the completi= on > list is gradually narrowed. > > But in the case of completion of a file path, this assumption is not > valid. (And completing each directory name down a file path is a > perfectly normal use case.) The difference is that one is not doing a > single completion but several discrete completions. I'm not sure whether we should by default change something in this case. Juri has designed the present concept and I would rather leave it to him how to proceed. > For example, I was doing a find-file to find something in my Emacs ini= t. > I started with `~/.em TAB' expecting a single match of ~/.emacs.d/ but= > instead (of course) I got the initial completions window with .emacs a= nd > .emacs.d in it -- a very small completions window. Then I needed a > subdirectory in ~/.emacs.d/ but couldn't remember its name at all, so = I > hit TAB again and got the entire contents of emacs.d/ which is a very > long list [it seems to be jammed up full of session files for some > reason] all displayed in a buffer sized to show one line of > completion candidates. Does enabling =E2=80=98temp-buffer-resize-mode=E2=80=99 handle that case = sufficiently well? >> 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. > > No, not normally. When I was trying to come up with a simple > reproducible recipe I wanted an example in the emacs tree, and the > example I was able to up with was a bit contrived. (Although I don't > think it's an unlikely use case.) Let's wait for Juri to chime in. Meanwhile please have a look at the manual changes I proposed. (I don't even know if the example works as intended.) martin