bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Ryan]

completing-read-default still supports a behavior that is, as far as I
know, a legacy feature that is kept only for backward compatibility with
code that was written before the default argument was added: if the
input is empty and the user presses RET, it will return the empty
string, even if require-match is non-nil and the empty string is not in
the collection. This quirk is a thorn in the side of packages that
provide alternative completing-read functions such as ido-ubiquitous and
ivy-mode, which both want to have RET return either the default or the
first choice on the list, not the empty string. While this behavior can
probably not be changed without breaking backward compatibility, we can
at least eliminate every use of the feature in the elisp files included
with Emacs. The patch below does exactly that for all the cases that I
am aware of. I am not a regular user of any of the 3 affected features,
so while I have done my best to ensure that these all work correctly,
ideally someone should check my work.

--- a/lisp/autoinsert.el    2017-05-30 23:50:04.000000000 -0400
+++ b/lisp/autoinsert.el    2017-05-31 00:14:05.000000000 -0400
@@ -186,7 +186,7 @@
         finder-known-keywords
         "\n"))
   ((let ((minibuffer-help-form v2))
-    (completing-read "Keyword, C-h: " v1 nil t))
+    (completing-read "Keyword, C-h: " v1 nil t nil nil ""))
      str ", ") & -2 "

  \;; This program is free software; you can redistribute it and/or modify

--- a/lisp/net/webjump.el    2017-05-30 23:41:41.000000000 -0400
+++ b/lisp/net/webjump.el    2017-05-30 23:48:39.000000000 -0400
@@ -358,7 +358,8 @@
    (interactive)
    (let* ((completion-ignore-case t)
       (item (assoc-string
-        (completing-read "WebJump to site: " webjump-sites nil t)
+        (completing-read "WebJump to site: " webjump-sites nil t nil nil
+                                 (car webjump-sites))
          webjump-sites t))
       (name (car item))
       (expr (cdr item)))
@@ -418,0 +419,0 @@

  (defun webjump-read-choice (name what choices &optional default)
    (let* ((completion-ignore-case t)
-         (choice (completing-read (concat name " " what ": ") choices 
nil t)))
+         (choice (completing-read (concat name " " what ": ") choices 
nil t nil nil
+                                  default)))
      (if (webjump-null-or-blank-string-p choice)
          default
        (cdr (assoc choice choices)))))
@@ -441,7 +443,8 @@
                                           ": ")
                                   completions
                                   nil
-                                 t)))
+                                 t nil nil
+                                 default)))
      (if (webjump-null-or-blank-string-p input)
          default
        (car (assoc input completions)))))

--- a/lisp/info.el    2017-05-30 23:39:55.000000000 -0400
+++ b/lisp/info.el    2017-05-30 23:37:44.000000000 -0400
@@ -956,7 +956,7 @@
    (interactive
     (list (if current-prefix-arg
           (completing-read "Node name: " (Info-build-node-completions)
-                  nil t "Top"))))
+                  nil t nil nil "Top"))))
    (unless nodename (setq nodename "Top"))
    (info-initialize)
    (Info-mode)
@@ -2580,7 +2580,8 @@
                          "Follow reference named (default "
                          default "): ")
                       "Follow reference named: ")
-                       completions nil t)))
+                       completions nil t nil nil
+                                       default)))
         (list (if (equal input "")
               default input) current-prefix-arg))
         (user-error "No cross-references in this node"))))
@@ -2742,4 +2743,4 @@
             (list Info-current-file Info-current-node
               Info-complete-next-re string completions
               Info-complete-nodes)))
-            (complete-with-action action completions string 
predicate))))))))
+            (complete-with-action action (cons "" completions) string 
predicate))))))))


  (defun Info-menu (menu-item &optional fork)
@@ -5311,11 +5312,13 @@
  completion alternatives to currently visited manuals."
    (interactive
     (list
-    (progn
+    (let ((choice ""))
        (info-initialize)
-      (completing-read "Manual name: "
-               (info--manual-names current-prefix-arg)
-               nil t))))
+      (while (equal choice "")
+        (setq choice
+              (completing-read "Manual name: "
+                               (info--manual-names current-prefix-arg)
+                               nil t))))))
    (let ((blist (buffer-list))
      (manual-re (concat "\\(/\\|\\`\\)" manual "\\(\\.\\|\\'\\)"))
      (case-fold-search t)




In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 
Version 10.9.5 (Build 13F1911))
of 2017-04-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Diff

Minor modes in effect:
recentf-mode: t
ws-butler-global-mode: t
ws-butler-mode: t
winner-mode: t
sml-modeline-mode: t
savehist-mode: t
save-place-mode: t
minibuffer-electric-default-mode: t
minibuffer-depth-indicate-mode: t
midnight-mode: t
ido-yes-or-no-mode: t
icomplete-mode: t
highlight-stages-global-mode: t
highlight-stages-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
global-pointback-mode: t
pointback-mode: t
global-hl-line-mode: t
global-anzu-mode: t
anzu-mode: t
desktop-save-mode: t
delete-selection-mode: t
beacon-mode: t
auto-dim-other-buffers-mode: t
ido-complete-space-or-hyphen-mode: t
ido-ubiquitous-mode: t
ido-everywhere: t
osx-pseudo-daemon-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
autopair-global-mode: t
autopair-mode: t
show-paren-mode: t
global-auto-complete-mode: t
override-global-mode: t
diff-auto-refine-mode: t
shell-dirtrack-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
line-number-mode: t
transient-mark-mode: t

Recent messages:
Checking 120 files in 
/Applications/Emacs.app/Contents/Resources/lisp/obsolete...
Checking for load-path shadows...done
Mark set [2 times]
Saved text until "(\\.\\|\\'\\)"))
(case-fold-search t)
"
Mark set [2 times]
Saved text until "(\\.\\|\\'\\)"))
(case-fold-search t)
"

Load-path shadows:
/Users/ryan/.emacs.d/el-get/ido-completing-read+/ido-completing-read+ 
hides 
/Users/ryan/.emacs.d/.cask/25.2/elpa/ido-completing-read+-20170313.1603/ido-completing-read+
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-bullets-20140918.1137/org-bullets 
hides 
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-bullets
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox hides 
/Applications/Emacs.app/Contents/Resources/lisp/org/ox
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-texinfo 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-texinfo
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-publish 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-publish
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-org 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-org
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-odt 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-odt
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-md 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-md
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-man 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-man
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-latex 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-latex
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-icalendar 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-icalendar
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-html 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-html
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-beamer 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-beamer
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ox-ascii 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ox-ascii
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org hides 
/Applications/Emacs.app/Contents/Resources/lisp/org/org
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-w3m 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-w3m
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-version 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-timer 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-table 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-src 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-rmail 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-rmail
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-protocol 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-plot 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-pcomplete 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-mouse 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-mobile 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-mhe 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-mhe
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-macs 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-macro 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-macro
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-loaddefs 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-list 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-irc 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-irc
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-install 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-inlinetask 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-info 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-info
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-indent 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-id 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-habit 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-gnus 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-gnus
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-footnote 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-feed 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-faces 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-eshell 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-eshell
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-entities 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-element 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-docview 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-docview
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-datetree 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-ctags 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-crypt 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-compat 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-colview 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-clock 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-capture 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-bibtex 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-bibtex
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-bbdb 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-bbdb
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-attach 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-archive 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/org-agenda 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob hides 
/Applications/Emacs.app/Contents/Resources/lisp/org/ob
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-tangle 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-table 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-sqlite 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-sql 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-shen 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-screen 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-scheme 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-scala 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-scala
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-sass 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-ruby 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-ref 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-R 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-python 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-plantuml 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-picolisp 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-perl 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-org 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-octave 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-ocaml 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-mscgen 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-maxima 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-matlab 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-makefile 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-makefile
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-lob 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-lisp 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-lilypond 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-ledger 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-latex 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-keys 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-keys
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-js 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-java 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-io 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-haskell 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-gnuplot 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-fortran 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-exp 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-eval 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-emacs-lisp 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-dot 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-ditaa 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-css 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-core 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-core
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-comint 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-clojure 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-calc 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-C 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-awk 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/ryan/.emacs.d/.cask/25.2/elpa/org-plus-contrib-20170515/ob-asymptote 
hides /Applications/Emacs.app/Contents/Resources/lisp/org/ob-asymptote
/Users/ryan/.emacs.d/.cask/25.2/elpa/seq-2.20/seq hides 
/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/seq
/Users/ryan/.emacs.d/.cask/25.2/elpa/let-alist-1.0.5/let-alist hides 
/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/let-alist

Features:
(shadow sort mail-extr ispell finder skeleton autoinsert webjump
perl-mode tramp-cache ivy-hydra hydra lv colir ivy derived ivy-overlay
ffap tar-mode mm-archive network-stream nsm starttls url-http tls gnutls
url-gw url-cache url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers magit-extras noflet-test ert ewoc files-x dired-aux dired-x
rect org-table goto-addr generic creole-mode magit-ediff ediff-merg
ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff
dabbrev misearch multi-isearch debug eieio-opt speedbar sb-image ezimage
dframe recentf tree-widget conf-mode sgml-mode flymake sh-script smie
emacsbug sendmail face-remap ws-butler winner sml-modeline savehist
saveplace minibuf-eldef mb-depth midnight ido-yes-or-no icomplete
highlight-stages undo-tree diff pointback assoc hl-line anzu desktop
frameset delsel beacon auto-dim-other-buffers ido-completing-read+
loadhist bar-cursor debian-changelog-mode git-wip-mode vc vc-dispatcher
ido-complete-space-or-hyphen ido-describe-fns ido-ubiquitous tempbuf
smooth-scrolling .loaddefs cus-edit cus-start cus-load warnings
system-specific-settings snakemake-mode smex ido slime etags xref
project arc-mode archive-mode hyperspec python pretty-symbols polymode
poly-base polymode-weave polymode-export polymode-debug polymode-methods
poly-lock polymode-compat polymode-classes polymode-core eieio-custom
wid-edit eieio-base color osx-pseudo-daemon org-bullets
occur-context-resize noflet cl-indent markdown-mode thingatpt
magit-filenotify magit-obsolete magit-blame magit-stash magit-bisect
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-branch magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip magit-log magit-diff smerge-mode magit-core
magit-autorevert autorevert filenotify magit-process magit-margin
magit-mode magit-git magit-section magit-popup git-commit magit-utils
crm log-edit message rfc822 mml mml-sec epg mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log with-editor async-bytecomp async
tramp-sh server lexbind-mode highlight-defined header2 git-gutter-fringe
fringe-helper git-gutter esup esup-child benchmark ess ess-mode
ess-noweb-mode ess-inf ess-tracebug ess-generics ess-utils ess-custom
executable ess-compat el-get el-get-autoloading el-get-list-packages
el-get-dependencies el-get-build el-get-status pp el-get-methods
el-get-fossil el-get-svn el-get-pacman el-get-github-zip
el-get-github-tar el-get-http-zip el-get-http-tar el-get-hg el-get-go
el-get-git-svn el-get-fink el-get-emacswiki el-get-http el-get-notify
el-get-emacsmirror el-get-github el-get-git el-get-elpa el-get-darcs
el-get-cvs el-get-bzr el-get-brew el-get-builtin el-get-apt-get
el-get-recipes el-get-byte-compile el-get-custom el-get-core autoload
keydef cperl-mode cl-lib-highlight bs browse-url autopair paren
auto-complete edmacro kmacro popup apache-mode adjust-parens
exec-path-from-shell use-package diminish bind-key compile vc-git
diff-mode org-eldoc org-rmail org-mhe org-irc org-info org-gnus
org-docview doc-view subr-x jka-compr image-mode dired org-bibtex bibtex
org-bbdb org-w3m org-element avl-tree org org-macro org-footnote
org-pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob
ob-table ob-keys ob-exp ob-comint tramp tramp-compat tramp-loaddefs
trampver shell pcomplete comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs pallet advice gh-common gh-profile url-parse auth-source
gnus-util password-cache url-vars marshal eieio-compat ht eieio
eieio-core cl slime-autoloads rx info cask cl-seq cl-macs cask-bootstrap
package-build mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr json map lisp-mnt shut-up
epl git commander f dash s finder-inf package epg-config seq byte-opt gv
bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs
pcase cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win 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
kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 2122003 311555)
(symbols 48 73753 285)
(miscs 40 11156 5859)
(strings 32 543550 25734)
(string-bytes 1 8281437)
(vectors 16 103351)
(vector-slots 8 2493815 132393)
(floats 8 1292 4144)
(intervals 56 139062 3567)
(buffers 976 220))

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> completing-read-default still supports a behavior that is, as
> far as I know, a legacy feature that is kept only for backward 
> compatibility with code that was written before the default
> argument was added:

The default arg has been available since the beginning, AFAIK.
The behavior you describe is no more legacy than is providing a
default-value arg.  Nothing to do with backward compatibility,
I think.

> if the input is empty and the user presses RET, it will return
> the empty string, even if require-match is non-nil and the empty
> string is not in the collection.

And it returns the default, even if REQUIRE-MATCH is non-nil
and the default is not in the collection.  Do you dislike
that behavior too?

"" is just the default default, if you like (or not).

Would you make a default arg be mandatory instead of optional?
Is that it?  If not, what default default would you propose?
What should be returned if no explicit default is provided and
the user hits RET with no input?

"" seems like a great choice for the default default, to me.
It's pretty much guaranteed never to coincide with any usable
completion candidate (which is not the case for a non-empty
default value).  For one thing, that lets you easily check
whether the user chose one of the candidates, even in the
case where the collection is complex (e.g. a function).

> This quirk

Why is it a quirk?

IN any case, nothing stops someone from defining their own
`my-completing-read', which does not have this feature, er,
quirk.  I don't see the problem.

> is a thorn in the side of packages that provide alternative
> completing-read functions such as ido-ubiquitous an
> ivy-mode, which both want to have RET return either the
> default or the first choice on the list, not the empty string.

They can do exactly do that - just by providing that as the
default arg.  RET with no input returns the default already.
If you want to return the first candidate by default then
just pass that candidate as the default arg.  What am I
missing?

I also don't see the behavior as a thorn in the side of all
packages that provide alternative kinds of completion.  But
you don't really say what you mean by a thorn, here.

And I don't see it as a thorn in the side of other uses of
`completing-read'.  `completing-read' is a quite general
function.  Just because some particular user or package
might not use it in every way possible is not a reason why
its behavior should be limited to what some package uses.
Nothing prevents a package from always supplying a default
arg other than "".

The doc string says:

 If the input is null, ‘completing-read’ returns DEF, or the
 first element of the list of default values, or an empty
 string if DEF is nil, regardless of the value of REQUIRE-MATCH.

That's the design.  What part of it do you not like, and
why?  What's the thorn/quirk?

Sorry, but I don't see what problem you are trying to solve.
Is it the need to specify a default other than "" when you
don't want that default default?

> While this behavior can probably not be changed without
> breaking backward compatibility,

Yes.

> we can at least eliminate every use of the feature in the
> elisp files included with Emacs.

Why would we do that?

It's up to calling code to decide what behavior it wants
for RET with no input.  Yes, probably there are some cases
in existing code where a better default value might be
provided.  That's something to be looked at case by case.
So far, I don't see a general problem to be fixed.  Where's
the bug?

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Ryan Thompson]

[-- Attachment #1: Type: text/plain, Size: 4644 bytes --]

>
> The default arg has been available since the beginning, AFAIK.
> The behavior you describe is no more legacy than is providing a
> default-value arg.  Nothing to do with backward compatibility,
> I think.


I suppose I inferred that it was a backward-compatibility issue from the
fact that the feature is used intentionally in very few places (all fairly
old code) and is triggered unintentionally in more places, i.e. more
recently-written functions that set REQUIRE-MATCH to t and then assume that
completing-read will always return an element from the collection. The
latter kind will typically produce an error or do something nonsensical for
the empty string.

And it returns the default, even if REQUIRE-MATCH is non-nil
> and the default is not in the collection.  Do you dislike
> that behavior too?
>
> "" is just the default default, if you like (or not).
>

Thanks, that's actually a good way to think about it.


> Would you make a default arg be mandatory instead of optional?
> Is that it?  If not, what default default would you propose?
> What should be returned if no explicit default is provided and
> the user hits RET with no input?
>

Thinking some more about it, I guess one solution would be to give
REQUIRE-MATCH could gain a special 3rd value, such as `force', which would
mandate that the returned value is a valid completion. (Not sure what
should happen in this case if DEF is provided and is not a valid
completion.)

"" seems like a great choice for the default default, to me.
> It's pretty much guaranteed never to coincide with any usable
> completion candidate (which is not the case for a non-empty
> default value).  For one thing, that lets you easily check
> whether the user chose one of the candidates, even in the
> case where the collection is complex (e.g. a function).
>
> > This quirk
>
> Why is it a quirk?
>
> IN any case, nothing stops someone from defining their own
> `my-completing-read', which does not have this feature, er,
> quirk.  I don't see the problem.
>

The problem comes when implementing a completion system that returns the
first available completion when pressiong RET (e.g. ido and ivy). In the
case of an empty input, RET causes these completion systems to return the
first element of COLLECTION if no default was specified. Sometimes this is
correct, but sometimes this is wrong, as in the following usage pattern:

(defun pick-a-fruit ()
  (interactive)
  (let* ((default "banana")
         (prompt (format "Pick a fruit (default %s): " default))
         (collection '("apple" "banana" "cherry"))
         (selection (completing-read prompt collection nil t)))
    (when (string= selection "")
      (setq selection default))
    (message "You selected %s" selection)))

This pattern is used in e.g. Info-follow-reference. The problem is that
there's no way for the completion function to know whether it's being used
in this way or not, so if the user presses RET on an empty input and the
default wasn't provied to completing-read, it doesn't know whether it
should return the empty string or the first match. For an example where
returning the first match seems like the more correct behavior, see
read-char-by-name, which throws an error on the empty string. This
ambiguity makes it difficult to reconcile the desired convenience feature
of "return the first match on RET" with the documented completing-read
behavior of "return the empty string on empty input + RET" without breaking
some functions. And it's not even possible to implement an automatic
fallback to completing-read-default, because there's no way for the
completion function to know whether the caller is expecting that behavior
(Info-follow-reference) or is expecting it not to happen
(read-char-by-name). Ultimately, that's the issue: if completing-read is
called with a DEF being nil, the calling code may or may not be expecting
it to return the empty string, and while not expecting the empty string
might represent a bug in the caller, the existence of such functions makes
it difficult to implement ido-style completion that does the right thing in
all cases.

Going back to your statement that "empty string is just the default
default", it's possible that one might get reasonable behavior for ido and
ivy by taking this statement literally and prepending "" to the list of
completions when DEF is nil. By "reasonable" I mean correct behavior in all
of the cases that completing-read-default is correct, and bug-for-bug
compatibility in functions that don't expect completing-read to return "".
I'll try that out and see how it works.

Thanks for the insights. I guess you can close this.

[-- Attachment #2: Type: text/html, Size: 6803 bytes --]

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 5/31/17 8:52 AM, Drew Adams wrote:

> Would you make a default arg be mandatory instead of optional?
> Is that it?  If not, what default default would you propose?

It's not necessary.

> What should be returned if no explicit default is provided and
> the user hits RET with no input?

Prohibit them from finishing completion, except through entering a valid 
value, or pressing C-g.

> IN any case, nothing stops someone from defining their own
> `my-completing-read', which does not have this feature, er,
> quirk.  I don't see the problem.

That doesn't help if we want to augment completing-read-function and all 
packages using it.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 7283 bytes --]

"" is just the default default, if you like (or not).

 

Thanks, that's actually a good way to think about it.

 

Would you make a default arg be mandatory instead of optional?
Is that it?  If not, what default default would you propose?
What should be returned if no explicit default is provided and
the user hits RET with no input?

 

Thinking some more about it, I guess one solution would be to give REQUIRE-MATCH could gain a special 3rd value, such as `force', which would mandate that the returned value is a valid completion. (Not sure what should happen in this case if DEF is provided and is not a valid completion.)

 

Today, `force' (or `abc', for that matter) does not exit IF at least some completion is performed. What you are requesting is, I guess, that it not exit even if no completion is performed - that it would be able to exit only if one of the candidates is chosen.

 

That would be backward-incompatible, since today the symbol `force' means the same as any other non-nil, non-t REQUIRE-MATCH value. Not the end of the world, but one consideration.

 

Today, you can just test the "" return value and re-issue the `completing-read'. Do that in a loop in and you have the behavior you want, no?

 

The problem comes when implementing a completion system that returns the first available completion when pressiong RET (e.g. ido and ivy). In the case of an empty input, RET causes these completion systems to return the first element of COLLECTION if no default was specified. 

 

I think you are saying that those systems want/need to behave that way, but `completing-read' does not behave that way out of the box? But you can make calls to `completing-read' always behave that way, right (see above)?

 

Sometimes this is correct, but sometimes this is wrong, as in the following usage pattern:

 

(defun pick-a-fruit ()
  (interactive)
  (let* ((default "banana")
         (prompt
          (format "Pick a fruit (default %s): " default))
         (collection '("apple" "banana" "cherry"))
         (selection
          (completing-read prompt collection nil t)))
    (when (string= selection "")
      (setq selection default))
    (message "You selected %s" selection)))
 

I don't follow. What is the behavior that you want? The above seems to be fine, as would be to repeatedly calli `completing-read' until the user entered something (that completes). Which behavior do you want?

 

This pattern is used in e.g. Info-follow-reference. The problem is that there's no way for the completion function to know whether it's being used in this way or not, so if the user presses RET on an empty input and the default wasn't provied to completing-read, it doesn't know whether it should return the empty string or the first match. 

 

Do you want your completion system to obey the (outside) call to `completing-read' or to do its own thing of returning the first candidate on empty input?

 

It sounds like you have a system that wants to have an alternative completion behavior from what some of the possible behaviors `completing-read' provides, but you also want it to (sometimes?) respect the behavior that `completing-read' provides.

 

And you cannot tell when you want this and when you want that, that is, when the behavior specified by the (outside) code should be respected and when the usual behavior of your completion should be imposed instead.

 

Is that it? If so, that doesn't sound like a problem with `completing-read'. And I don't see how letting REQUIRE-MATCH = `force' would change anything. IIUC, you don't have control over (outside) calls to `completing-read', so you cannot change them to use `force' or whatever.

 

For an example where returning the first match seems like the more correct behavior, see read-char-by-name, which throws an error on the empty string. 

 

(So does `Info-follow-reference', BTW: "No reference was specified".)

 

Raising an error on empty input is not the same thing as forcing input to be non-empty. Today it is easy to test for empty input (and so throw an error), thanks to the default default behavior of returning "".

 

This ambiguity makes it difficult to reconcile the desired convenience feature of "return the first match on RET" with the documented completing-read behavior of "return the empty string on empty input + RET" without breaking some functions. 

 

But your chosen convenience itself apparently gets in the way when you want to respect an (outside) call to `completing-read' that expects a different behavior, no?

 

This doesn't sound like a problem with `completing-read'. It sounds like a problem reconciling a one-size-fits-all convenient completion behavior (return the first candidate if no input) with (outside) code that might expect a different behavior for empty input.

 

And it's not even possible to implement an automatic fallback to completing-read-default, because there's no way for the completion function to know whether the caller is expecting that behavior (Info-follow-reference) or is expecting it not to happen (read-char-by-name). 

 

Isn't that the real problem you're having: that there is no way to know when to respect the caller and when to impose a different completion behavior? How can changing `completing-read' help solve that problem?

 

Ultimately, that's the issue: if completing-read is called with a DEF being nil, the calling code may or may not be expecting it to return the empty string,

 

It's normal for different calling code to expect different such behavior, no? And you are trying to accommodate those different expectations (at least sometimes?), instead of overriding them, no?

 

and while not expecting the empty string might represent a bug in the caller, 

 

Why suppose that? Sure, it's possible, but it's more likely that that's the desired behavior. When trying to accommodate outside code, you might need to put on its rose-colored glasses, not only the rose-colored glasses of your completion system. ;-)

 

the existence of such functions makes it difficult to implement ido-style completion that does the right thing in all cases.

 

Can you give a concrete example, describing the intended behavior by the outside caller, your intended behavior, and the problem you have in achieving either one?

 

Going back to your statement that "empty string is just the default default", it's possible that one might get reasonable behavior for ido and ivy by taking this statement literally and prepending "" to the list of completions when DEF is nil. 

 

Does that do what you want?

 

By "reasonable" I mean correct behavior in all of the cases that completing-read-default is correct, and bug-for-bug compatibility in functions that don't expect completing-read to return "". I'll try that out and see how it works.

 

Thanks for the insights. I guess you can close this.

 

No reason to be hasty in closing it. Better for us all to understand just what the problem is. So far, I admit that I don't, so I can't say much that is helpful here.

[-- Attachment #2: Type: text/html, Size: 18580 bytes --]

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> > Would you make a default arg be mandatory instead of optional?
> > Is that it?  If not, what default default would you propose?
> 
> It's not necessary.

What's not necessary?  The argument is either optional or mandatory.
If optional, what default behavior do you want?

Or are you saying that the default arg should just be removed
from `completing-read', because "it's not necessary"?  Not
necessary for whom?  Why isn't it ever a useful thing to have?

Just because some callers might not need it does not mean that
it is not useful for other callers.

> > What should be returned if no explicit default is provided and
> > the user hits RET with no input?
> 
> Prohibit them from finishing completion, except through entering
> a valid value, or pressing C-g.

(while <no valid value> <get input with completion>)

Is that hard?

> > In any case, nothing stops someone from defining their own
> > `my-completing-read', which does not have this feature, er,
> > quirk.  I don't see the problem.
> 
> That doesn't help if we want to augment completing-read-function
> and all packages using it.

What happens when you set `completing-read-function' to your
`my-completing-read'?

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 5/31/17 5:51 PM, Drew Adams wrote:

> What's not necessary?  The argument is either optional or mandatory.
> If optional, what default behavior do you want?

The one I mentioned in the next paragraph in my previous email.

> Or are you saying that the default arg should just be removed
> from `completing-read', because "it's not necessary"?  Not
> necessary for whom?  Why isn't it ever a useful thing to have?

No, I mean that having the default argument when it's not specified, is 
not necessary. There is no need for "default default".

> Just because some callers might not need it does not mean that
> it is not useful for other callers.

They can use the DEFAULT argument.

>> Prohibit them from finishing completion, except through entering
>> a valid value, or pressing C-g.
> 
> (while <no valid value> <get input with completion>)
> 
> Is that hard?

It makes completing-read-function calling convention more complex for no 
real gain. The simpler the API is, the easier it is to provide 
alternative implementations for.

And also, we will have new callers who are not aware of this quirk. 
Those packages might fail to account for the possibility that 
completing-read can return "". After all, they passed t as the 
REQUIRE-MATCH argument.

> What happens when you set `completing-read-function' to your
> `my-completing-read'?

Some callers rely on it returning an empty string when the user presses 
RET. In those cases, if my-completing-read does not provide this ability 
(literally, does not return "" when the user presses RET right away), 
the user experience can suffer.

And some UIs make it non-trivial for the completing-read-function to 
behave like above. E.g. add "" to the completions list but only when the 
user does not type anything.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> I mean that having the default argument when it's not specified, is
> not necessary. There is no need for "default default".
> 
> > Just because some callers might not need it does not mean that
> > it is not useful for other callers.
> 
> They can use the DEFAULT argument.

So are you arguing that DEFAULT should be a mandatory argument?
I addressed that in my first message.

> >> Prohibit them from finishing completion, except through entering
> >> a valid value, or pressing C-g.
> >
> > (while <no valid value> <get input with completion>)
> >
> > Is that hard?
> 
> It makes completing-read-function calling convention
> more complex for no real gain.

So you do think that it is hard?  Hard to believe.

And how so, no real gain?  If there is no real gain for
you then don't do it.  You said you wanted to keep
prompting and getting input as long as the user tried
to exit with no input.  Now you are saying that doing
that would e no real gain.  (?)

> The simpler the API is, the easier it is to provide
> alternative implementations for.

By that logic we should get rid of most of the optional
args to `completing-read'.  Or maybe we should get rid
of `completing-read' and let people do it all using
`read-from-minibuffer'?

But go ahead.  Make DEFAULT mandatory if you like.
See how that change goes down.

But if an explicit DEFAULT arg is the solution then your
completion system need only set arg DEFAULT to "" when
it is nil, no?  Or set it to the first completion candidate
when it is nil or "".  Or ... <whatever floats your boat>.

> And also, we will have new callers who are not aware of this quirk.
> Those packages might fail to account for the possibility that
> completing-read can return "". After all, they passed t as the
> REQUIRE-MATCH argument.
> 
> > What happens when you set `completing-read-function' to your
> > `my-completing-read'?
> 
> Some callers rely on it returning an empty string when the user
> presses RET.

Imagine that.  And they would rely on the same thing if they
passed "" as an explicit DEFAULT arg.

> In those cases, if my-completing-read does not provide this
> ability (literally, does not return "" when the user presses
> RET right away), the user experience can suffer.

Indeed.  So don't do that.  Respect what the caller expects.

> And some UIs make it non-trivial for the
> completing-read-function to behave like above. E.g. add
> "" to the completions list but only when the user does
> not type anything.

If you cannot test for "" return value then checking for
no input becomes even harder.

Sure, explicit "" DEFAULT provides the same possibility
for checking for input.

What does your `completing-read-function' want to do in
that case?

Sorry, but it's not clear to me what the problem is.
Anything I think I see you saying about the problem does
not seem to be solved by making DEFAULT mandatory.
What am I missing?  How about a concrete example?

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Ryan Thompson]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

>
> But if an explicit DEFAULT arg is the solution then your
> completion system need only set arg DEFAULT to "" when
> it is nil, no?  Or set it to the first completion candidate
> when it is nil or "".  Or ... <whatever floats your boat>.
>

The problem is that there is no one solution that floats everyone's boat.
Whatever you choose, someone sinks (i.e. has broken completion). The only
way to float everyone's boat is for the completion function to check which
function called it and then change its behavior based on prior knowledge of
what each caller expects. Consider the following two functions:

(defun pick-a-fruit ()
  (interactive)
  (let* ((default "banana")
         (prompt (format "Pick a fruit (default %s): " default))
         (collection '("apple" "banana" "cherry"))
         (selection (completing-read prompt collection nil t)))
    (when (string= selection "")
      (setq selection default))
    (message "You selected %s" selection)))

(defun pick-a-tool ()
  (interactive)
  (let* ((prompt "Pick a tool: ")
         (collection '("hammer" "screwdriver" "drill"))
         (selection (completing-read prompt collection nil t)))
    (message "You selected %S" selection)))

The fruit function expects completing-read to return an empty string
to indicate that the default should be used, while the tool function
expects completing-read to always return an element from the
collection no matter what. Technically, the tool function is wrong,
because completing-read is documented to return an empty string even
when REQUIRE-MATCH is non-nil. But there are plenty of functions that
use this pattern and expect it to work, because they don't know about
this edge case, and it would be nice to be able to support them in a
custom completion system without breaking the functions that use the
former pattern. As it is, you have to choose one or the other to
break, or else imeplement caller-dependent behavior to give everyone
what they expect, which is messy.

As I said, though, treating DEF = nil as equivalent to DEF = "" might
form the basis for an acceptable compromise. It will still break the
pick-a-tool case, but it will be clearer why it's breaking, since the
empty string will be presented explicitly as the first completion
option. I'll test it out.

[-- Attachment #2: Type: text/html, Size: 4779 bytes --]

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 5/31/17 6:19 PM, Drew Adams wrote:

>>> Just because some callers might not need it does not mean that
>>> it is not useful for other callers.
>>
>> They can use the DEFAULT argument.
> 
> So are you arguing that DEFAULT should be a mandatory argument?
> I addressed that in my first message.

No, I don't (hence the "can", not "must"). I addressed that in my first 
message. Go ahead and give it a read.

>>>> Prohibit them from finishing completion, except through entering
>>>> a valid value, or pressing C-g.
>>>
>>> (while <no valid value> <get input with completion>)
>>>
>>> Is that hard?
>>
>> It makes completing-read-function calling convention
>> more complex for no real gain.
> 
> So you do think that it is hard?  Hard to believe.

You've rephrased and misstated the above statement (which is obviously 
true) into something you can disagree with. Go back and read it again.

> And how so, no real gain?  If there is no real gain for
> you then don't do it.

I'm talking about what the API allows to do. You counter that with "the 
callers can opt not to do that". That is a useless observation.

> You said you wanted to keep
> prompting and getting input as long as the user tried
> to exit with no input.  Now you are saying that doing
> that would e no real gain.  (?)

No, I'm saying something different. The API gives two different ways to 
specify the default value of "" (one explicit and one implicit). There 
is no benefit in it.

> But if an explicit DEFAULT arg is the solution then your
> completion system need only set arg DEFAULT to "" when
> it is nil, no?  Or set it to the first completion candidate
> when it is nil or "".  Or ... <whatever floats your boat>.

Let's take ido-completing-read as an example. It shows the available 
options in the minibuffer right away. There are two types of callers.

1. Ones that want to see "" as the default. They are served by the 
current completing-read calling convention, and they can use the calling 
convention where "" has to be specified explicitly in the DEFAULT 
argument. The only difficulty is the backward compatibility and updating 
the existing code that is still out there.

2. Ones that don't want to see "" returned, ever, because they don't 
know what to do with it. Your proposed solution is:

(while <no valid value> <get input with completion>)

How will that look to the user faced with ido-completing-read? Suppose 
that function is modified to behave most compatibly with 
completing-read, that is, adds "" to the collection and makes it first 
in the list (as the default value).

The user sees that "" at the beginning of the list, has to skip over it 
to choose a valid completion (two actions instead of one, which is 
especially a problem if the first real option is usually the one user 
will want to take), and if they choose "", nothing happens except they 
have to choose again, while "" still hovers annoyingly at the beginning 
of the list.

That's ridiculous.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 5/31/17 6:44 PM, Ryan Thompson wrote:

> The problem is that there is no one solution that floats everyone's 
> boat. Whatever you choose, someone sinks (i.e. has broken completion). 
> The only way to float everyone's boat is for the completion function to 
> check which function called it and then change its behavior based on 
> prior knowledge of what each caller expects.

Or ask the "sane" callers to call a different, new function.

I think we should change the calling convention of 
completion-read-function (while keeping completing-read the same, it 
will call completing-read-function passing (or DEF "") as the default).

The new completing-read-function can choose to get rid of the legacy 
behavior; this variable is not as encumbered by backward compatibility 
requirement as completing-read itself. Hopefully updating 
completing-read-default won't be too difficult.

Then we introduce completing-read-strict (as one naming example) which 
calls completing-read-function without the implicit default.

Going back to the beginning of this bug report, the new patch would 
convert all uses of completing-read that don't expect "" as the default 
to use completing-read-strict.

See also this previous discussion: 
http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01682.html

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> I think we should change the calling convention of
> completion-read-function (while keeping completing-read the
> same, it will call completing-read-function passing (or DEF "")
> as the default).

The value of that variable is supposed to accept the same
args as `completing-read'.  Understood is that `completing-read'
just passes its args along to the value of `completing-read-function'.

Anything else makes it impossible for `completing-read-function'
to be as general as it should be.  It should be able to do
exactly what `completing-read' does now, if it wants.

If your particular value of `completing-read-function' wants
to consider the DEF arg value to really be `(or DEF "")' then
it need only act that way, no?

  (setq def  (or def ""))

End of story, no?  Why do you need to change the interface
of `completing-read-function' itself?

And if that is insufficient for some reason, can't you use
`advice-add' to redefine `completing-read' (e.g. in some
scope or for some duration) to do exactly what you need?

I sense that you have a real problem, but I'm not sure what it is.

A guess is that you would like `completing-read', within the
scope of some mode (e.g. Ido Ubiquitous), behave as if the DEF
arg it receives (where abscence is equivalent to receiving nil)
were in fact `(or DEF "")'.

What prevents you from making `completing-read' behave that
way (or any other way) within your context?  Why is it
insufficient for you to do that in your value of
`completing-read-function' or by advising `completing-read'
for the duration?

Why should your particular need be spread to everyone and
every use of `completing-read'?  Why should `completing-read'
or `completing-read-function' be stunted in this way?

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 6/1/17 2:16 AM, Drew Adams wrote:

> The value of that variable is supposed to accept the same
> args as `completing-read'.  Understood is that `completing-read'
> just passes its args along to the value of `completing-read-function'.

That will change.

> Anything else makes it impossible for `completing-read-function'
> to be as general as it should be.

(defun completing-read (prompt collection &optional predicate
                                require-match initial-input hist def
                                inherit-input-method)
   (funcall completing-read-function
            prompt collection predicate require-match
            initial-input hist (or def "") inherit-input-method))

should suffice.

> It should be able to do
> exactly what `completing-read' does now, if it wants.

The function does not want anything.

> And if that is insufficient for some reason, can't you use
> `advice-add' to redefine `completing-read' (e.g. in some
> scope or for some duration) to do exactly what you need?
> 
> I sense that you have a real problem, but I'm not sure what it is.

Maybe try reading? I've sent a pretty long explanation to you in the 
previous message.

> What prevents you from making `completing-read' behave that
> way (or any other way) within your context?  Why is it
> insufficient for you to do that in your value of
> `completing-read-function' or by advising `completing-read'
> for the duration?

My context is "the whole of Emacs". That's what Ido Ubiquitous is 
supposed to be affecting and improving.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> > The value of that variable is supposed to accept the same
> > args as `completing-read'.  Understood is that `completing-read'
> > just passes its args along to the value of `completing-read-function'.
> 
> That will change.

I certainly hope not, a priori.  No good reason has been given
for that.  Just a trumpian pronouncement of a change to come.

> > Anything else makes it impossible for `completing-read-function'
> > to be as general as it should be.
> 
> (defun completing-read (prompt collection &optional predicate
>                                 require-match initial-input hist def
>                                 inherit-input-method)
>    (funcall completing-read-function
>             prompt collection predicate require-match
>             initial-input hist (or def "") inherit-input-method))
> 
> should suffice.

It doesn't suffice.  This should suffice, as advertised:

 (funcall completing-read-function
          prompt collection predicate require-match
          initial-input hist def inherit-input-method)

And in your `completing-read-function': (setq def (or def "")).
End of story.  It really seems like you are making a mountain
out of a mole hill.  You want DEF = nil to act like DEF = "".
Big deal.  Just do that in the right place: inside your
`completing-read-function'.

> > What prevents you from making `completing-read' behave that
> > way (or any other way) within your context?  Why is it
> > insufficient for you to do that in your value of
> > `completing-read-function' or by advising `completing-read'
> > for the duration?
> 
> My context is "the whole of Emacs". That's what Ido Ubiquitous
> is supposed to be affecting and improving.

Really?  Even when `ido-ubiquitous-mode' is off?

What about users who do not want to use `ido-ubiquitous-mode'?
Do they count too?  Do you mean that all of Emacs will succumb
to `ido-ubiquitous-mode'?  Will you be expecting all Emacs users
and libraries to adhere to the "improvement" of Ido Uber Alles?

Not every user is an Ido user.  `completing-read' does not
belong to Ido - it is more general than the restricted
behavior you've been pitching.  Having nil DEF act like ""
is a special case.

If that behavior is contained within `ido-ubiquitous-mode'
then that mode should already be able to impose whatever
completion behavior it wants.

Isn't that fair enough: Keep Ido Ubiquitous completion
behavior for `ido-ubiquitous-mode', and not for all of
Emacs and all the time?

And it should be able to do that without changing anything in
`completing-read' or `completing-read-function'.  And if it
does need to change the value of `completing-read-function'
for the duration, it can do that.  And if it needs to advise
`completing-read' for the duration, it can do that.  That
seems clear enough.  Your mode can use any kind of completion
it wants.

Again: What prevents you from making `completing-read' behave
that way (or any other way) within your context?  Why is it
insufficient for you to do that in your value of
`completing-read-function' or by advising `completing-read'
for the duration?

No answer.  Just a statement that your context is the World
Of Emacs, that you "will change" the behavior not just for
Ido Ubiquitous but for all of Emacs.  Sheesh.

Please do whatever you need to do to `completing-read'
inside the mode only.  That's why it's a mode.  That's
why it's called `ido-ubiquitous-mode' and not "Emacs".

I change the behavior of `completing-read' considerably
more than what you've described, but I do it only inside
`icicle-mode'.  When the mode is off, the vanilla behavior
returns to `completing-read'.  Not a big deal.  Normal.

Icicles completion too applies to "the whole of Emacs".
That's what Icicles "affects and improves".  And it
does so only when Icicle mode is on.

I don't see why `ido-ubiquitous-mode' can't act similarly.
What's so special about it, that it needs to not only
modify `completing-read' behavior when the mode is on
but modify more generally, for all uses, regardless of
whether `ido-ubiquitous-mode' is on?

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 6/1/17 5:23 AM, Drew Adams wrote:

>> (defun completing-read (prompt collection &optional predicate
>>                                  require-match initial-input hist def
>>                                  inherit-input-method)
>>     (funcall completing-read-function
>>              prompt collection predicate require-match
>>              initial-input hist (or def "") inherit-input-method))
>>
>> should suffice.
> 
> It doesn't suffice.

Citation needed.

>> My context is "the whole of Emacs". That's what Ido Ubiquitous
>> is supposed to be affecting and improving.
> 
> Really?  Even when `ido-ubiquitous-mode' is off?

Obviously not. Also not when it's not installed, in case you were wondering.

> Again: What prevents you from making `completing-read' behave
> that way (or any other way) within your context?  Why is it
> insufficient for you to do that in your value of
> `completing-read-function' or by advising `completing-read'
> for the duration?
> 
> No answer.

You fail at reading.

> I change the behavior of `completing-read' considerably
> more than what you've described, but I do it only inside
> `icicle-mode'.  When the mode is off, the vanilla behavior
> returns to `completing-read'.  Not a big deal.  Normal.

And yet, you haven't contributed anything helpful to this discussion so far.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Drew Adams]

> >> (defun completing-read (prompt collection &optional predicate
> >>                                  require-match initial-input hist def
> >>                                  inherit-input-method)
> >>     (funcall completing-read-function
> >>              prompt collection predicate require-match
> >>              initial-input hist (or def "") inherit-input-method))
> >> should suffice.
> >
> > It doesn't suffice.
> 
> Citation needed.

No "citation" needed.

`completing-read-function' needs to have the same signature
as `completing-read'.

I am the one who requested `completing-read-function' and
pushed to have it added to Emacs.  Its purpose is to easily
let you change the _complete_ behavior of `completing-read',
just by binding a variable.

That requires passing it exactly the same arguments, to do
as it pleases with them.  If, as in your case, it wants to
act as if DEF were in fact `(or DEF "")', it can do that.

If you want to simulate an explicit DEF when none is present,
that's easy enough to do in the function that is your value
of `completing-read-function'.  You don't need to force that
on all uses of `completing-read-function'.

Changing the signature of `completing-read-function' in the
way you suggest makes all uses of `completing-read-function'
follow the path you've outlined for `ido-ubiquitous-mode'.
That's a particular kind of completion.  No thanks.

And no need.  You don't need that, to make your mode do
what you want.  If you disagree, please show da codez: a
simple example that doesn't work and for which you see no
possible solution.

> >> My context is "the whole of Emacs". That's what Ido Ubiquitous
> >> is supposed to be affecting and improving.
> >
> > Really?  Even when `ido-ubiquitous-mode' is off?
> 
> Obviously not. Also not when it's not installed, in case you
> were wondering.

In that case, it's obvious that you can do whatever you need
inside the mode.  Do your (setq def (or def "")) there, for
use only by your mode.  You haven't shown why you think you
cannot do that.

> > Again: What prevents you from making `completing-read' behave
> > that way (or any other way) within your context?  Why is it
> > insufficient for you to do that in your value of
> > `completing-read-function' or by advising `completing-read'
> > for the duration?
> >
> > No answer.
> 
> You fail at reading.

Nonsense.  Why can't you use `completing-read-function' to
do what you want in your mode?

> > I change the behavior of `completing-read' considerably
> > more than what you've described, but I do it only inside
> > `icicle-mode'.  When the mode is off, the vanilla behavior
> > returns to `completing-read'.  Not a big deal.  Normal.
> 
> And yet, you haven't contributed anything helpful to this
> discussion so far.

Ooooh.

Please say why you cannot do what you need for just your mode.

`completing-read' is not intended to have only the behavior
you want.  But it is designed to _let you get_ the behavior
you want, as well as other behaviors.

There is a reason for the DEF argument, a reason for it to
be optional, and a reason for its default value to be "".
All of which I've gone over.

This thread was started by a misconception of what DEF is
for, thinking that it is useless.  It may be useless - or
even an obstacle to be worked around - for your use case,
but it is not useless for Emacs.

DEF was even expanded several releases ago, to allow a
value that is a list of default values.  Those too likely
don't fit your narrow use case.  Default values are
intentionally not completion candidates.  And yes, in
general they are useful, even if not for your use case
of `completing-read'.

If your use case calls for no default values, or in effect
wants to treat them as completion candidates, it's easy
enough for you to do that.  That is not the general,
default, intentional treatment of DEF by `completing-read'.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 6/1/17 5:57 PM, Drew Adams wrote:

> `completing-read-function' needs to have the same signature
> as `completing-read'.
> 
> I am the one who requested `completing-read-function' and
> pushed to have it added to Emacs.

Thank you for that, but that doesn't mean it can't ever change.

> Its purpose is to easily
> let you change the _complete_ behavior of `completing-read',
> just by binding a variable.

Indeed.

> That requires passing it exactly the same arguments, to do
> as it pleases with them.

No, it does not require that.

> If, as in your case, it wants to
> act as if DEF were in fact `(or DEF "")', it can do that.

It _already is_, according to the contract of completing-read. And that 
is the problem.

> Changing the signature of `completing-read-function' in the
> way you suggest makes all uses of `completing-read-function'
> follow the path you've outlined for `ido-ubiquitous-mode'.

Nope. Like I said, the behavior of completing-read will not change.

completing-read-function will change, but just a little. With the new 
benefit that it's now aware of whether the caller wants to have a 
default value or not.

> And no need.  You don't need that, to make your mode do
> what you want.  If you disagree, please show da codez: a
> simple example that doesn't work and for which you see no
> possible solution.

The code is pointless here. Just read this again:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27158#32

>> Obviously not. Also not when it's not installed, in case you
>> were wondering.
> 
> In that case, it's obvious that you can do whatever you need
> inside the mode.

Nope.

> There is a reason for the DEF argument, a reason for it to
> be optional, and a reason for its default value to be "".
> All of which I've gone over.

Err, no. You didn't.

> DEF was even expanded several releases ago, to allow a
> value that is a list of default values.  Those too likely
> don't fit your narrow use case.  Default values are
> intentionally not completion candidates.  And yes, in
> general they are useful, even if not for your use case
> of `completing-read'.

Nobody is taking DEF away.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Ryan Thompson]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

In any case, I've come up with an experimental version of ido-ubiquitous
based on the idea of "empty string is the default default". It's currently
on the empty-string branch:
https://github.com/DarwinAwardWinner/ido-ubiquitous/tree/empty-string

Here's the relevant code:
https://github.com/DarwinAwardWinner/ido-ubiquitous/blob/083479a3075eaf35711a53cef2d90d3fdf9213a1/ido-completing-read%2B.el#L88-L111
 and
https://github.com/DarwinAwardWinner/ido-ubiquitous/blob/083479a3075eaf35711a53cef2d90d3fdf9213a1/ido-completing-read%2B.el#L266-L286


I'll be testing this out to see if it works acceptably well in all cases.
Comments welcome.

[-- Attachment #2: Type: text/html, Size: 1143 bytes --]

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 6/2/17 12:04 AM, Ryan Thompson wrote:

> I'll be testing this out to see if it works acceptably well in all 
> cases.

Does it work well in the "don't want any default" case?

> Comments welcome.

'prepend-empty-string' sounds like what I'd expect; 
'append-empty-string' doesn't sounds particularly useful (what's the 
goal here?); 'Any other value' kind of looks like over-engineering.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Ryan Thompson]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

On Mon, Jun 5, 2017 at 7:01 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Does it work well in the "don't want any default" case?
>

It does the same thing as completing-read-default, which is that it allows
you to enter an empty string by pressing RET and assumes that the calling
function is expecting that to happen. In particular, this means that any
code that wrongly assumed that setting REQUIRE-MATCH would guarantee
returning an element of COLLECTION is now equally broken in both standard
completion and ido completion, as opposed to being spuriously "fixed" by
ido ignoring the spec of completing-read.

'prepend-empty-string' sounds like what I'd expect;
> 'append-empty-string' doesn't sounds particularly useful (what's the
> goal here?); 'Any other value' kind of looks like over-engineering.
>

I wasn't sure if any of those made sense other than prepend-empty-string
and nil, but they were 2 lines of code each, and I can remove them later (I
haven't made a release for this yet). The idea behind append-empty-string
was that you might to make it possible to return the empty string even
though REQUIRE-MATCH is non-nil, but you don't want it to be the default.
The function thing was just "I dunno, maybe someone needs someone else."
I'll probably remove them if I don't find a use for them. They're not used
at the moment.

Anyway, I'm finding it to work pretty well without requiring a distinction
between commands that do or do not expect the empty string. I merged that
branch into my bleeding-edge branch and fixed a bunch of bugs, and I'm
going to test it for a while before releasing.

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 6/6/17 3:06 AM, Ryan Thompson wrote:

>     Does it work well in the "don't want any default" case?
> 
> It does the same thing as completing-read-default, which is that it 
> allows you to enter an empty string by pressing RET and assumes that the 
> calling function is expecting that to happen. In particular, this means 
> that any code that wrongly assumed that setting REQUIRE-MATCH would 
> guarantee returning an element of COLLECTION is now equally broken in 
> both standard completion and ido completion, as opposed to being 
> spuriously "fixed" by ido ignoring the spec of completing-read.

Indeed. So less than ideal, like discussed.

> Anyway, I'm finding it to work pretty well without requiring a 
> distinction between commands that do or do not expect the empty string. 
> I merged that branch into my bleeding-edge branch and fixed a bunch of 
> bugs, and I'm going to test it for a while before releasing.

I agree that it's a step forward toward better compatibility.

bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Lars Ingebrigtsen]

Ryan <rct@thompsonclan.org> writes:

> completing-read-default still supports a behavior that is, as far as I
> know, a legacy feature that is kept only for backward compatibility with
> code that was written before the default argument was added: if the
> input is empty and the user presses RET, it will return the empty
> string, even if require-match is non-nil and the empty string is not in
> the collection.

[...]

> While this behavior can
> probably not be changed without breaking backward compatibility, we can
> at least eliminate every use of the feature in the elisp files included
> with Emacs. The patch below does exactly that for all the cases that I
> am aware of.

[...]

> -    (completing-read "Keyword, C-h: " v1 nil t))
> +    (completing-read "Keyword, C-h: " v1 nil t nil nil ""))

If we're not going to change the behaviour, I don't really see any
advantage to changing the in-tree callers, so I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no