bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

When TAB is pressed during entry of a command in the minibuffer, a
window appears displaying a list of completions. To some extent this
window seems to be sized to fit the number of completions. If the
user enters more of the command and presses TAB again the contents
of the completions window are refreshed but the window is not resized.

This is impossible to use if there are very few completions when TAB
is pressed the first time, resulting in a very tiny window, and
there are very many completions when TAB is pressed the second time.
This can happen, for example, when finding a file.

For example, from the Emacs build directory:

    src/emacs -Q

    C-x C-f            ; find-file
    lib/v TAB          ; A tiny window pops up with "verify.h" and "vla.h."
    <backspace> s TAB

At this point there is still a tiny completions window with about 50
completions most of which are not visible in the window.

On the other hand,

    C-x C-f lib/s TAB

displays the same completions in a much larger completion window
(looks like it's half the frame height), so most of the available
completions can be seen.


In GNU Emacs 25.0.92.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-03-21 built on moondust
Windowing system distributor 'Fedora Project', version 11.0.11801000
System Description:	Fedora release 23 (Twenty Three)

Configured using:
 'configure --prefix=/usr/local/ --enable-checking=yes,glyphs
 --enable-check-lisp-object-type 'CFLAGS=-O0 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_MONETARY: en_DK.utf8
  value of $LC_NUMERIC: en_DK.utf8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  recentf-mode: t
  display-battery-mode: t
  display-time-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  savehist-mode: t
  save-place-mode: t
  electric-pair-mode: t
  desktop-save-mode: t
  cua-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
Reading active file from archive via nnfolder...
Opening nnfolder server on archive...done
Reading active file from archive via nnfolder...done
Reading active file via nnfolder...
Opening nnfolder server...done
Reading incoming mail from file...
nnfolder: Reading incoming mail (no new mail)...done
Reading active file via nnfolder...done
Checking new news...done
command-execute: Command attempted to use minibuffer while in minibuffer

Load-path shadows:
/home/nlj/.emacs.d/elpa/org-20160229/ob-ref hides /usr/local/share/emacs/25.0.92/lisp/org/ob-ref
/home/nlj/.emacs.d/elpa/org-20160229/ob-dot hides /usr/local/share/emacs/25.0.92/lisp/org/ob-dot
/home/nlj/.emacs.d/elpa/org-20160229/ob-octave hides /usr/local/share/emacs/25.0.92/lisp/org/ob-octave
/home/nlj/.emacs.d/elpa/org-20160229/ob-maxima hides /usr/local/share/emacs/25.0.92/lisp/org/ob-maxima
/home/nlj/.emacs.d/elpa/org-20160229/ob-scala hides /usr/local/share/emacs/25.0.92/lisp/org/ob-scala
/home/nlj/.emacs.d/elpa/org-20160229/org-plot hides /usr/local/share/emacs/25.0.92/lisp/org/org-plot
/home/nlj/.emacs.d/elpa/org-20160229/ob-org hides /usr/local/share/emacs/25.0.92/lisp/org/ob-org
/home/nlj/.emacs.d/elpa/org-20160229/ob-haskell hides /usr/local/share/emacs/25.0.92/lisp/org/ob-haskell
/home/nlj/.emacs.d/elpa/org-20160229/org-indent hides /usr/local/share/emacs/25.0.92/lisp/org/org-indent
/home/nlj/.emacs.d/elpa/org-20160229/org-habit hides /usr/local/share/emacs/25.0.92/lisp/org/org-habit
/home/nlj/.emacs.d/elpa/org-20160229/org-datetree hides /usr/local/share/emacs/25.0.92/lisp/org/org-datetree
/home/nlj/.emacs.d/elpa/org-20160229/ob-lob hides /usr/local/share/emacs/25.0.92/lisp/org/ob-lob
/home/nlj/.emacs.d/elpa/org-20160229/org-list hides /usr/local/share/emacs/25.0.92/lisp/org/org-list
/home/nlj/.emacs.d/elpa/org-20160229/ob-ruby hides /usr/local/share/emacs/25.0.92/lisp/org/ob-ruby
/home/nlj/.emacs.d/elpa/org-20160229/ob-R hides /usr/local/share/emacs/25.0.92/lisp/org/ob-R
/home/nlj/.emacs.d/elpa/org-20160229/ob-awk hides /usr/local/share/emacs/25.0.92/lisp/org/ob-awk
/home/nlj/.emacs.d/elpa/org-20160229/ob-sqlite hides /usr/local/share/emacs/25.0.92/lisp/org/ob-sqlite
/home/nlj/.emacs.d/elpa/org-20160229/ob-makefile hides /usr/local/share/emacs/25.0.92/lisp/org/ob-makefile
/home/nlj/.emacs.d/elpa/org-20160229/org-capture hides /usr/local/share/emacs/25.0.92/lisp/org/org-capture
/home/nlj/.emacs.d/elpa/org-20160229/org-archive hides /usr/local/share/emacs/25.0.92/lisp/org/org-archive
/home/nlj/.emacs.d/elpa/org-20160229/ob-python hides /usr/local/share/emacs/25.0.92/lisp/org/ob-python
/home/nlj/.emacs.d/elpa/org-20160229/ob-js hides /usr/local/share/emacs/25.0.92/lisp/org/ob-js
/home/nlj/.emacs.d/elpa/org-20160229/ox-md hides /usr/local/share/emacs/25.0.92/lisp/org/ox-md
/home/nlj/.emacs.d/elpa/org-20160229/org-table hides /usr/local/share/emacs/25.0.92/lisp/org/org-table
/home/nlj/.emacs.d/elpa/org-20160229/org-install hides /usr/local/share/emacs/25.0.92/lisp/org/org-install
/home/nlj/.emacs.d/elpa/org-20160229/ox-latex hides /usr/local/share/emacs/25.0.92/lisp/org/ox-latex
/home/nlj/.emacs.d/elpa/org-20160229/org-docview hides /usr/local/share/emacs/25.0.92/lisp/org/org-docview
/home/nlj/.emacs.d/elpa/org-20160229/ox-ascii hides /usr/local/share/emacs/25.0.92/lisp/org/ox-ascii
/home/nlj/.emacs.d/elpa/org-20160229/org-mhe hides /usr/local/share/emacs/25.0.92/lisp/org/org-mhe
/home/nlj/.emacs.d/elpa/org-20160229/org-crypt hides /usr/local/share/emacs/25.0.92/lisp/org/org-crypt
/home/nlj/.emacs.d/elpa/org-20160229/org-macro hides /usr/local/share/emacs/25.0.92/lisp/org/org-macro
/home/nlj/.emacs.d/elpa/org-20160229/ox-odt hides /usr/local/share/emacs/25.0.92/lisp/org/ox-odt
/home/nlj/.emacs.d/elpa/org-20160229/org-eshell hides /usr/local/share/emacs/25.0.92/lisp/org/org-eshell
/home/nlj/.emacs.d/elpa/org-20160229/ob-fortran hides /usr/local/share/emacs/25.0.92/lisp/org/ob-fortran
/home/nlj/.emacs.d/elpa/org-20160229/org-entities hides /usr/local/share/emacs/25.0.92/lisp/org/org-entities
/home/nlj/.emacs.d/elpa/org-20160229/ob-picolisp hides /usr/local/share/emacs/25.0.92/lisp/org/ob-picolisp
/home/nlj/.emacs.d/elpa/org-20160229/org-feed hides /usr/local/share/emacs/25.0.92/lisp/org/org-feed
/home/nlj/.emacs.d/elpa/org-20160229/ox hides /usr/local/share/emacs/25.0.92/lisp/org/ox
/home/nlj/.emacs.d/elpa/org-20160229/org-id hides /usr/local/share/emacs/25.0.92/lisp/org/org-id
/home/nlj/.emacs.d/elpa/org-20160229/ob-clojure hides /usr/local/share/emacs/25.0.92/lisp/org/ob-clojure
/home/nlj/.emacs.d/elpa/org-20160229/org-macs hides /usr/local/share/emacs/25.0.92/lisp/org/org-macs
/home/nlj/.emacs.d/elpa/org-20160229/ob-table hides /usr/local/share/emacs/25.0.92/lisp/org/ob-table
/home/nlj/.emacs.d/elpa/org-20160229/org-pcomplete hides /usr/local/share/emacs/25.0.92/lisp/org/org-pcomplete
/home/nlj/.emacs.d/elpa/org-20160229/ox-publish hides /usr/local/share/emacs/25.0.92/lisp/org/ox-publish
/home/nlj/.emacs.d/elpa/org-20160229/ob-scheme hides /usr/local/share/emacs/25.0.92/lisp/org/ob-scheme
/home/nlj/.emacs.d/elpa/org-20160229/ob-keys hides /usr/local/share/emacs/25.0.92/lisp/org/ob-keys
/home/nlj/.emacs.d/elpa/org-20160229/ob-io hides /usr/local/share/emacs/25.0.92/lisp/org/ob-io
/home/nlj/.emacs.d/elpa/org-20160229/ox-texinfo hides /usr/local/share/emacs/25.0.92/lisp/org/ox-texinfo
/home/nlj/.emacs.d/elpa/org-20160229/org-bibtex hides /usr/local/share/emacs/25.0.92/lisp/org/org-bibtex
/home/nlj/.emacs.d/elpa/org-20160229/org-protocol hides /usr/local/share/emacs/25.0.92/lisp/org/org-protocol
/home/nlj/.emacs.d/elpa/org-20160229/ob-mscgen hides /usr/local/share/emacs/25.0.92/lisp/org/ob-mscgen
/home/nlj/.emacs.d/elpa/org-20160229/org-irc hides /usr/local/share/emacs/25.0.92/lisp/org/org-irc
/home/nlj/.emacs.d/elpa/org-20160229/org-faces hides /usr/local/share/emacs/25.0.92/lisp/org/org-faces
/home/nlj/.emacs.d/elpa/org-20160229/ob-lilypond hides /usr/local/share/emacs/25.0.92/lisp/org/ob-lilypond
/home/nlj/.emacs.d/elpa/org-20160229/org-w3m hides /usr/local/share/emacs/25.0.92/lisp/org/org-w3m
/home/nlj/.emacs.d/elpa/org-20160229/ob-ditaa hides /usr/local/share/emacs/25.0.92/lisp/org/ob-ditaa
/home/nlj/.emacs.d/elpa/org-20160229/ob-comint hides /usr/local/share/emacs/25.0.92/lisp/org/ob-comint
/home/nlj/.emacs.d/elpa/org-20160229/ob-css hides /usr/local/share/emacs/25.0.92/lisp/org/ob-css
/home/nlj/.emacs.d/elpa/org-20160229/org hides /usr/local/share/emacs/25.0.92/lisp/org/org
/home/nlj/.emacs.d/elpa/org-20160229/org-src hides /usr/local/share/emacs/25.0.92/lisp/org/org-src
/home/nlj/.emacs.d/elpa/org-20160229/ob-eval hides /usr/local/share/emacs/25.0.92/lisp/org/ob-eval
/home/nlj/.emacs.d/elpa/org-20160229/ob-gnuplot hides /usr/local/share/emacs/25.0.92/lisp/org/ob-gnuplot
/home/nlj/.emacs.d/elpa/org-20160229/ox-man hides /usr/local/share/emacs/25.0.92/lisp/org/ox-man
/home/nlj/.emacs.d/elpa/org-20160229/org-version hides /usr/local/share/emacs/25.0.92/lisp/org/org-version
/home/nlj/.emacs.d/elpa/org-20160229/org-mobile hides /usr/local/share/emacs/25.0.92/lisp/org/org-mobile
/home/nlj/.emacs.d/elpa/org-20160229/ob-emacs-lisp hides /usr/local/share/emacs/25.0.92/lisp/org/ob-emacs-lisp
/home/nlj/.emacs.d/elpa/org-20160229/ob-perl hides /usr/local/share/emacs/25.0.92/lisp/org/ob-perl
/home/nlj/.emacs.d/elpa/org-20160229/ob-exp hides /usr/local/share/emacs/25.0.92/lisp/org/ob-exp
/home/nlj/.emacs.d/elpa/org-20160229/org-info hides /usr/local/share/emacs/25.0.92/lisp/org/org-info
/home/nlj/.emacs.d/elpa/org-20160229/org-footnote hides /usr/local/share/emacs/25.0.92/lisp/org/org-footnote
/home/nlj/.emacs.d/elpa/org-20160229/org-compat hides /usr/local/share/emacs/25.0.92/lisp/org/org-compat
/home/nlj/.emacs.d/elpa/org-20160229/org-agenda hides /usr/local/share/emacs/25.0.92/lisp/org/org-agenda
/home/nlj/.emacs.d/elpa/org-20160229/org-timer hides /usr/local/share/emacs/25.0.92/lisp/org/org-timer
/home/nlj/.emacs.d/elpa/org-20160229/ob-shen hides /usr/local/share/emacs/25.0.92/lisp/org/ob-shen
/home/nlj/.emacs.d/elpa/org-20160229/ob-tangle hides /usr/local/share/emacs/25.0.92/lisp/org/ob-tangle
/home/nlj/.emacs.d/elpa/org-20160229/ob-calc hides /usr/local/share/emacs/25.0.92/lisp/org/ob-calc
/home/nlj/.emacs.d/elpa/org-20160229/org-inlinetask hides /usr/local/share/emacs/25.0.92/lisp/org/org-inlinetask
/home/nlj/.emacs.d/elpa/org-20160229/ob-C hides /usr/local/share/emacs/25.0.92/lisp/org/ob-C
/home/nlj/.emacs.d/elpa/org-20160229/org-gnus hides /usr/local/share/emacs/25.0.92/lisp/org/org-gnus
/home/nlj/.emacs.d/elpa/org-20160229/org-clock hides /usr/local/share/emacs/25.0.92/lisp/org/org-clock
/home/nlj/.emacs.d/elpa/org-20160229/ox-icalendar hides /usr/local/share/emacs/25.0.92/lisp/org/ox-icalendar
/home/nlj/.emacs.d/elpa/org-20160229/ox-beamer hides /usr/local/share/emacs/25.0.92/lisp/org/ox-beamer
/home/nlj/.emacs.d/elpa/org-20160229/org-mouse hides /usr/local/share/emacs/25.0.92/lisp/org/org-mouse
/home/nlj/.emacs.d/elpa/org-20160229/ob-ocaml hides /usr/local/share/emacs/25.0.92/lisp/org/ob-ocaml
/home/nlj/.emacs.d/elpa/org-20160229/ob-plantuml hides /usr/local/share/emacs/25.0.92/lisp/org/ob-plantuml
/home/nlj/.emacs.d/elpa/org-20160229/ob-screen hides /usr/local/share/emacs/25.0.92/lisp/org/ob-screen
/home/nlj/.emacs.d/elpa/org-20160229/org-colview hides /usr/local/share/emacs/25.0.92/lisp/org/org-colview
/home/nlj/.emacs.d/elpa/org-20160229/ob-sass hides /usr/local/share/emacs/25.0.92/lisp/org/ob-sass
/home/nlj/.emacs.d/elpa/org-20160229/ox-html hides /usr/local/share/emacs/25.0.92/lisp/org/ox-html
/home/nlj/.emacs.d/elpa/org-20160229/org-bbdb hides /usr/local/share/emacs/25.0.92/lisp/org/org-bbdb
/home/nlj/.emacs.d/elpa/org-20160229/ob-lisp hides /usr/local/share/emacs/25.0.92/lisp/org/ob-lisp
/home/nlj/.emacs.d/elpa/org-20160229/ob-java hides /usr/local/share/emacs/25.0.92/lisp/org/ob-java
/home/nlj/.emacs.d/elpa/org-20160229/org-rmail hides /usr/local/share/emacs/25.0.92/lisp/org/org-rmail
/home/nlj/.emacs.d/elpa/org-20160229/ob-asymptote hides /usr/local/share/emacs/25.0.92/lisp/org/ob-asymptote
/home/nlj/.emacs.d/elpa/org-20160229/ob-matlab hides /usr/local/share/emacs/25.0.92/lisp/org/ob-matlab
/home/nlj/.emacs.d/elpa/org-20160229/ox-org hides /usr/local/share/emacs/25.0.92/lisp/org/ox-org
/home/nlj/.emacs.d/elpa/org-20160229/org-element hides /usr/local/share/emacs/25.0.92/lisp/org/org-element
/home/nlj/.emacs.d/elpa/org-20160229/org-attach hides /usr/local/share/emacs/25.0.92/lisp/org/org-attach
/home/nlj/.emacs.d/elpa/org-20160229/ob-ledger hides /usr/local/share/emacs/25.0.92/lisp/org/ob-ledger
/home/nlj/.emacs.d/elpa/org-20160229/ob-core hides /usr/local/share/emacs/25.0.92/lisp/org/ob-core
/home/nlj/.emacs.d/elpa/org-20160229/ob-sql hides /usr/local/share/emacs/25.0.92/lisp/org/ob-sql
/home/nlj/.emacs.d/elpa/org-20160229/ob-latex hides /usr/local/share/emacs/25.0.92/lisp/org/ob-latex
/home/nlj/.emacs.d/elpa/org-20160229/org-ctags hides /usr/local/share/emacs/25.0.92/lisp/org/org-ctags
/home/nlj/.emacs.d/elpa/org-20160229/org-loaddefs hides /usr/local/share/emacs/25.0.92/lisp/org/org-loaddefs
/home/nlj/.emacs.d/elpa/org-20160229/ob hides /usr/local/share/emacs/25.0.92/lisp/org/ob
~/.emacs.d/modules/emms/lisp/tq hides /usr/local/share/emacs/25.0.92/lisp/emacs-lisp/tq

Features:
(shadow bbdb-message mail-extr emacsbug sendmail nndraft nnmh utf-7
server pinentry epa-file epa derived network-stream nsm starttls
nnfolder bbdb-gnus bbdb-mua nnnil gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg nntp gnus-cache character-fold misearch
multi-isearch view flyspell ispell sage sage-load rx emms-bookmarks
emms-cue emms-mode-line-icon emms-browser sort emms-playlist-sort
emms-last-played emms-player-xine emms-player-mpd tq emms-playing-time
emms-lyrics emms-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source eieio
byte-opt bytecomp byte-compile cl-extra cconv eieio-core url-vars
emms-streams emms-tag-editor emms-mark emms-mode-line emms-cache
emms-info-ogginfo emms-info-mp3info emms-info later-do
emms-playlist-mode emms-player-vlc emms-player-mplayer
emms-player-simple emms-source-playlist emms-source-file locate
emms-setup emms emms-compat compile navi-mode outshine outorg
org-contacts cl-seq org-capture gnus-art mm-uu mml2015 mm-view mml-smime
smime password-cache dig mailcap gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc
nnoo parse-time gnus-spec gnus-int gnus-range message cl-macs rfc822 mml
mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus gnus-ems nnheader
mail-utils mm-util help-fns help-mode mail-prsvr cl gv org-rmail org-mhe
org-irc org-info org-gnus gnus-util org-docview doc-view subr-x
jka-compr image-mode dired org-bibtex bibtex org-bbdb org-element
avl-tree org-w3m org-agenda org advice org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func bbdb-anniv
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs bbdb-com crm
mailabbrev bbdb bbdb-site timezone bbdb-loaddefs finder-inf tex-site
info package epg-config edmacro kmacro recentf tree-widget wid-edit
easymenu battery time wheatgrass-theme delsel paren savehist saveplace
elec-pair desktop frameset cl-loaddefs pcase cl-lib cua-base cus-start
cus-load time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 429063 43530)
 (symbols 48 92971 1)
 (miscs 40 2440 7664)
 (strings 32 127530 10978)
 (string-bytes 1 4294397)
 (vectors 16 39578)
 (vector-slots 8 882340 15295)
 (floats 8 552 613)
 (intervals 56 2004 0)
 (buffers 976 39)
 (heap 1024 96824 6437))

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 > When TAB is pressed during entry of a command in the minibuffer, a
 > window appears displaying a list of completions. To some extent this
 > window seems to be sized to fit the number of completions. If the
 > user enters more of the command and presses TAB again the contents
 > of the completions window are refreshed but the window is not resized.
 >
 > This is impossible to use if there are very few completions when TAB
 > is pressed the first time, resulting in a very tiny window, and
 > there are very many completions when TAB is pressed the second time.
 > This can happen, for example, when finding a file.
 >
 > For example, from the Emacs build directory:
 >
 >      src/emacs -Q
 >
 >      C-x C-f            ; find-file
 >      lib/v TAB          ; A tiny window pops up with "verify.h" and "vla.h."
 >      <backspace> s TAB
 >
 > At this point there is still a tiny completions window with about 50
 > completions most of which are not visible in the window.
 >
 > On the other hand,
 >
 >      C-x C-f lib/s TAB
 >
 > displays the same completions in a much larger completion window
 > (looks like it's half the frame height), so most of the available
 > completions can be seen.

Please try again with ‘temp-buffer-resize-mode’ enabled.  I always
wanted to enable it by default but a number of people didn't like it so
I dropped the idea.

martin

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Tue, 22 Mar 2016 14:07:39 -0300
> 
>     src/emacs -Q
> 
>     C-x C-f            ; find-file
>     lib/v TAB          ; A tiny window pops up with "verify.h" and "vla.h."
>     <backspace> s TAB
> 
> At this point there is still a tiny completions window with about 50
> completions most of which are not visible in the window.

Press TAB repeatedly to scroll through those 50 completions.

(I'm not saying this cannot or shouldn't be improved, I'm saying this
is not "impossible to use".)

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

Hi Martin,

At 18:21 +0100 on Tuesday 2016-03-22, martin rudalics wrote:
>
> Please try again with ‘temp-buffer-resize-mode’ enabled.  I always
> wanted to enable it by default but a number of people didn't like it so
> I dropped the idea.

Yes, with `temp-buffer-resize-mode' enabled the problem goes away. I do
not know, though, whether or not enabling it by default is the "correct"
fix for the bug.

N.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 > Yes, with `temp-buffer-resize-mode' enabled the problem goes away. I do
 > not know, though, whether or not enabling it by default is the "correct"
 > fix for the bug.

Neither do I.  But displaying two, three completions in a window that
occupies one half of your frame does not strike me as a good solution
either.

martin

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

Hi Eli,

At 20:28 +0200 on Tuesday 2016-03-22, Eli Zaretskii wrote:
>
>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Tue, 22 Mar 2016 14:07:39 -0300
>> 
>>     src/emacs -Q
>> 
>>     C-x C-f            ; find-file
>>     lib/v TAB          ; A tiny window pops up with "verify.h" and "vla.h."
>>     <backspace> s TAB
>> 
>> At this point there is still a tiny completions window with about 50
>> completions most of which are not visible in the window.
>
> Press TAB repeatedly to scroll through those 50 completions.
>
> (I'm not saying this cannot or shouldn't be improved, I'm saying this
> is not "impossible to use".)

That's pretty weird, but yes, it does work (in a manner of speaking). So
as you correctly point out, it is not "impossible to use".

However, it's interesting that with the recipe reversed, the completions
window _does_ get resized.:

    src/emacs -Q

    C-x C-f            ; find-file
    lib/s TAB          ; A largish completions window is shown.
    <backspace> 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 isn't
working quite right. Unless the design is that the completions window
can only be "shrunk" but not "grown".

N.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: 23092@debbugs.gnu.org
> Date: Tue, 22 Mar 2016 15:55:33 -0300
> 
> >> At this point there is still a tiny completions window with about 50
> >> completions most of which are not visible in the window.
> >
> > Press TAB repeatedly to scroll through those 50 completions.
> >
> > (I'm not saying this cannot or shouldn't be improved, I'm saying this
> > is not "impossible to use".)
> 
> That's pretty weird, but yes, it does work (in a manner of speaking).

I'm surprised you didn't know about this behavior.  It's one of the
oldest ones I remember in Emacs, a very basic feature of displaying
completions.

> However, it's interesting that with the recipe reversed, the completions
> window _does_ get resized.:
> 
>     src/emacs -Q
> 
>     C-x C-f            ; find-file
>     lib/s TAB          ; A largish completions window is shown.
>     <backspace> 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 isn'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 ;-)

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

Hi Martin,

At 19:53 +0100 on Tuesday 2016-03-22, martin rudalics wrote:
>
> displaying two, three completions in a window that occupies one half
> of your frame does not strike me as a good solution either.

For me though, this seems absolutely fine. After all that window is only
there until I've finished my command in the minibuffer, then it
disappears. So it doesn't really matter to me how few completions are
in it.

(If it was taking up so much space that it prevented me from seeing
something I needed to refer to while completing my command in the
minibuffer, that would be another matter entirely, but with the
completions window occupying the right half of the frame that was never
an issue for me in Emacs 24.)

N.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

At 21:04 +0200 on Tuesday 2016-03-22, Eli Zaretskii wrote:
>
>> > Press TAB repeatedly to scroll through those 50 completions.
>> >
>> > (I'm not saying this cannot or shouldn't be improved, I'm saying this
>> > is not "impossible to use".)
>> 
>> That's pretty weird, but yes, it does work (in a manner of speaking).
>
> I'm surprised you didn't know about this behavior.  It's one of the
> oldest ones I remember in Emacs, a very basic feature of displaying
> completions.

I'm not terribly surprised that I didn't know about it. Emacs is replete
with useful things that I don't know about, or have forgotten about!

In this case, back when the completions appeared in the
window-split-right, often they would all fit, so there no need to
scroll. Otherwise I relied on doing `M-x o' enough times to get to the
completion window and then worked from inside it.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Tue, 22 Mar 2016 16:56:03 -0300
> Cc: 23092@debbugs.gnu.org
> 
> > displaying two, three completions in a window that occupies one half
> > of your frame does not strike me as a good solution either.
> 
> For me though, this seems absolutely fine. After all that window is only
> there until I've finished my command in the minibuffer, then it
> disappears.

In theory, yes.  In practice, it's all too easy to cause it be left in
place long after you have no use for that buffer.  I'm sure it
happened to you at least once.

> (If it was taking up so much space that it prevented me from seeing
> something I needed to refer to while completing my command in the
> minibuffer, that would be another matter entirely, but with the
> completions window occupying the right half of the frame that was never
> an issue for me in Emacs 24.)

Having it occupy half the frame, obscuring too much of the buffer I'm
editing, is also an annoyance.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

At 22:10 +0200 on Tuesday 2016-03-22, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Tue, 22 Mar 2016 16:56:03 -0300
>> Cc: 23092@debbugs.gnu.org
>> 
>> > displaying two, three completions in a window that occupies one half
>> > of your frame does not strike me as a good solution either.
>> 
>> For me though, this seems absolutely fine. After all that window is only
>> there until I've finished my command in the minibuffer, then it
>> disappears.
>
> In theory, yes.  In practice, it's all too easy to cause it be left in
> place long after you have no use for that buffer.  I'm sure it
> happened to you at least once.

Actually, no, I haven't had that problem yet, not caused by the
completions window at least; it seems to consistently close when I
finish the command in the minibuffer.

>> (If it was taking up so much space that it prevented me from seeing
>> something I needed to refer to while completing my command in the
>> minibuffer, that would be another matter entirely, but with the
>> completions window occupying the right half of the frame that was never
>> an issue for me in Emacs 24.)
>
> Having it occupy half the frame, obscuring too much of the buffer I'm
> editing, is also an annoyance.

Yes, obscuring the buffer being edited is an annoyance. I suppose the
circumstances when it occurs depends on the user's set up.

In my usage I almost always use a small laptop and the display is
sufficiently small that it's easiest to keep all my Emacs frames
maximised. The display has a 16:9 rather than a 4:3 (16:12) ratio, so
I'm rather limited in height compared to width. A full height window
here is only 48 characters high.

When my frame gets split-right, I get two windows that are both about 92
characters wide, so a completions window on the right rarely obscures
_any_ of the window I'm editing (which is typically displaying lines of
text 72- or 80-characters long).

On the other hand, the new behaviour of splitting the completion window
below is guaranteed to obscure part of the window I'm editing.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 >> However, it's interesting that with the recipe reversed, the completions
 >> window _does_ get resized.:
 >>
 >>      src/emacs -Q
 >>
 >>      C-x C-f            ; find-file
 >>      lib/s TAB          ; A largish completions window is shown.
 >>      <backspace> 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 isn'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 ‘minibuffer-completion-help’:

	    ,(if temp-buffer-resize-mode
		 '(window-height . resize-temp-buffer-window)
	       '(window-height . shrink-window-if-larger-than-buffer))

The first branch of the ‘if’ means that if ‘temp-buffer-resize-mode’ is
enabled, this function will always try to fit the window to the buffer.
The second branch means that if ‘temp-buffer-resize-mode’ 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

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

At 09:09 +0100 on Wednesday 2016-03-23, martin rudalics wrote:
>
> 	    ,(if temp-buffer-resize-mode
> 		 '(window-height . resize-temp-buffer-window)
> 	       '(window-height . shrink-window-if-larger-than-buffer))

Thanks Martin, that indeed captures the observed behaviour in a
nutshell.

> 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.

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 completion
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.

For example, I was doing a find-file to find something in my Emacs init.
I started with `~/.em TAB' expecting a single match of ~/.emacs.d/ but
instead (of course) I got the initial completions window with .emacs and
.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.

> 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.)

N.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 >> 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.
 >
 > 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 completion
 > 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 init.
 > I started with `~/.em TAB' expecting a single match of ~/.emacs.d/ but
 > instead (of course) I got the initial completions window with .emacs and
 > .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 ‘temp-buffer-resize-mode’ 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

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[N. Jackson]

At 19:53 +0100 on Wednesday 2016-03-23, martin rudalics wrote:
>
> 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.

By all means. I just felt it was my "duty" to point out what might (or
might not) be an oversight in the design.

> Does enabling ‘temp-buffer-resize-mode’ handle that case sufficiently
> well?

Yes after a day of use, I can say that `temp-buffer-resize-mode'
provides much better behaviour (IMO), and properly supports the type of
use cases I mentioned.

However the point is moot (for this user at least), because with your
code from bug#23093, viz.

    (customize-set-variable
     'display-buffer-alist
     '(("\\*Completions\\*" display-buffer-pop-up-window)))

I get my completions buffer on the right half of my frame, and it would
not make sense for that to change size (I wouldn't like it, anyway), so
I won't need to use `temp-buffer-resize-mode'.

Thanks.

Regards,
N.

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[Juri Linkov]

>> 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.

I noticed this deficiency, but failed to properly fix it earlier,
because it's only you who completely understands all the intricacies
of window-displaying machinery ;-)

However, after I looked at this again now, it looks natural to just
replace ‘shrink-window-if-larger-than-buffer’ with ‘fit-window-to-buffer’.
But I'd leave it to you to decide how good this change is and what
consequences it might entail.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index ecac0ae..6540059 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1835,7 +1835,7 @@ minibuffer-completion-help
                 'display-buffer-below-selected))
 	    ,(if temp-buffer-resize-mode
 		 '(window-height . resize-temp-buffer-window)
-	       '(window-height . shrink-window-if-larger-than-buffer))
+	       '(window-height . fit-window-to-buffer))
 	    ,(when temp-buffer-resize-mode
 	       '(preserve-size . (nil . t))))
           nil

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 > However, after I looked at this again now, it looks natural to just
 > replace ‘shrink-window-if-larger-than-buffer’ with ‘fit-window-to-buffer’.
 > But I'd leave it to you to decide how good this change is and what
 > consequences it might entail.

It should have two consequences: (1) When there are many completions,
the *Completions* window might be larger initially.  (2) The
*Completions* window will mostly behave as if ‘temp-buffer-resize-mode’
were enabled by default.  I think the OP's scenario is much more
embarrassing so I think we can live with the consequences of your fix.

Please install it and I'll fix the manual accordingly.

Thanks, martin

 > diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
 > index ecac0ae..6540059 100644
 > --- a/lisp/minibuffer.el
 > +++ b/lisp/minibuffer.el
 > @@ -1835,7 +1835,7 @@ minibuffer-completion-help
 >                   'display-buffer-below-selected))
 >   	    ,(if temp-buffer-resize-mode
 >   		 '(window-height . resize-temp-buffer-window)
 > -	       '(window-height . shrink-window-if-larger-than-buffer))
 > +	       '(window-height . fit-window-to-buffer))
 >   	    ,(when temp-buffer-resize-mode
 >   	       '(preserve-size . (nil . t))))
 >             nil
 >
 >

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[Juri Linkov]

>> However, after I looked at this again now, it looks natural to just
>> replace ‘shrink-window-if-larger-than-buffer’ with ‘fit-window-to-buffer’.
>> But I'd leave it to you to decide how good this change is and what
>> consequences it might entail.
>
> It should have two consequences: (1) When there are many completions,
> the *Completions* window might be larger initially.

This doesn't look like a bad consequence since more currently active data
on screen is better.

> (2) The *Completions* window will mostly behave as if ‘temp-buffer-resize-mode’
> were enabled by default.  I think the OP's scenario is much more
> embarrassing so I think we can live with the consequences of your fix.
>
> Please install it and I'll fix the manual accordingly.

Fixed minibuffer-completion-help now.

> Thanks, martin
>
>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>> index ecac0ae..6540059 100644
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -1835,7 +1835,7 @@ minibuffer-completion-help
>>                   'display-buffer-below-selected))
>>   	    ,(if temp-buffer-resize-mode
>>   		 '(window-height . resize-temp-buffer-window)
>> -	       '(window-height . shrink-window-if-larger-than-buffer))
>> +	       '(window-height . fit-window-to-buffer))
>>   	    ,(when temp-buffer-resize-mode
>>   	       '(preserve-size . (nil . t))))
>>             nil

bug#23092: 25.0.92; Minibuffer completion fails to resize completion window if reused during same command

[martin rudalics]

 > Fixed minibuffer-completion-help now.

I updated the Emacs manual accordingly.  Please have a look.

Thanks, martin