From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 00:42:23 2017 Received: (at submit) by debbugs.gnu.org; 31 May 2017 04:42:23 +0000 Received: from localhost ([127.0.0.1]:46044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFvSg-0006V3-9M for submit@debbugs.gnu.org; Wed, 31 May 2017 00:42:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFvSd-0006Uq-Uv for submit@debbugs.gnu.org; Wed, 31 May 2017 00:42:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFvSV-0007fD-Ib for submit@debbugs.gnu.org; Wed, 31 May 2017 00:42:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43834) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dFvSV-0007f7-Eg for submit@debbugs.gnu.org; Wed, 31 May 2017 00:42:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFvSR-0000IH-Km for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 00:42:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFvSO-0007eM-Nj for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 00:42:07 -0400 Received: from mail-qk0-x22a.google.com ([2607:f8b0:400d:c09::22a]:34634) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dFvSO-0007eC-FN for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 00:42:04 -0400 Received: by mail-qk0-x22a.google.com with SMTP id d14so3407563qkb.1 for ; Tue, 30 May 2017 21:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=to:subject:from:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=qHk37iEsdBbQ36Swbk04ARDoHyX00AAkD31tCZ9KCvA=; b=VRAGjb3yEuBLiQIW8RyrGykkbod1mOtteI2ZVEWHLKdEmqwWSh+8XpEM/UQxf2MrNB gdX19rDZwSgi+MTi9L0FiZpMyrAsrQLucvn6xFI6J3BU+MQs9/WrErrcyy7KuFo0fVjA vHBHMiN57NnqOZdnFiKIpD8mZ3KLN61JPjBOA7hy7S9psO2sZ7bFOhNqJkq+G3N2TDdv PbYVkM2A8G90UdF+DbzneGp6gVh5QYjLtrdnuAaFlOigwc2S/R8IV05zlsrwTGELTWxW s1YTaOCSlCJD3UQjOpILJUdOOiguYgJDO3SaJcX5sDaBAfI2bheZK0tIOEK2Tab0j+GZ GEtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=qHk37iEsdBbQ36Swbk04ARDoHyX00AAkD31tCZ9KCvA=; b=N0n301EcCByBzF6boyrNXyd2PBu8Gjd0p0Zd5/SH0G4E4IzQSl8iRQXAwZTrcfcDqp AcyLDDP7aTSRjPw0UQFy0ngJG9zNiNFfQdoPluZyKfg5cLJdc+tge5kKbvNCBYSbw161 o6N9KJhfvgJgj7n3YhsVFqZriGS+r5RxR5UfMRsT3f/AjT0Y+Q59sWjzkLM78x+M8oTv 4Z7wwY33z9Kxdb9c50Is02kNyXkSZtrMl5q3YnF2LHp2uhM9Yq0YMnjcLxAlCIRvgHMk i4kLi1dB+1CM0iSLpyH1UNarh5ANpwnz1RjCPKIAYt+an+lAumWz9NUoACcnaMJ38v78 Iu2Q== X-Gm-Message-State: AODbwcCKMposetlFGOF5KJu1u2GOafPZDQCWmQGkI42vWkaeXxpxd5RB 10MAAJE11Hl9vs6/cOH4hw== X-Received: by 10.55.192.75 with SMTP id o72mr19056873qki.94.1496205721463; Tue, 30 May 2017 21:42:01 -0700 (PDT) Received: from techne-2.local ([2601:194:8281:252f:1047:af3f:d6f6:c8a5]) by smtp.googlemail.com with ESMTPSA id r10sm9782804qtb.15.2017.05.30.21.42.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 21:42:00 -0700 (PDT) To: bug-gnu-emacs@gnu.org Subject: 25.2; Eliminating old usage of completing-read from built-in files From: Ryan Message-ID: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> Date: Wed, 31 May 2017 00:41:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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)) From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 01:52:30 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 05:52:30 +0000 Received: from localhost ([127.0.0.1]:46065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFwYY-0008Ga-4q for submit@debbugs.gnu.org; Wed, 31 May 2017 01:52:30 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:49060) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFwYV-0008GM-Uy for 27158@debbugs.gnu.org; Wed, 31 May 2017 01:52:28 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4V5qJv9003077 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 05:52:20 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4V5qJmT000389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 05:52:19 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4V5qIFW031622; Wed, 31 May 2017 05:52:18 GMT MIME-Version: 1.0 Message-ID: <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> Date: Tue, 30 May 2017 22:52:16 -0700 (PDT) From: Drew Adams To: Ryan , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> In-Reply-To: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > completing-read-default still supports a behavior that is, as > far as I know, a legacy feature that is kept only for backward=20 > 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, =E2=80=98completing-read=E2=80=99 returns DEF, or th= e 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? From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 07:45:52 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 11:45:53 +0000 Received: from localhost ([127.0.0.1]:46250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG24W-0001KW-Ef for submit@debbugs.gnu.org; Wed, 31 May 2017 07:45:52 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:32805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG24U-0001KJ-B7 for 27158@debbugs.gnu.org; Wed, 31 May 2017 07:45:50 -0400 Received: by mail-io0-f174.google.com with SMTP id p24so14369566ioi.0 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 04:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RK9Dwu3HKyggMhFU5kWWIlReW6Z4ostB0Yz9TN50Yqs=; b=maqYGaJN/dPb/ccrmkT4SJxMgkhaJunzr8E3n9pG1r6eu9sSFwiO3slgWYxi9DzgKD I53K2atczzx4pfzH8Cned5coP1Gm6mwTI+h3/3s3PkvQVX/OfhmY+LEn37IUFvZUUxG3 LHzP+7J+SX3V64RcW5JjtM7CiZfLYod3ZIgk+zGKEEvmORveu868qDd9fPXpeLOQbLhq 8beEvOwoY8b0O0bRXEmiBUuvGLWr+hDdmYForhW2NbC+A0nkwTuIE/kYJ2t54HYO/lwV bpVuhAoYJWbqskeHAVIMqCdB9Ov0bZ+quDVLZWT32T+gwuul3QQy7ar1Hlc+wNp1NKOI lR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RK9Dwu3HKyggMhFU5kWWIlReW6Z4ostB0Yz9TN50Yqs=; b=apq4PdRcjRxx3O3ucEeXRPjyqbd9WojhCPyKTINrdhp1poNeo4eVPb/aaXK6qB+OYt DY6QWC+7Exzhi4jjcosPfe9WFm8Pz4S+XisuMKeup/0FHRBaeocLpWFWspV9djZS4fa2 VN3IWIR33vmqF6byPODkS7Lan9mkPA5Bfl7wRLRleOImu/uXykoRxdU0TqIQAWdOgkby yQZ6U7kDKh2Kkb7c77tVB458Zt1nemeoShFbx4geOlRs0b3h/GaJ6Nt2k4cs01uEL+J5 wGeGJtwoMvnVuCocTT4IPl9lsIif/gX7pURQ4tSvJBjfbyza1d1wQ8f4mFdF/2Qr3lQy AD6g== X-Gm-Message-State: AODbwcCRjp4Ra/sBczd+SpuLbcM/hITvtqhy6GiV8YOImGE7VJoMKjWN N6BzJD32Sg1KW77CI2xTxZA+ksM1ChQl X-Received: by 10.107.25.203 with SMTP id 194mr21188830ioz.182.1496231144761; Wed, 31 May 2017 04:45:44 -0700 (PDT) MIME-Version: 1.0 References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> In-Reply-To: <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> From: Ryan Thompson Date: Wed, 31 May 2017 11:45:33 +0000 Message-ID: Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , 27158@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113fe2dae2c06f0550d0758b" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --001a113fe2dae2c06f0550d0758b Content-Type: text/plain; charset="UTF-8" > > 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. --001a113fe2dae2c06f0550d0758b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= 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.=C2=A0 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 intent= ionally in very few places (all fairly old code) and is triggered unintenti= onally in more places, i.e. more recently-written functions that set REQUIR= E-MATCH to t and then assume that completing-read will always return an ele= ment from the collection. The latter kind will typically produce an error o= r 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.=C2=A0 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 ab= out it.
=C2=A0
Would you make= a default arg be mandatory instead of optional?
Is that it?=C2=A0 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?

Thinki= ng 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 th= at the returned value is a valid completion. (Not sure what should happen i= n this case if DEF is provided and is not a valid completion.)
"" seems like a great choi= ce 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).=C2=A0 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.=C2=A0 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 c= ase of an empty input, RET causes these completion systems to return the fi= rst element of COLLECTION if no default was specified. Sometimes this is co= rrect, but sometimes this is wrong, as in the following usage pattern:
(defun pick-a-fruit ()
  (interactive)
  (let* ((default "banana")
         (prompt (format "Pic=
k a fruit (default %s): " default))
         (collection '("apple&q=
uot; "banana" "cherry"))
         (selection (completing-read prompt collection nil t)))
    (when (string=3D selection "")
      (setq selection default))
    (message "You selected %s"=
 selection)))
This pattern is used in e.g. In= fo-follow-reference. The problem is that there's no way for the complet= ion 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 t= o completing-read, it doesn't know whether it should return the empty s= tring or the first match. For an example where returning the first match se= ems 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 t= he desired convenience feature of "return the first match on RET"= with the documented completing-read behavior of "return the empty str= ing on empty input + RET" without breaking some functions. And it'= s not even possible to implement an automatic fallback to completing-read-d= efault, because there's no way for the completion function to know whet= her the caller is expecting that behavior (Info-follow-reference) or is exp= ecting it not to happen (read-char-by-name). Ultimately, that's the iss= ue: 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 expec= ting the empty string might represent a bug in the caller, the existence of= such functions makes it difficult to implement ido-style completion that d= oes the right thing in all cases.

Going back to yo= ur statement that "empty string is just the default default", it&= #39;s possible that one might get reasonable behavior for ido and ivy by ta= king this statement literally and prepending "" to the list of co= mpletions when DEF is nil. By "reasonable" I mean correct behavio= r 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 ret= urn "". I'll try that out and see how it works.
Thanks for the insights. I guess you can close this.
--001a113fe2dae2c06f0550d0758b-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 08:23:11 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 12:23:11 +0000 Received: from localhost ([127.0.0.1]:46284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG2ec-0005oQ-U0 for submit@debbugs.gnu.org; Wed, 31 May 2017 08:23:11 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:34266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG2eb-0005oC-Cr for 27158@debbugs.gnu.org; Wed, 31 May 2017 08:23:09 -0400 Received: by mail-wm0-f46.google.com with SMTP id 123so33437081wmg.1 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 05:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X7ehj8/cDodBkvuThfBgDSMjRjdQBPmOjNZjGrB5KtU=; b=cW1KPt4kgUgO0Hw+LoUqbyYzaBQGchN1iGQRpc7sXHTNvlESTSfh+CJYegu4MQ7nRs HIhwoGw9/FfAsL2fVVIiwHGPz1b8k5fJjJDeyUM4AHf+AEtGlPKFfz15duMFldS0DPvv PaVMS7LtEDdf6L1J41Btz7qoHMvjQHnKOLgJMCZSPzaqVqKrhr8QdrvT9jZGV0wX1YZk GxO4vGZ6Z2E12aH4vJxwULCHjtK+NIgQ+4LiMiTB7n2GUDqPTd+LnYD8fCBf/0VBrMX7 V9e6Q13gOFBX2GuUj1Ns8w1K3UbicocizZwijsZxTnAED91dipLkMwyVVMw84iNxlAsB ZvdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X7ehj8/cDodBkvuThfBgDSMjRjdQBPmOjNZjGrB5KtU=; b=brUeupYpu5fVIngntrYmNUM5QmRv7uGEejUsgYm3g1Uix7sIvEvy0yGQWNGVFO3wGT H6lMZtdYcxZDgyxXwTY04F4a7jqhjoUHYaSJiqvM2sX+varUwWhJsmCKsoy9EHevDtST ZfT+R+Ju1cK3tnKjj19aDtTfuYnQfVleWS8EXiJ8C49Xu8leEHKK7a2ikS+LCvYMMJH1 ePruzOkLkj6dmdPUb2Ndt/PyzuCKQqaczLF++KbHgcwtnIriOqSv9bjarG8gQzBFzArC amNUoCHaulsNKy/PZiu4hsntk/LX2qUvRMHKeSVXQThi6VOIWzNyCCAecEJjXCDWovWp TTDw== X-Gm-Message-State: AODbwcCW+ECc898Hgl5dACtwK08+dHrwG1DUzwGFk8pa12JZSsOqyVtb t2Obyx9YlPrpyk5M0JY= X-Received: by 10.28.51.73 with SMTP id z70mr4938867wmz.65.1496233383382; Wed, 31 May 2017 05:23:03 -0700 (PDT) Received: from [192.168.0.133] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id m11sm23574213wmg.34.2017.05.31.05.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 05:23:02 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> From: Dmitry Gutov Message-ID: <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> Date: Wed, 31 May 2017 15:23:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 10:52:03 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 14:52:03 +0000 Received: from localhost ([127.0.0.1]:47551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yh-00030s-2H for submit@debbugs.gnu.org; Wed, 31 May 2017 10:52:03 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:41224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yf-000300-Ax for 27158@debbugs.gnu.org; Wed, 31 May 2017 10:52:01 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VEprOj022292 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 14:51:53 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v4VEpqri031974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 14:51:53 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4VEpqGN029317; Wed, 31 May 2017 14:51:52 GMT MIME-Version: 1.0 Message-ID: <562784bd-e22b-411d-8230-4f95fe2fa7db@default> Date: Wed, 31 May 2017 07:51:51 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> In-Reply-To: <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > Would you make a default arg be mandatory instead of optional? > > Is that it? If not, what default default would you propose? >=20 > 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? >=20 > Prohibit them from finishing completion, except through entering > a valid value, or pressing C-g. (while ) 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. >=20 > 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'? From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 10:52:04 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 14:52:04 +0000 Received: from localhost ([127.0.0.1]:47553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yh-00030w-Jp for submit@debbugs.gnu.org; Wed, 31 May 2017 10:52:04 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:43195) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yd-0002zv-CJ for 27158@debbugs.gnu.org; Wed, 31 May 2017 10:52:02 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VEpqLo004925 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 May 2017 14:51:52 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v4VEpqwr024493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 May 2017 14:51:52 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4VEpnMe029285; Wed, 31 May 2017 14:51:51 GMT MIME-Version: 1.0 Message-ID: <820b1931-918c-48c2-aca5-ed1d62d9c09a@default> Date: Wed, 31 May 2017 07:51:47 -0700 (PDT) From: Drew Adams To: Ryan Thompson , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: multipart/alternative; boundary="__1496242309564140232abhmp0012.oracle.com" X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --__1496242309564140232abhmp0012.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "" is just the default default, if you like (or not). =C2=A0 Thanks, that's actually a good way to think about it. =C2=A0 Would you make a default arg be mandatory instead of optional? Is that it?=C2=A0 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? =C2=A0 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.) =C2=A0 Today, `force' (or `abc', for that matter) does not exit IF at least some c= ompletion is performed. What you are requesting is, I guess, that it not ex= it even if no completion is performed - that it would be able to exit only = if one of the candidates is chosen. =C2=A0 That would be backward-incompatible, since today the symbol `force' means t= he same as any other non-nil, non-t REQUIRE-MATCH value. Not the end of the= world, but one consideration. =C2=A0 Today, you can just test the "" return value and re-issue the `completing-r= ead'. Do that in a loop in and you have the behavior you want, no? =C2=A0 The problem comes when implementing a completion system that returns the fi= rst 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.=20 =C2=A0 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 mak= e calls to `completing-read' always behave that way, right (see above)? =C2=A0 Sometimes this is correct, but sometimes this is wrong, as in the following= usage pattern: =C2=A0 (defun pick-a-fruit () =C2=A0 (interactive) =C2=A0 (let* ((default "banana") =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (prompt =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (format "Pick a frui= t (default %s): " default)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (collection '("apple" "ban= ana" "cherry")) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (selection =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (completing-read pro= mpt collection nil t))) =C2=A0=C2=A0=C2=A0 (when (string=3D selection "") =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (setq selection default)) =C2=A0=C2=A0=C2=A0 (message "You selected %s" selection))) =C2=A0 I don't follow. What is the behavior that you want? The above seems to be f= ine, as would be to repeatedly calli `completing-read' until the user enter= ed something (that completes). Which behavior do you want? =C2=A0 This pattern is used in e.g. Info-follow-reference. The problem is that the= re'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 defau= lt wasn't provied to completing-read, it doesn't know whether it should ret= urn the empty string or the first match.=20 =C2=A0 Do you want your completion system to obey the (outside) call to `completin= g-read' or to do its own thing of returning the first candidate on empty in= put? =C2=A0 It sounds like you have a system that wants to have an alternative completi= on behavior from what some of the possible behaviors `completing-read' prov= ides, but you also want it to (sometimes?) respect the behavior that `compl= eting-read' provides. =C2=A0 And you cannot tell when you want this and when you want that, that is, whe= n the behavior specified by the (outside) code should be respected and when= the usual behavior of your completion should be imposed instead. =C2=A0 Is that it? If so, that doesn't sound like a problem with `completing-read'= . And I don't see how letting REQUIRE-MATCH =3D `force' would change anythi= ng. IIUC, you don't have control over (outside) calls to `completing-read',= so you cannot change them to use `force' or whatever. =C2=A0 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.= =20 =C2=A0 (So does `Info-follow-reference', BTW: "No reference was specified".) =C2=A0 Raising an error on empty input is not the same thing as forcing input to b= e non-empty. Today it is easy to test for empty input (and so throw an erro= r), thanks to the default default behavior of returning "". =C2=A0 This ambiguity makes it difficult to reconcile the desired convenience feat= ure 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.=20 =C2=A0 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? =C2=A0 This doesn't sound like a problem with `completing-read'. It sounds like a = problem reconciling a one-size-fits-all convenient completion behavior (ret= urn the first candidate if no input) with (outside) code that might expect = a different behavior for empty input. =C2=A0 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 w= hether the caller is expecting that behavior (Info-follow-reference) or is = expecting it not to happen (read-char-by-name).=20 =C2=A0 Isn't that the real problem you're having: that there is no way to know whe= n to respect the caller and when to impose a different completion behavior?= How can changing `completing-read' help solve that problem? =C2=A0 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 s= tring, =C2=A0 It's normal for different calling code to expect different such behavior, n= o? And you are trying to accommodate those different expectations (at least= sometimes?), instead of overriding them, no? =C2=A0 and while not expecting the empty string might represent a bug in the calle= r,=20 =C2=A0 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 yo= ur completion system. ;-) =C2=A0 the existence of such functions makes it difficult to implement ido-style c= ompletion that does the right thing in all cases. =C2=A0 Can you give a concrete example, describing the intended behavior by the ou= tside caller, your intended behavior, and the problem you have in achieving= either one? =C2=A0 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 completion= s when DEF is nil.=20 =C2=A0 Does that do what you want? =C2=A0 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 d= on't expect completing-read to return "". I'll try that out and see how it = works. =C2=A0 Thanks for the insights. I guess you can close this. =C2=A0 No reason to be hasty in closing it. Better for us all to understand just w= hat the problem is. So far, I admit that I don't, so I can't say much that = is helpful here. --__1496242309564140232abhmp0012.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

"" is just t= he default default, if you like (or not).

<= p class=3DMsoNormal> 

Th= anks, that's actually a good way to think about it.

 

Would you make a default ar= g be mandatory instead of optional?
Is that it?  If not, what defau= lt default would you propose?
What should be returned if no explicit def= ault 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 w= ould 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= .)

 <= /p>

Today, `force' (or `abc', for that matt= er) does not exit IF at least some completion is performed. What you are re= questing 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, s= ince today the symbol `force' means the same as any other non-nil, non-t RE= QUIRE-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 y= ou have the behavior you want, no?

 

The probl= em comes when implementing a completion system that returns the first avail= able completion when pressiong RET (e.g. ido and ivy). In the case of an em= pty 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 sy= stems want/need to behave that way, but `completing-read' does not b= ehave that way out of the box? But you can make calls to `completing-read' = always behave that way, right (see above)?

 

Some= times this is correct, but sometimes this is wrong, as in the following usa= ge pattern:

 

(defun pick-a-fruit ()
=
=C2=A0 (interactive)
=C2=A0 (let* ((default "<=
span class=3Dinbox-inbox-pl-s>banana")
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 (prompt
<= pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 (format "Pic= k a fruit (default %s): " default))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 (collection '("apple&quo=
t; "banana" "c=
herry"))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (selection
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (complet=
ing-read prompt collection nil t)))
=C2=A0=C2=A0=C2=
=A0 (when (string=3D selection "")
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 (setq selec=
tion default))
=C2=A0=C2=A0=C2=A0 (message "You selec=
ted %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 t= he user entered something (that completes). Which behavior do you want?

&= nbsp;

This pattern is used in e.g. Inf= o-follow-reference. The problem is that there's no way for the completion f= unction 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 firs= t match.

 

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

 =

It sounds like you have a= system that wants to have an alternative completion behavior from what som= e of the possible behaviors `completing-read' provides, but you also want i= t 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 (outsi= de) 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 =3D `force' would change anything. IIU= C, 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= .

=  

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

 <= /span>

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 defaul= t behavior of returning "".

 

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 li= ke a problem reconciling a one-size-fits-all convenient completion behavior= (return the first candidate if no input) with (outside) code that might ex= pect a different behavior for empty input.

 

And = it's not even possible to implement an automatic fallback to completing-rea= d-default, because there's no way for the completion function to know wheth= er the caller is expecting that behavior (Info-follow-reference) or is expe= cting it not to happen (read-char-by-name). <= o:p>

 

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 th= e issue: if completing-read is called with a DEF being nil, the calling cod= e may or may not be expecting it to return the empty string,

=  

It's normal for dif= ferent calling code to expect different such behavior, no? And you are tryi= ng to accommodate those different expectations (at least sometimes?), inste= ad of overriding them, no?

 

and while not expect= ing the empty string might represent a bug in the caller,

&n= bsp;

Why suppose that? Sur= e, it's possible, but it's more likely that that's the desired behavior. Wh= en 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. ;-)

&nbs= p;

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

 

Can you give a concrete exa= mple, 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 ju= st the default default", it's possible that one might get reasonable b= ehavior for ido and ivy by taking this statement literally and prepending &= quot;" to the list of completions when DEF is nil.

&nbs= p;

Does that do what you w= ant?

 

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

<= /div>

 

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.

--__1496242309564140232abhmp0012.oracle.com-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 10:59:53 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 14:59:53 +0000 Received: from localhost ([127.0.0.1]:47570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG56H-0003CV-CZ for submit@debbugs.gnu.org; Wed, 31 May 2017 10:59:53 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:35898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG56F-0003CJ-M5 for 27158@debbugs.gnu.org; Wed, 31 May 2017 10:59:52 -0400 Received: by mail-wm0-f49.google.com with SMTP id 7so122024337wmo.1 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 07:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rv2T2gr569AEqHw6xFjM+DnNJ/3L0DF2TodqXlSJEkg=; b=XKmYl9VGKineNJiXbaB9XHA6Pj514dQqLiM08FZYVFQQHHb+/CbQ1cTSF8/qbvB9hv XrL0dlc0TS6n+SKiGAt2uC/Tr2hJWP5d3eBm7uxenya2cRmppoHx2eb/Tap9ALjbTw8B zWIxjZ3Ijty9HOMX1OKg6oN5HADEub8XbDrFj3NxHLEIgb+/WhzWUSP62565RBB6YvF4 lW2Htr9iGTmWJoMMPMhgF0a/4PQ4iPQVFZKq4ylr7w+5NYDufq5hCCQPlf7xeyTfHYeI pPw54+j145SNthFOr8a8tExVIWRBm6+zYRNq+CTX4MPAJ1WLyuuNlGnrvM3lfgq/hGgM 4TJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rv2T2gr569AEqHw6xFjM+DnNJ/3L0DF2TodqXlSJEkg=; b=uDwl2AWMRFUPI5Tyiu6Q9ip/zbD1MSQ6i5HkW7zRWqq8VxdfxaW6cm6ODXEdRu14gf gOtfe0nT3ojKerwOe0ftXGDMXe7KRFnIQz1lD1svtyJ0ssJpnS+q+0DDsqlacEG7d8Y7 RRa8s0//sxT79uuq4Ra63772KkTjZOKNZ0ILz1SxanRKJL/dkAYlMchPcj/LSUgqVOWF qvFrBoPuh36GgsAb3uTnO0XgZeNysVd2ekd9l4P4DsLUyzCEMHFKAw9nOJaMqo+0qIVb 9ooKOt9ps9I99fjbJUfj3m9uZN/FLgzSUlIimOvwlnkfUQMlYW4dGZ7BSIxHh7PEhNsp G7xw== X-Gm-Message-State: AODbwcAu4urM+iOcxwGgmBfnANCQdGRSZjijJO+idR1+KZOnZ26EnEcF TzyDL2ZSnXQUH1zfN2k= X-Received: by 10.223.170.195 with SMTP id i3mr22383285wrc.49.1496242785581; Wed, 31 May 2017 07:59:45 -0700 (PDT) Received: from [192.168.0.133] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id r29sm13695732wra.18.2017.05.31.07.59.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 07:59:44 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> From: Dmitry Gutov Message-ID: <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> Date: Wed, 31 May 2017 17:59:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <562784bd-e22b-411d-8230-4f95fe2fa7db@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) 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 ) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 11:19:21 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 15:19:21 +0000 Received: from localhost ([127.0.0.1]:47600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5P7-0003gL-Gm for submit@debbugs.gnu.org; Wed, 31 May 2017 11:19:21 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:25885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5P5-0003g7-MR for 27158@debbugs.gnu.org; Wed, 31 May 2017 11:19:20 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VFJCwr029155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 15:19:13 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4VFJCxu013536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 15:19:12 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4VFJBhh028291; Wed, 31 May 2017 15:19:12 GMT MIME-Version: 1.0 Message-ID: <3d3bc85b-31d3-4701-8acd-45591d075253@default> Date: Wed, 31 May 2017 08:19:10 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> In-Reply-To: <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I mean that having the default argument when it's not specified, is > not necessary. There is no need for "default default". >=20 > > Just because some callers might not need it does not mean that > > it is not useful for other callers. >=20 > 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 ) > > > > Is that hard? >=20 > 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 ... . > 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. >=20 > > What happens when you set `completing-read-function' to your > > `my-completing-read'? >=20 > 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? From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 11:44:34 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 15:44:34 +0000 Received: from localhost ([127.0.0.1]:47632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5nW-0004OV-6J for submit@debbugs.gnu.org; Wed, 31 May 2017 11:44:34 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:37930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5nU-0004OH-0t for 27158@debbugs.gnu.org; Wed, 31 May 2017 11:44:32 -0400 Received: by mail-it0-f52.google.com with SMTP id r63so13889627itc.1 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 08:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EESIRukJ6xS7tntLQHdvrvAG5f60waFnNE4fH1lOWcU=; b=Ufc737Txt3ykQUgbmHvotI1e8XWtvauXwNlt1WruHAcCvVmq0+EakEulAdAH/Pcm+S vREvIay9LK5VGf8e44g8nwdiI//PIg22q4JysVBFvOVGD1pv2a+GpxCOSyFRY1B8m8wU uzQRhlFYiRL+Kf/WO2Tzlbb0ur7e5MWsHM/GffakcSm791sB4Fg7QGUQZ4dPvU8aZc8Y x2Ps+Dj7BzpeDCcS6tM6twYwNDXugrRNRhHKARtIB9LKt6PjdC04qBKVhni09Yv1yt4N Gw5XzHl2gbVTfahcSdCS+1jNlim2qhNi+vmsHB9eJK9FIvc3mXjwdZEz3pRm8ZY6lNwX 5h+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EESIRukJ6xS7tntLQHdvrvAG5f60waFnNE4fH1lOWcU=; b=Cu2GkbiLa/euxfjsFRSfKpvlqXuWfZsiv5rW7LSBC+EXHDiKQNUyouWIQsq+DoLpo5 VkzAnTTRnj187KgYOlCfzPPPGYAsiSY18EDWcqvEjy1ze4hCvVqK37gkiTbIMx0xvPQ5 ztgqw4msecyioB+ee9gE77rh12jX7HtuQG4LchQNi6Hu9ggKUtfRwYBv7aWqOFewToAj mDTA3TSPPPfeHUyqRx0fwd60oQeefa/aLsTpLoqrQNRb5qCnNWlpV/slTHz2XnGL5zgO EtInZFkMQTMn4sah/2zJ7c8JPJ8EGmYbTf0fjYCJPYq58xR/0uBNotNBvOLRwTecaZHN CrCw== X-Gm-Message-State: AODbwcAFuT0aRfscAf+F6s6ZUBrw3RtcbT53w36xDOEa/5eKdkBSPWvM 3mdA6P48lk4/ZticSIo0jX/QIkgeo086 X-Received: by 10.36.53.79 with SMTP id k76mr7507181ita.71.1496245466244; Wed, 31 May 2017 08:44:26 -0700 (PDT) MIME-Version: 1.0 References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> In-Reply-To: <3d3bc85b-31d3-4701-8acd-45591d075253@default> From: Ryan Thompson Date: Wed, 31 May 2017 15:44:15 +0000 Message-ID: Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Dmitry Gutov , 27158@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a114a91f6837f7b0550d3cb5d" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a114a91f6837f7b0550d3cb5d Content-Type: text/plain; charset="UTF-8" > > 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 ... . > 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. --001a114a91f6837f7b0550d3cb5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= But if an explicit DEFAULT arg is the solution then your
completion system need only set arg DEFAULT to "" when
it is nil, no?=C2=A0 Or set it to the first completion candidate
when it is nil or "".=C2=A0 Or ... <whatever floats your boat&= gt;.

The problem is that there is no on= e solution that floats everyone's boat. Whatever you choose, someone si= nks (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. C= onsider the following two functions:
(defun pick-a-fruit<=
/span> ()
  (interactive)
  (let* ((default "banana")
         (prompt (format "Pic=
k a fruit (default %s): " default))
         (collection '("apple&q=
uot; "banana" "cherry"))
         (selection (completing-read prompt collection nil t)))
    (when (string=3D selection "")
      (setq selection default))
    (message "You selected %s"=
 selection)))
(def=
un pick-a-tool ()
  (interactive)
  (let* ((prompt "Pick a tool:=
 ")
         (collection '("hammer&=
quot; "screwdriver&qu=
ot; "drill"))
         (selection (completing-read prompt collection nil t)))
    (message "You selected %S"=
 selection)))
The fruit function expects completing-read to return a=
n empty string to indicate that the default should be used, while the tool =
function expects completing-read to always return an element from the colle=
ction no matter what. Technically, the tool function is wrong, because comp=
leting-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 ex=
pect it to work, because they don't know about this edge case, and it w=
ould be nice to be able to support them in a custom completion system witho=
ut breaking the functions that use the former pattern. As it is, you have t=
o choose one or the other to break, or else imeplement caller-dependent beh=
avior to give everyone what they expect, which is messy.
<=
span style=3D"font-family:sans-serif;white-space:normal">As I said, though,=
 treating DEF =3D nil as equivalent to DEF =3D "" might form the =
basis for an acceptable compromise. It will still break the pick-a-tool cas=
e, but it will be clearer why it's breaking, since the empty string wil=
l be presented explicitly as the first completion option. I'll test it =
out.
--001a114a91f6837f7b0550d3cb5d-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 17:21:05 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 21:21:05 +0000 Received: from localhost ([127.0.0.1]:48020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGB3B-0000tn-Cx for submit@debbugs.gnu.org; Wed, 31 May 2017 17:21:05 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGB39-0000sz-M2 for 27158@debbugs.gnu.org; Wed, 31 May 2017 17:21:03 -0400 Received: by mail-wm0-f52.google.com with SMTP id d127so35900327wmf.0 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 14:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0eCBVeZHr6a1NJEEMCxsg1PQEZLJmYEFYbGjeOVML40=; b=WHbFGKGGYPOKAvbN4cSlDz/eRapBfffKBe60cyc1U9tNkOS6q8eQyQWffa/emGoYEI ZuvmOwOvO2NSZGFUnWGIJAs2Yg0TkARNJdPRWUDVBR7WKa2v2KRCWrAG+11F1tBgSrxa gCiePVhCBE33tFRmvujSVWXw16xQ7kofoYNyaWdvCmWoubHgWZ33YEPDgl/e7VbQC2GS VCl0oTInYjX7Lo1Qn7X0iqwvu7Y6AKyi83gzcgva16dI+ZDFOssDIsss8PQzTVVlG+Qn eSYjWZGIN8GRLDErrja1mmRH7/+RRMqiIMe5xNtIVWF5UBGfhiIUI0pjtSK10UvfK/hz YjBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0eCBVeZHr6a1NJEEMCxsg1PQEZLJmYEFYbGjeOVML40=; b=PTfFSpni/zbc7UnjyjBhtc4g7eIiPRNI7xb+ffGpy5GKfoSZMPPC6Xei/+ftNTj7vh zME1F/hP9MtZ3ftvrVqjeg7YOx/WMdS0ZDeutJLnLz7dXscH5JVKyC8KHuJ0sQ1347SN kNNK5iT3sCXV/ze7cSAJqJS2gKAHnTKa1S1xsNpa2JK9h6iBoDybL+tjZsTPRU4PIdFs rfWA/k7EebKX4WtfMwQ9OmfI9SNgriMFXCVLbZK2yyxDK/9vhUwfr5rZ9Z8mKrn90CvU CapHmTmgk4imL4hfVld0zT2V63bS1R20QveBYGGHNAmaClmmSjEqfJdXZPSO5WkEq3jv jJ0w== X-Gm-Message-State: AODbwcAfrpm64TM518y/nRDr4wavPWchBFrGWcg9kW0nJhGSa8kvXwGy OFYfcXF/zNBOjlCgsDw= X-Received: by 10.28.63.209 with SMTP id m200mr6414489wma.45.1496265657537; Wed, 31 May 2017 14:20:57 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id i64sm864186wmd.33.2017.05.31.14.20.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 14:20:56 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> From: Dmitry Gutov Message-ID: Date: Thu, 1 Jun 2017 00:20:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <3d3bc85b-31d3-4701-8acd-45591d075253@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) 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 ) >>> >>> 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 ... . 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 ) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 18:41:24 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 22:41:24 +0000 Received: from localhost ([127.0.0.1]:48095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGCIu-0008Ev-EJ for submit@debbugs.gnu.org; Wed, 31 May 2017 18:41:24 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:33674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGCIt-0008Ei-2S for 27158@debbugs.gnu.org; Wed, 31 May 2017 18:41:23 -0400 Received: by mail-wm0-f54.google.com with SMTP id m7so37519958wmg.0 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 15:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1c5Xlod0Hs81eCifG2sTolUKr/JCHEj9G282N5iWESw=; b=FcwsoWQbS8CYWZYsk43oEzoVAhqyYzPzCHJTpSxHBLzQfSuPNf55D9PJUe6EhSXlU6 apVncmkxTX43SlWdm2rQqjerl4GgbcQdqyfsuL/GXyV+CE7n/oKop3nlzGQbDfClhDux frcY9b4xHNjLUVBFUHYlehatUuAYjvdUFfXrzbmtZI3ryYJpb4r7+vMj61qfWJbAMwwY zHEd7klOeDBCFITu3W+DCHVRVha56RFyG8YJigO7RtzfxRzjPuOxjcMyraTkhW24X1ul A9GrHP6tfNxVlFy5VazQ4A/Dd4YC8/0qybS/LQqx2QRz1NXzSQfhv5LMUpanYMqG7EM3 Kg9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1c5Xlod0Hs81eCifG2sTolUKr/JCHEj9G282N5iWESw=; b=RN+qjT97WkEcVwmyOeI0vNEDDWvmjVdIWdwrLF4j0Y/8LCPEkPMQHVebfETBc4wTf1 fxMsxMKc2BicEar2r+PzVikfLZZR3e9QkucX4FwGkvF1tB+BzvKI6Z+yhmNbGibqHFOp 7k/bMBC8w0nfziKHhKhwX9+BKJTrCR50lPawa/UZ+TmStKUeegWIkuRmFl5inwY5xg8j TMgurPr3w6zuy8jr6nJeD/dx+aFlpWK4uXCyyufWkvzm5OkihaeeTBNLnnNj/FwfuhnZ 7E/MBrx3ZjFhP2zu7LqvDuKFXThnaH1NbzyN8iM0kqQGFoDNk/i5j8+AKimQKcQJTJFM IrpQ== X-Gm-Message-State: AODbwcA8Qtz94sFSaeNHp5mpEoqKnpo6WI0cD5I7rNf7fCOFGdk+yKrp 0m0zW+jOOPqCJNxAjlY= X-Received: by 10.223.129.230 with SMTP id 93mr3385391wra.57.1496270476698; Wed, 31 May 2017 15:41:16 -0700 (PDT) Received: from [192.168.1.3] ([185.105.175.129]) by smtp.googlemail.com with ESMTPSA id y2sm425383wrd.23.2017.05.31.15.41.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 15:41:15 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Ryan Thompson , Drew Adams , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> From: Dmitry Gutov Message-ID: Date: Thu, 1 Jun 2017 01:41:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 19:16:18 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 23:16:18 +0000 Received: from localhost ([127.0.0.1]:48106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGCqg-0000Zj-EG for submit@debbugs.gnu.org; Wed, 31 May 2017 19:16:18 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:48698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGCqf-0000ZW-8y for 27158@debbugs.gnu.org; Wed, 31 May 2017 19:16:17 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VNGAZE015020 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 23:16:10 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v4VNGAEP010538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 23:16:10 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v4VNG75W020223; Wed, 31 May 2017 23:16:07 GMT MIME-Version: 1.0 Message-ID: <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> Date: Wed, 31 May 2017 16:16:05 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan Thompson , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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? From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 19:54:37 2017 Received: (at 27158) by debbugs.gnu.org; 31 May 2017 23:54:37 +0000 Received: from localhost ([127.0.0.1]:48141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGDRl-0001Rz-CI for submit@debbugs.gnu.org; Wed, 31 May 2017 19:54:37 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:34675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGDRj-0001Rl-2u for 27158@debbugs.gnu.org; Wed, 31 May 2017 19:54:35 -0400 Received: by mail-wm0-f52.google.com with SMTP id 123so37801512wmg.1 for <27158@debbugs.gnu.org>; Wed, 31 May 2017 16:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oM2uaniU+Gp5PdULCZO4X+rDUjRTOVy1i2T2Zdka8FE=; b=puAI5mf2O2BNYJtA+kY4ZcOkg4Fn8CoJqn4zVAyo7AiRsWGShZcdIBeq+cf0PGIqaP xQuqBAExJdMBrvhrpQYZ08Y10wO3jHL/zJeIQixzbPljL1QIl8Ad5d6lm4F7HRA+zbG2 4yVIwPmbOu7GpzLwF+gAKG6k6Urje4423UDkjx8GHjUXRO58hVmO2m3wpqKxiMPoBe7L AajlDt0eawss+dtNjjlNln2+ZRHMtVKzSXeYnq86amGoIp6LKOhAtRRoSQJehYOIaB6H aO3K7Yz8koy6W1+lTaJZRwfMiaQ/twAchZrYs1xCycuT+zzppcR+fFt1LwIi4Bt0NBsm 5JBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oM2uaniU+Gp5PdULCZO4X+rDUjRTOVy1i2T2Zdka8FE=; b=c/VMugSq4UiF8YgAWBa19L5cLMecVvISplnuCc/Ki5ggXgHgf+31Rqg7diPw1GWXW7 lYDB+XBlE+PgSJN9osyzwXBCQBKyLCZOQSfAtLQqdUQgfaZkGmKYF2K1mG92tXve7arL mChmJ+CDRgkUVpxRQSGfr6pNg95uFpVL/t4+8RFV1k+koVldhcEFlRL4dOWYNDrDCX4V sOKLriyfPeKhROcKiUGUyGsoIXFQdbjVtHO7oarJyupVjFDksyGnj5Kuquj+w7WF3QhL vDpEsW2R+DE7Wpz4jW43aj5X2b/rV5EZOaUGzhawzzXOrXyg9WVVpyEkqs09hrZlytVT l9Xw== X-Gm-Message-State: AODbwcBebSWJOB/2JomccLoP/0QHEdEJEtGvL1OfrsCxsMFoYvLc7eQ+ uiqOXAwpwjjt+317bQ0= X-Received: by 10.223.175.214 with SMTP id y22mr18941126wrd.63.1496274868993; Wed, 31 May 2017 16:54:28 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id q77sm19501303wmb.4.2017.05.31.16.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 16:54:28 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan Thompson , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> From: Dmitry Gutov Message-ID: <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> Date: Thu, 1 Jun 2017 02:54:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 22:23:28 2017 Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 02:23:28 +0000 Received: from localhost ([127.0.0.1]:48221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGFlo-0006cG-AQ for submit@debbugs.gnu.org; Wed, 31 May 2017 22:23:28 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:44152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGFlm-0006c4-OS for 27158@debbugs.gnu.org; Wed, 31 May 2017 22:23:27 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v512NJEa026847 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Jun 2017 02:23:20 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v512NHkR013803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 02:23:19 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v512NEkD030284; Thu, 1 Jun 2017 02:23:16 GMT MIME-Version: 1.0 Message-ID: <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> Date: Wed, 31 May 2017 19:23:12 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan Thompson , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> In-Reply-To: <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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'. >=20 > 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. >=20 > (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)) >=20 > 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 =3D nil to act like DEF =3D "". 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? >=20 > 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 01 05:27:15 2017 Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 09:27:15 +0000 Received: from localhost ([127.0.0.1]:48436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGMNu-0003A9-VM for submit@debbugs.gnu.org; Thu, 01 Jun 2017 05:27:15 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:35598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGMNt-00039x-9p for 27158@debbugs.gnu.org; Thu, 01 Jun 2017 05:27:13 -0400 Received: by mail-wm0-f42.google.com with SMTP id b84so150523942wmh.0 for <27158@debbugs.gnu.org>; Thu, 01 Jun 2017 02:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JSB3PCIyEFMzjKVQUocNgTfe6wInAOoG4EL7wYRKsto=; b=kb319efxMm5Srpck8Dg1BvNnbU7l+Zzt/twHPswGop9GCRtPIbsvPaqSQIMInXqrvR ndEMT3gGdPMNph5rwAzC6jWcAnF/TD0sebmOqeLUQx7UcaR/kBzTnWlA0lnd0HDPFhsM 7FqH9tRyeRYLM0ipZzTGxneKsaI4NjS4mH1TMT8vYAKJT0Q1d+crtZMIItSirSo3M3t0 mB+azky4PX4xHw2kN32yuUyz9P7vjJW6Ocl7bXVxaYRXWb7QpJDd8rns55FKQY702yi4 Cqr0mv2Pla/CnkHEA+463ZXmcnJ7xV0VqGwcVCava4pLdufCL+M7b0FybQKPV6qqtH1n GRfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JSB3PCIyEFMzjKVQUocNgTfe6wInAOoG4EL7wYRKsto=; b=ncMVcLZSjQdriVkW0bveB6zwyy5JkeXlclj2sxyRYLx9KvCUzZUlZj8DgdgjeoENET Dt8CcG0pJGzJYrRpR5Bh7YwYggcuzzcT+yBio5YkpxcaOi6XhkHS5nLuj4ruOje6OY4q iLdxTofM3M5TNTTfrp65wvhxNuNz8KJjWn0e2ii0mfy2mVUaOZ/SadiW3wL5hQLNiyg6 l1lPlYDuDX6v2EaB3cI+/BLf/v7fkunk3xfMoTlWqkyT23HRbTTS4Yn90MPcVtdzAb7s 1HOh31mMcN5+k8a2siF4M9bX5ucoJa5RCcpg/ewTsD15Yh8Yeac72MvUDjKIY8wucHCs Dfmg== X-Gm-Message-State: AODbwcBja3kQqOz9+R1tC5nXsGOt/NYPGGaf+jmypcqMYZAW5MquvMYZ Nkqs5euN4b5lJt9YnkU= X-Received: by 10.223.172.113 with SMTP id v104mr572070wrc.112.1496309227281; Thu, 01 Jun 2017 02:27:07 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 47sm1407014wrb.55.2017.06.01.02.27.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 02:27:05 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan Thompson , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> From: Dmitry Gutov Message-ID: Date: Thu, 1 Jun 2017 12:27:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 01 10:57:38 2017 Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 14:57:39 +0000 Received: from localhost ([127.0.0.1]:49831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGRXe-0006SS-L1 for submit@debbugs.gnu.org; Thu, 01 Jun 2017 10:57:38 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:36550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGRXd-0006SE-Bb for 27158@debbugs.gnu.org; Thu, 01 Jun 2017 10:57:37 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v51EvTtO012003 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 14:57:30 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v51EvTB4000585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 14:57:29 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v51EvRet024919; Thu, 1 Jun 2017 14:57:28 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 1 Jun 2017 07:57:26 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan Thompson , 27158@debbugs.gnu.org Subject: RE: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > >> (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. >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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'. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 01 16:53:39 2017 Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 20:53:39 +0000 Received: from localhost ([127.0.0.1]:50032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGX6B-00082C-2q for submit@debbugs.gnu.org; Thu, 01 Jun 2017 16:53:39 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:34399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGX69-00081y-FY for 27158@debbugs.gnu.org; Thu, 01 Jun 2017 16:53:37 -0400 Received: by mail-wm0-f48.google.com with SMTP id 123so7281821wmg.1 for <27158@debbugs.gnu.org>; Thu, 01 Jun 2017 13:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X2/8qr9OoHesDpPZHIVAvPEyhEs9tXZfVXwQv/CUNzE=; b=Asyg688U+NF3tAjSKSobiRzMKZ8bB/wRSqFxqa3FItfVRv/fnHimbKNoxOLGW2Mmcq 5jYRGpC4c+jwzVCzzNXUGFZ1Ckc8FZoJaykU3bKSBBNsIbSBsz/kxUzdX4pDlIOHuBHL lqc/DAc5HNofki41IoE1KdHTRbYx4pr/ahyrLOqlN/X/kLApC2zpsyc/ES8ESCeEu+oS Ib00Cxjz5gfNDM9H6IRV9s0i/ZfSeOnFSzkHWh9blM21xkXG3wvOfB6leDlHgvq4nRlO YMwj7szsf41dZ2EtgLMJpsNY9TdNXMazPF3pg5/feVjUTHqytqJBLYd6I+tM0sBtXijq geHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X2/8qr9OoHesDpPZHIVAvPEyhEs9tXZfVXwQv/CUNzE=; b=cNvZBlNRgM3oKKFHb2dBO0A53OvpyOqDhIoqtTBGBhq8/U2Vc062wn5H4bK6ZYkorD DwHba9+0EP4EcQdr/3E0n5Fpwq/sipGVI46z1h/MDd1qpD0wcHTSDagvlhAC14aooOBt amCucleATi7BeBpUaH9BomMSE8Fcp16OEGgYZCZWztQnJB7zv/uG2xHj+JGdJ2ow5huk hOAbY7+KvWPVnFY8hHaq/inUQ2GS+YoQBknRB+ZAQMWU9C9yETb/k66LMAXDLf4gSCoV ez4aCgYpacPO5zlf9GC8bxl1V9hu/xkeAyESqypCAad3zkI3a0nseBvnaunNJj4RUSwW oflA== X-Gm-Message-State: AODbwcC+XR2XAHtfPYuPfVvRiZMg4P9lHKriuQ+uBbc3C+e0UjeacSzU yowcleLnzLh26E0FFQY= X-Received: by 10.223.171.20 with SMTP id q20mr2573714wrc.89.1496350411308; Thu, 01 Jun 2017 13:53:31 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id l30sm14468294wre.25.2017.06.01.13.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 13:53:30 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Drew Adams , Ryan Thompson , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> From: Dmitry Gutov Message-ID: <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> Date: Thu, 1 Jun 2017 23:53:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 01 17:05:16 2017 Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 21:05:16 +0000 Received: from localhost ([127.0.0.1]:50038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGXHQ-0008Ja-7w for submit@debbugs.gnu.org; Thu, 01 Jun 2017 17:05:16 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:33486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGXHO-0008JM-RD for 27158@debbugs.gnu.org; Thu, 01 Jun 2017 17:05:15 -0400 Received: by mail-io0-f172.google.com with SMTP id b184so3177089ioe.0 for <27158@debbugs.gnu.org>; Thu, 01 Jun 2017 14:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bZz0iFQwz5npQcnFTZCmQYTX0UKAc5WNkbtQ3/SpWHQ=; b=p6ZKhaldyXqgSQtPb4iNXZTQOORwd05mAakw/ei7SCC73fXXhZWmySJquTSOcGwsyR 318qfa2GGnDlt6BI2NvEMpVzU2I1aRokdPPE6NJDcC5uoyxD5+uO7/XnatvTtS/uKcoQ Y2EYjglgHW1/aNdn9xoiv3Yfpa5mDePyudCeYJMBCSztj3Ej6yDX6Mn/vRxwi4H7SVMj lGtVmXlZ9vXf/uOaDD6kEwGpjfON0J+npAXTlccW4zPn8dVkzmD4t6A5MOvxfFEmuOPt 4ZDcFj+S7kXUTjMpYXabOOLzMxDkzbLd/0G/4yZuzzPGYnJAt8nm7FS6B2bzQhovRyWf 7dPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bZz0iFQwz5npQcnFTZCmQYTX0UKAc5WNkbtQ3/SpWHQ=; b=so383JKADYvSsK8WyZt83uF/zLkmhFHw1gcdY4cEEt3l9jf6H8NC2ttPg5083syhDA WdrLQ/gN1WiS/yT6TVPEkigSdeWdM5v+JBc916TWlFVDSsB3s9pv6UizF/Z9QR6BaxY5 0xMlsFNkIq/iL4IKWlQTfEBFgoXh43AjuIs0rYWGJTzGLzjAdCQX8iLSeUeAkZO4lBwk CRrKqv/8BaXxYgjqO0+KdTp99mDz5xIwSmSq+IxIwYTMSCrv1t5vf2EvbhEvoMQH3q+i K9sjCVlZ/Sqm+bdoYNsqfumxeSwKRcFNDfrLHcklhkgSkn4QHq7ozcEH9Pe2YznIq6/R 28tA== X-Gm-Message-State: AODbwcClafj06PmjRPhQDKbdoDoPOd46XScSYMWcIkGjrCp6IXomY1gi FH2z6ckMGqBdo3/G8NzkWbSuaVPsFZj0 X-Received: by 10.107.165.148 with SMTP id o142mr4481509ioe.179.1496351109151; Thu, 01 Jun 2017 14:05:09 -0700 (PDT) MIME-Version: 1.0 References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> In-Reply-To: <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> From: Ryan Thompson Date: Thu, 01 Jun 2017 21:04:58 +0000 Message-ID: Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Dmitry Gutov , Drew Adams , 27158@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a114928f45214490550ec64ae" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --001a114928f45214490550ec64ae Content-Type: text/plain; charset="UTF-8" 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. --001a114928f45214490550ec64ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In any case, I've come up with an experimental version= of ido-ubiquitous based on the idea of "empty string is the default d= efault". It's currently on the empty-string branch: https:/= /github.com/DarwinAwardWinner/ido-ubiquitous/tree/empty-string

=
Here's the relevant code:

= I'll be testing this out to see if it works acceptably well in all case= s. Comments welcome.
--001a114928f45214490550ec64ae-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 19:01:51 2017 Received: (at 27158) by debbugs.gnu.org; 5 Jun 2017 23:01:51 +0000 Received: from localhost ([127.0.0.1]:58243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI10Q-0008DV-V2 for submit@debbugs.gnu.org; Mon, 05 Jun 2017 19:01:51 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:35523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI10N-0008Ct-8X for 27158@debbugs.gnu.org; Mon, 05 Jun 2017 19:01:47 -0400 Received: by mail-wr0-f176.google.com with SMTP id q97so45616830wrb.2 for <27158@debbugs.gnu.org>; Mon, 05 Jun 2017 16:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TOviJvZhv2iWN/jc6MirU0rNdUQArjgVquEPFc176XA=; b=FikIQ5/+yTF1Cqvgo0ctXJTkWc6EvlgNHu9FKXavu6EfI7HAjMp8WOmsiJULbgjA/T T5SPJoCYjckzDK685JietDeq0KFG5T1eZZojFWsDjRkfR8+qTs785BlbFb0KpXjkjATY kKG56HkYbQoxTjsEgkzvuU4iujb/eSsJxrxkXsm7rL2geET67WDBF6iv9JzxoLQahpBw +ihX9a+NKSBBijz2xkZVgJepBC2mz9Dlg+r1eW89mcO/E2QhGuWtUdwvG5tfatxExzKp D22NQCaOxe+FoPM5bbWaseuxd+GAH+V/bo6vKnHwM0/Yk7+uk7fdZmDP8vDekLl0TAAv ScIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TOviJvZhv2iWN/jc6MirU0rNdUQArjgVquEPFc176XA=; b=aJQdgODXKdBb3xyIS8COTiDQkQ4EvLGan8STMCd/r4uAS9Y09eoizQileSPbp5Oq7h 8rO5/Ec28aJ+TorhHejV7c3DqxOE3DoC9y9fmbjQXuwTQ1lx9YsTv5Je1TsEyjQCJk2x OIq8x8HdE9Va4rEzly/jG3oSLT89dovRfODfum/ZkewkJBWQeLJ8KaabwuGug7ULDUHv MtWxfdDnH6DEhm1xwOuxfsBbX+yQr1d7rkuqiZM13EZ35DwxlORhK8kBF9f59UsCJNoV aIFCvkf0/o3R0gA9/MerzqV1Mt92/Qi8LrPsLR6L0FZRYEhcIHoA/NadU0bBQ7AuZuhR vKrw== X-Gm-Message-State: AODbwcBTiUGARZYZthUaaYR1THtwgBKbEABphhu1MBKmau0Ls/bUaILy OZPof/lwK64SQntWBXM= X-Received: by 10.223.182.152 with SMTP id j24mr11749438wre.122.1496703701336; Mon, 05 Jun 2017 16:01:41 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id l190sm15385766wmb.18.2017.06.05.16.01.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 16:01:40 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Ryan Thompson , Drew Adams , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> From: Dmitry Gutov Message-ID: Date: Tue, 6 Jun 2017 02:01:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 20:07:03 2017 Received: (at 27158) by debbugs.gnu.org; 6 Jun 2017 00:07:03 +0000 Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI21X-0004t0-2U for submit@debbugs.gnu.org; Mon, 05 Jun 2017 20:07:03 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:38132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI21V-0004sW-2q for 27158@debbugs.gnu.org; Mon, 05 Jun 2017 20:07:01 -0400 Received: by mail-it0-f41.google.com with SMTP id r63so94450134itc.1 for <27158@debbugs.gnu.org>; Mon, 05 Jun 2017 17:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=y4KewuLLCow8FURGRuBzIV6OTzRocyIWAyXE0IZMeDU=; b=e/eHS0d5k8dbb9PlvGFARew2LF6L8Gq0s3+Z1vMEmVlXLSvz2uTN/6nK6d5XPYpBq9 dlPaueYm+KwWquXCZnO7MRQV/rcPbH1uszMqxW7cKo2075rFfwFxJW/wA80CD5r9TKTw bjdIvPK9qWD/StQyhxSNS1V2VPu/iK0S5HaHmepBtUFjul8aveFKhCEtRbtvicxXtmj8 XL4RXckOGhIvhCiU86IQjLvcwhAKtobXSpNw7pR8k8XSukTjvkfahtceXwavN0gxfTfu S6cLnmsjWPk1dvccQFswRfIPiMNjvExKPPpGgsyoYHGCCPydRwIB4NpNAr9fd830jWpD eLBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=y4KewuLLCow8FURGRuBzIV6OTzRocyIWAyXE0IZMeDU=; b=OZEtcG2seeGVfN4LbDZIcbWEYN8xXZCJNxaVj16LTQYNt9zRIqfRxEHwLGIv22FRYU ff7ylTqV8mjCKfK+qnCvwjbIxylCL6nhYIhvgsm7DRra0HARxKfurhDiV7rU1YQ7W1Fj muQ7Zb7u06QSS27LkmPtplkiEC+PgSByLZpP/4DeoLgrGQylJhFXAk5WhPEvX2VMYZgZ 0w9SFvuMq+TS0k4njVseVTpgQGf8ERgrY9E5u7epcNMf7cSH7pcm+u+dyz1ifikOkxYr sWPu6NwZ/mE3Mgpg1QnX/pFJTBmR1hPKWaGZ5jeqfO+M6Fmkc+Oz7pBENuGVnDP5QFcw V84A== X-Gm-Message-State: AODbwcBsQ71OuyeABpA5xV/yW7DEmRKjy0SzRFDmShEp4EOP02/QcvKL HbqLOIjIm1q07Y/f3xl93MLLCY+u6ZAy X-Received: by 10.36.39.139 with SMTP id g133mr14753738ita.65.1496707615414; Mon, 05 Jun 2017 17:06:55 -0700 (PDT) MIME-Version: 1.0 References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> In-Reply-To: From: Ryan Thompson Date: Tue, 06 Jun 2017 00:06:44 +0000 Message-ID: Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Dmitry Gutov , Drew Adams , 27158@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a1147c9eabfec0505513f65ed" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a1147c9eabfec0505513f65ed Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 7:01 PM Dmitry Gutov 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. --001a1147c9eabfec0505513f65ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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?
=C2=A0
It does the same thing as completing-read-= default, which is that it allows you to enter an empty string by pressing R= ET and assumes that the calling function is expecting that to happen. In pa= rticular, this means that any code that wrongly assumed that setting REQUIR= E-MATCH would guarantee returning an element of COLLECTION is now equally b= roken in both standard completion and ido completion, as opposed to being s= puriously "fixed" by ido ignoring the spec of completing-read.

'prepend-empty-string&= #39; sounds like what I'd expect;
'append-empty-string' doesn't sounds particularly useful (what&= #39;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 co= de 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 po= ssible 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 w= ithout requiring a distinction between commands that do or do not expect th= e 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= .
--001a1147c9eabfec0505513f65ed-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 20:09:53 2017 Received: (at 27158) by debbugs.gnu.org; 6 Jun 2017 00:09:53 +0000 Received: from localhost ([127.0.0.1]:58287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI24H-0004wh-HX for submit@debbugs.gnu.org; Mon, 05 Jun 2017 20:09:53 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:37623) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI24F-0004wT-N5 for 27158@debbugs.gnu.org; Mon, 05 Jun 2017 20:09:52 -0400 Received: by mail-wm0-f54.google.com with SMTP id d73so36530472wma.0 for <27158@debbugs.gnu.org>; Mon, 05 Jun 2017 17:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yq2p5iCg7YewOfUdu0vbH1yjbgkyMm7VaYwL2uZWuQM=; b=bAkfdHqLhVHVEFQwOQONirTQIlzQ0wtkWiCYz5HIaxsNylF2ZSi4dW+XLP0JP7pbBr EbNQp4UIaDPMlZGpYCvke7/gwfk29pYJ2wn+3miwLbob6UVf/e6HmAYGOWtdY0AJCOWW yZEP6GPDJi3qD0i3ZXM/803AaroqSZPv85SM+zq+EiXEH5wq39Kmh9Ce2NW7foF5Xc81 i0WxgjrdIE8YLtAySORqocSfl3z7htGdwzZZiX2mcdZfs1s0K6Ft1L2gomb05fxM4ltm RDINij8k5fDTCgx8vVd/vOlxNmObYrN1yVrZznd3ty9bVB011pNJAJNUmyU4qqNX8Wk5 X2xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yq2p5iCg7YewOfUdu0vbH1yjbgkyMm7VaYwL2uZWuQM=; b=nTdHlQLT/5jETwUyRkf+zl5i4uZqGBshCGAoL/YQLzVPfnNIdSIQlaWo8fZbkS2mDR n6I1EdyRIDXkyH19FIq6Lj/cvkR9rCUdn3tj4O5Jh2BRfRnTNzAo4aAq8QtfOPiHMepg L7jKOxb9yc6W3d9zZWiPiBQlVVRJnAm5EB5ZKF+G9RB6sWvd/Ik1XMRIocZnfIavGjs2 eeiYRPuYlLBEvNJ7XTKtOsBlj+AzoSH8I8I8Ot+MlhNSyI43Nt6Z5Ew+Dp142aHSOL/o kIGxhWrgLlFZCDuN6q69GDzDYdyFgmEzc3BGTBCFGbfiYLG59sE6vrWtHG4R7DtC8FjR oOEA== X-Gm-Message-State: AODbwcDzAbEhcdGQ6zLkr8zlvZJOuBz5udd0VE6C38jvGxDbWqSvuZ9S fEPAM53Ik9GysKzT58A= X-Received: by 10.28.214.211 with SMTP id n202mr9384807wmg.105.1496707785783; Mon, 05 Jun 2017 17:09:45 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id h70sm16471535wma.14.2017.06.05.17.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 17:09:44 -0700 (PDT) Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files To: Ryan Thompson , Drew Adams , 27158@debbugs.gnu.org References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> From: Dmitry Gutov Message-ID: <9ce0139f-36c0-efac-067d-14b8c0e89d7e@yandex.ru> Date: Tue, 6 Jun 2017 03:09:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27158 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 10:58:46 2020 Received: (at 27158) by debbugs.gnu.org; 24 Aug 2020 14:58:46 +0000 Received: from localhost ([127.0.0.1]:58874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADvq-0002LM-1d for submit@debbugs.gnu.org; Mon, 24 Aug 2020 10:58:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADvo-0002L2-1U for 27158@debbugs.gnu.org; Mon, 24 Aug 2020 10:58:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=m8LgUliUSPvu1ZRbSWS2KcSqB9Yfb+I5Tottyxa96aA=; b=pJ5S7SaLAM1rLF/XkNsCfGqEQp 95/KbS1cjMqnpbpS7mtlK05H6oPZo+OUczT39m9+QP5tl0Js+ldAyJWByVP0+xnJavROuOXaiop8H WOZXl7cG85oJSX7QFj+/sH1ncgTv1APVQbtWndDtPCKAb8cSGIBZR2FTQKbxTubgK1s0=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kADve-0007lq-VO; Mon, 24 Aug 2020 16:58:37 +0200 From: Lars Ingebrigtsen To: Ryan Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> X-Now-Playing: Sevdaliza's _ISON_: "Human" Date: Mon, 24 Aug 2020 16:58:33 +0200 In-Reply-To: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> (Ryan's message of "Wed, 31 May 2017 00:41:57 -0400") Message-ID: <87y2m4850m.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Ryan 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 27158 Cc: 27158@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ryan 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 10:58:54 2020 Received: (at control) by debbugs.gnu.org; 24 Aug 2020 14:58:54 +0000 Received: from localhost ([127.0.0.1]:58877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADvy-0002Lk-9m for submit@debbugs.gnu.org; Mon, 24 Aug 2020 10:58:54 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADvw-0002LU-EH for control@debbugs.gnu.org; Mon, 24 Aug 2020 10:58:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7hKk/tTIE6BQmq50ST6lVCz6hIA80rZXCe41zBzi7RU=; b=iZQS/SQFSqKaSHRvn6VvDgVOVL TgIG7IKSrqCwgQR21IqCBozqHJ48uI60sADDc9BPUdjm0fbt3MKjMrIHN9xcBpipjy2dg21sWKu0F Gm7NM5Mf937IK8Tbt7xhPmTpmMDtWPsH7/f/NrfKc2sGNiu4faqHNdfL6AiFJyjqd288=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kADvo-0007m1-JL for control@debbugs.gnu.org; Mon, 24 Aug 2020 16:58:46 +0200 Date: Mon, 24 Aug 2020 16:58:43 +0200 Message-Id: <87wo1o850c.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #27158 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 27158 wontfix close 27158 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 27158 wontfix close 27158 quit From unknown Sun Aug 17 04:17:56 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 22 Sep 2020 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator