From unknown Thu Jun 19 14:06:22 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#27193 <27193@debbugs.gnu.org> To: bug#27193 <27193@debbugs.gnu.org> Subject: Status: 25.2; tmm should use completing-read-default Reply-To: bug#27193 <27193@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:06:22 +0000 retitle 27193 25.2; tmm should use completing-read-default reassign 27193 emacs submitter 27193 Ryan severity 27193 minor tag 27193 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 00:51:22 2017 Received: (at submit) by debbugs.gnu.org; 2 Jun 2017 04:51:22 +0000 Received: from localhost ([127.0.0.1]:50293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGeYQ-0007QR-Mq for submit@debbugs.gnu.org; Fri, 02 Jun 2017 00:51:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGeYM-0007QD-UQ for submit@debbugs.gnu.org; Fri, 02 Jun 2017 00:51:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGeYE-0008UJ-MY for submit@debbugs.gnu.org; Fri, 02 Jun 2017 00:51:09 -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]:39367) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dGeYE-0008UA-IW for submit@debbugs.gnu.org; Fri, 02 Jun 2017 00:51:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGeYA-0002au-Qo for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 00:51:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGeY7-0008Oj-PO for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 00:51:02 -0400 Received: from mail-qt0-x22a.google.com ([2607:f8b0:400d:c0d::22a]:33220) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGeY7-0008KF-Ci for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 00:50:59 -0400 Received: by mail-qt0-x22a.google.com with SMTP id u12so716768qth.0 for ; Thu, 01 Jun 2017 21:50:57 -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=Wk1EWYRuEMnXQYLWGdEa6qHkKQawgVnw/po22duLJ6g=; b=OnuBO3oBxoQmX7u4eGal6hQTPVrJVBJ/4y0JI/77P1SIZ2p6WAx+ctm2EeKfEFoeZv llk7GB/GOVTlyoBdgymKo5Ch5+ZaEO+R8SirLisQ9CFY3CVelGxEF6bttYT7QwpnOrdA Zoa73DMqzvDX7dKJy8OnUgs0ScO9hUEtZBODEOElfiRkUtk/Rpdwl5sKk3kaAJlvEwCm 2/4fSdm3GEO3fKvBE/DVD14UNNjTz9RAS7uCsdXgpJ7ewRgysGkI/LySnRHjUqvQJijz o5ttYmKhmtg2IcQBksZEb6kqu0w04XbP6oZXhZlsOTJcGWIBwq0o1fDL3pxx6cdKiCez rD5g== 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=Wk1EWYRuEMnXQYLWGdEa6qHkKQawgVnw/po22duLJ6g=; b=ngXKwHiijOV31cPFdouYbbjqFQP9mRZnj9/9jNr9cSr0KTGtenIs4xPbKM9H6laHsT Rz4WtmDU57HpTkJeNK2yQimQclTZLv6Ix71tQ2fIW6ZF2yR3tfDwWX8OZfj15k8I38hh zgNaOx8oTukwaQdfuwg4+kpNj7SSfInXj/Y8lWrpcuYMij/mqw752ZY23O2g4uwCNncB IKkBemV9186Gvpc9j3uVtC5CL5etuumgpH9BzsTgYL1pOZiagM0kc+RUgkRPZxwNPBVP R7Iki3yMYLd6tJmw4mmWj2tLE689Qfsh0/rizCTAbULYr2hNFOaad4K//Gvd96C8L1vH bF6g== X-Gm-Message-State: AODbwcAfPhnVR+mqJBtBLfbV9f6wczwDEpov91UnKWqWgmvhWflHBQ1S J4G4WvAreS0cQmsOWvyWBQ== X-Received: by 10.200.39.93 with SMTP id h29mr6204998qth.76.1496379056805; Thu, 01 Jun 2017 21:50:56 -0700 (PDT) Received: from techne-2.local ([2601:194:8281:252f:59f9:d07b:1c1a:e2c]) by smtp.googlemail.com with ESMTPSA id u51sm14539513qta.56.2017.06.01.21.50.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 21:50:55 -0700 (PDT) To: bug-gnu-emacs@gnu.org Subject: 25.2; tmm should use completing-read-default From: Ryan Message-ID: Date: Fri, 2 Jun 2017 00:50:52 -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: 8bit 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 (-----) Below is a patch (formatted using "git format-patch") to avoid using "completing-read" in tmm, instead using "completing-read-default" directly. The rationale is explained in the commit message. Briefly: tmm already pretty much relies on the assumption that completing-read is actually calling completing-read-default. From f184717f9f025a7edc8a015404fef9770233164a Mon Sep 17 00:00:00 2001 From: "Ryan C. Thompson" Date: Fri, 2 Jun 2017 00:34:41 -0400 Subject: [PATCH] Use completing-read-default in tmm-prompt tmm uses completing-read, but it customizes its behavior so much that any alternative completing-read-function will almost certainly break it. For example, both ido-ubiquitous and ivy have special code to deactivate themselves for tmm. Since tmm is effectively imeplementing its own completion system, it should not depend on the value of completing-read-function. * lisp/tmm.el (tmm-prompt): Use completing-read-default instead of completing-read --- lisp/tmm.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/tmm.el b/lisp/tmm.el index c6830903e3..8755971d7c 100644 --- a/lisp/tmm.el +++ b/lisp/tmm.el @@ -247,7 +247,7 @@ Its value should be an event that has a binding in MENU." ;; candidates in the order they are shown on ;; the menu bar. So pass completing-read the ;; reversed copy of the list. - (completing-read + (completing-read-default (concat gl-str " (up/down to change, PgUp to menu): ") (tmm--completion-table (reverse tmm-km-list)) nil t nil -- 2.13.0 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: Magit Log Minor modes in effect: crm-custom-mode: t 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 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 diff-auto-refine-mode: t magit-auto-revert-mode: t global-git-commit-mode: t async-bytecomp-package-mode: t autopair-global-mode: t show-paren-mode: t global-auto-complete-mode: t override-global-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 buffer-read-only: t line-number-mode: t transient-mark-mode: t Recent messages: Git finished [2 times] [C-t] show common commands, [?] describe events, [C-h i] show manual Error during redisplay: (jit-lock-function 1) signaled (error "Can’t find the beginning of the file") Error during redisplay: (jit-lock-function 501) signaled (error "Can’t find the beginning of the file") Mark set [2 times] Saved text until "rse tmm-km-list)) nil t nil -- 2.13.0 " 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 whitespace tmm debug dabbrev colir ivy ivy-overlay ffap crm-custom tabify imenu tramp-cmds tramp-cache webjump woman man eieio-opt speedbar sb-image ezimage dframe misearch multi-isearch recentf tree-widget conf-mode sgml-mode org-eldoc sh-script smie org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m jka-compr vc-git flymake 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 diff-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 subr-x el-get-custom el-get-core autoload dired creole-mode 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 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 1730483 82461) (symbols 48 58102 0) (miscs 40 14562 7947) (strings 32 631042 30932) (string-bytes 1 7897000) (vectors 16 90902) (vector-slots 8 2215255 233733) (floats 8 1475 4347) (intervals 56 51527 3760) (buffers 976 169)) From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 11:26:44 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 15:26:44 +0000 Received: from localhost ([127.0.0.1]:51733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGoTM-0007a2-Ag for submit@debbugs.gnu.org; Fri, 02 Jun 2017 11:26:44 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:40672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGoTK-0007Zm-0H for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 11:26:42 -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 v52FQYju006588 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 15:26:35 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v52FQYrS010400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 15:26:34 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v52FQXcM011797; Fri, 2 Jun 2017 15:26:34 GMT MIME-Version: 1.0 Message-ID: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> Date: Fri, 2 Jun 2017 08:26:32 -0700 (PDT) From: Drew Adams To: Ryan , 27193@debbugs.gnu.org Subject: RE: bug#27193: 25.2; tmm should use completing-read-default References: 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: 27193 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 (--) > Below is a patch (formatted using "git format-patch") to avoid using > "completing-read" in tmm, instead using "completing-read-default" > directly. The rationale is explained in the commit message. Briefly: > tmm already pretty much relies on the assumption that completing-read > is actually calling completing-read-default. >=20 > tmm uses completing-read, but it customizes its behavior so much that > any alternative completing-read-function will almost certainly break > it. For example, both ido-ubiquitous and ivy have special code to > deactivate themselves for tmm. Since tmm is effectively imeplementing > its own completion system, it should not depend on the value of > completing-read-function. I don't understand that argument. (But to be clear, I don't really care much about `tmm'.) I don't see that that is an argument for _preventing_ the use of a `completing-read-function' by tmm. I see it only as a statement that it might not be helpful to use some particular values of `completing-read-function' with tmm. If there is a general problem then consider adding a comment in `tmm.el' (or perhaps put it in some doc string) that says what you are really saying: Some values of `completing-read-function' might not be helpful with `tmm', and if you find that is the case, consider binding that variable to nil. But now that I've taken a quick look (just now) at the use by tmm of `completing-read', I don't see that there is a problem to be fixed in `tmm.el'. I don't see that its use of `completing-read' is particularly exotic or problematic. This is it: (completing-read (concat gl-str " (up/down to change, PgUp to menu): ") (tmm--completion-table (reverse tmm-km-list)) nil t nil (cons 'tmm--history (- (* 2 history-len) index-of-default))) I don't see anything at all unusual about that. And the collection function, `tmm--completion-table', is likewise pretty ordinary, I think: (defun tmm--completion-table (items) (lambda (string pred action) (if (eq action 'metadata) =09'(metadata (display-sort-function . identity)) (complete-with-action action items string pred)))) You say: > tmm already pretty much relies on the assumption that > completing-read is actually calling completing-read-default. I don't see any evidence of that. This kind of argument could (inappropriately, IMO) be applied to any number of completely normal uses of `completing-read'. I see no reason to impose a dichotomy of either a `completing-read-function' similar to yours or else `completing-read-default'. There are likely other benign values of the variable, besides just `completing-read-default'. It sounds like (and no, I haven't looked into it; it just sounds like it) you have some particular `completing-read-function' values in mind, which you have found are incompatible with tmm's use of `completing-read'. If so, that's not an argument for preventing the use of other values of `completing-read-function' with tmm. (Clearly the value `completing-read-default' is fine, for instance.) That's not an argument for tmm to do something to prevent all use of `completing-read-function'. Instead, it's an argument for the code that defines and uses a particular `completing-read-function' to take care of the contexts where it makes sense, and to stop itself from being used in other contexts, where it might cause trouble. Only that code knows the kinds of context where its own `completing-read-function' makes sense and where it does not. Code such as tmm should not try to guess what kinds of trouble different values of `completing-read-function' might cause. I don't think tmm should throw up its hands and say, "Gee, there might be some values of `completing-read-function' that are troublesome, so let's just prevent all use of that variable." That doesn't make sense, to me. If you want additional suggestions, maybe describe just what the problem is that your completion function causes for tmm. It's hard to offer suggestions if you only state that it is incompatible, without going into any detail. (Not that you must ask for input about this. But if you would like some then giving more detail might help.) Please use your own judgment (as I said, I don't really care much about `tmm'), but a priori this sounds like overkill. It sounds a bit like trying to bend Emacs to fit your `completing-read-function'. I can understand such a motivation, believe me; I don't ascribe a bad intention to you. A guess is that you are not sure what to do, to prevent inappropriate application of your value of `completing-read-function' in this or that context. If you think it causes trouble in some contexts, or it is not able to handle some contexts properly, then I'd suggest you consider walling it off from those use cases. It might take some time to discover which contexts it causes trouble for, but that's OK - you could add them as you discover them. Tmm sounds like a start. The right approach, IMO, is to teach your code when to use its `completing-read-function' and when not to use it. Put differently, consider teaching your `completing-read-function' when and where to hold back and just punt to the default behavior. It's obvious that it is possible for someone to create a `completing-read-function' that causes trouble here or there. But such trouble is up to the causer to fix or tame. The approach of preventing code like `tmm.el' from=20 letting other code use `completing-read-function' does not look like it heads in the right direction. But mine is just one opinion. I ask only that you think some more about this. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 13:37:37 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 17:37:37 +0000 Received: from localhost ([127.0.0.1]:51844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGqW0-00048R-PO for submit@debbugs.gnu.org; Fri, 02 Jun 2017 13:37:37 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:37174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGqVz-00048E-B6 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 13:37:36 -0400 Received: by mail-it0-f49.google.com with SMTP id m47so25111797iti.0 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 10:37:35 -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=DKmsyb0RIEW/mEVjt04zuweYOQNxwNIcSHCM+82o0JE=; b=DqDDyjEusd37A7OlhaLuU0KJLbSa2HW62C/7REUnNjeqM7I2EcPWkzJT8fyM+Czb4y 6/l7/OB2hugA81y+xVv+x4CpinHjOja/FasYvspByh2PX+4sSoM/vlCm1xSRo8aLv342 k+RVU89ktsXu90SSQPFGCcxVTe0EHpmGgRUI+wStxw677NY0C6D1fOkb2iR+asQ1nBV7 5Hqgg72doMgcLMVtY1bPoUuNGoUTvzWRc6Y6yNMkxWBdlNZQv8SvjmEqNWaZQ1gUfA6R /DKT5VZDMPYfACgK0JGj5hpat2o2a4vsrs6J/EWtcTY8GtsdqvyQ1ydQy+IdzU00N1lq LrlQ== 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=DKmsyb0RIEW/mEVjt04zuweYOQNxwNIcSHCM+82o0JE=; b=kjrfA0kWp8dKohu+Ic1rpjAK2NFeF55K/qz99a7UH81OdpMkvRPto94YSHIW7tcP0t TDqxQo7MnoQax9wjDe55nDdWxalBZH6MqB0rU80NXb98VjRtHzjRjUn6yZAQp2drXPUj uuOzPp0qJnJPa7S0+YcUK1BGjnY/KLUl7ccc6pxTWa3wOn1o8RcLLC4lZQ8HNtPwuUyZ pUaSnLvjK+50F86tHO98sZ1B89Jig023x5jXw1dnaoOHndBFTBMqHdXLB/uLhGXegPr1 O98WlIIgaKsk4b1IgzbhBxoyRRZcoqb2qfmxJOoMBSXNVwkZWjO2cmIrGeZzWD1Emggx nvxQ== X-Gm-Message-State: AODbwcC4Lzg74EmUuLAu1NzDn77KOyNo4B4DUKa1z+ejB1kCPEtULxgb jmLORTjqGEPgPtAWHDP9VAZYl6IkeVd6 X-Received: by 10.107.25.203 with SMTP id 194mr8870399ioz.182.1496425049496; Fri, 02 Jun 2017 10:37:29 -0700 (PDT) MIME-Version: 1.0 References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> In-Reply-To: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> From: Ryan Thompson Date: Fri, 02 Jun 2017 17:37:18 +0000 Message-ID: Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , 27193@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113fe2da82342f0550fd9bbc" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27193 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 (/) --001a113fe2da82342f0550fd9bbc Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 11:26 AM Drew Adams wrote: > I don't understand that argument. (But to be clear, I don't > really care much about `tmm'.) > Fair enough. My post certainly assumes quite a bit familiarity with tmm. I'm happy to elaborate below. > I don't see that that is an argument for _preventing_ the > use of a `completing-read-function' by tmm. I see it > only as a statement that it might not be helpful to use > some particular values of `completing-read-function' with > tmm. > > If there is a general problem then consider adding a > comment in `tmm.el' (or perhaps put it in some doc > string) that says what you are really saying: Some > values of `completing-read-function' might not be > helpful with `tmm', and if you find that is the case, > consider binding that variable to nil. > > But now that I've taken a quick look (just now) at the > use by tmm of `completing-read', I don't see that there > is a problem to be fixed in `tmm.el'. I don't see that > its use of `completing-read' is particularly exotic or > problematic. This is it: > > (completing-read > (concat gl-str " (up/down to change, PgUp to menu): ") > (tmm--completion-table (reverse tmm-km-list)) nil t nil > (cons 'tmm--history (- (* 2 history-len) index-of-default))) > > I don't see anything at all unusual about that. > > And the collection function, `tmm--completion-table', > is likewise pretty ordinary, I think: > > (defun tmm--completion-table (items) > (lambda (string pred action) > (if (eq action 'metadata) > '(metadata (display-sort-function . identity)) > (complete-with-action action items string pred)))) > > You say: > > > tmm already pretty much relies on the assumption that > > completing-read is actually calling completing-read-default. > > I don't see any evidence of that. > tmm's weirdness is not in the actual call to completing-read. That completing-read call is wrapped by "(minibuffer-with-setup-hook #'tmm-add-prompt ...)", which in turn calls tmm-define-keys, which sets up a bunch of non-standard key bindings, which have the effect of implementing a menu system with single-keypress activation of menu items, rather than completion of a substring with string matching. The result is not even recognizable as completing-read. The use of completing-read is merely an implementation detail in a system that is *not* actually doing completion of any kind. So pluggable completion backends don't make any sense for tmm, and I can't imagine any other value of completing-read-function that would make sense for tmm besides completing-read-default. Looking at the "git blame" output for tmm, that call to completing-read has definitely not been updated since completing-read-function was introduced except for minor bugfixes, so it makes sense that tmm would be expecting one and only one implementation of completing-read. > This kind of argument could (inappropriately, IMO) be > applied to any number of completely normal uses of > `completing-read'. > > I see no reason to impose a dichotomy of either a > `completing-read-function' similar to yours or else > `completing-read-default'. There are likely other > benign values of the variable, besides just > `completing-read-default'. > I'm not trying to set a general precedent here. tmm is the only code that I'm aware of that uses completing-read in this way. It sounds like (and no, I haven't looked into it; > it just sounds like it) you have some particular > `completing-read-function' values in mind, which > you have found are incompatible with tmm's use of > `completing-read'. > The alternative completing-read-function providers that I am aware of are of are ido-ubiquitous (written by me), ivy, and helm. I'll also include icicles, even though uses some other mechanism besides modifying completing-read-function. ido-ubiquitous and ivy both have code to deactivate themselves when completing-read is called by tmm because otherwise their completion systems would break it, while icicles and helm simply break tmm when enabled. Thus, to my knowledge there is currently no other completing-read-function that doesn't break tmm (except for those that make exceptions specifically for tmm). If so, that's not an argument for preventing the use of > other values of `completing-read-function' with tmm. > (Clearly the value `completing-read-default' is fine, > for instance.) That's not an argument for tmm to do > something to prevent all use of `completing-read-function'. > > Instead, it's an argument for the code that defines and > uses a particular `completing-read-function' to take > care of the contexts where it makes sense, and to stop > itself from being used in other contexts, where it might > cause trouble. > > Only that code knows the kinds of context where its own > `completing-read-function' makes sense and where it does > not. Code such as tmm should not try to guess what kinds > of trouble different values of `completing-read-function' > might cause. > > I don't think tmm should throw up its hands and say, "Gee, > there might be some values of `completing-read-function' > that are troublesome, so let's just prevent all use of > that variable." That doesn't make sense, to me. > Based on my explanation above, that is precisely what I think tmm should do: avoid using completing-read-function entirely. To look at it another way, tmm was originally written to use completing-read as an implementation detail, and later the function that used to be called completing-read was renamed to completing-read-default, but tmm was never updated to use the new name. This patch rectifies that. > If you want additional suggestions, maybe describe just > what the problem is that your completion function causes > for tmm. It's hard to offer suggestions if you only > state that it is incompatible, without going into any > detail. (Not that you must ask for input about this. > But if you would like some then giving more detail might > help.) > > Please use your own judgment (as I said, I don't really > care much about `tmm'), but a priori this sounds like > overkill. > > It sounds a bit like trying to bend Emacs to fit your > `completing-read-function'. I can understand such a > motivation, believe me; I don't ascribe a bad intention > to you. A guess is that you are not sure what to do, > to prevent inappropriate application of your value of > `completing-read-function' in this or that context. > > If you think it causes trouble in some contexts, or it > is not able to handle some contexts properly, then > I'd suggest you consider walling it off from those use > cases. It might take some time to discover which > contexts it causes trouble for, but that's OK - you > could add them as you discover them. Tmm sounds like > a start. > The right approach, IMO, is to teach your code when to > use its `completing-read-function' and when not to use > it. Put differently, consider teaching your > `completing-read-function' when and where to hold back > and just punt to the default behavior. > This is exactly how ido-ubiquitous and ivy both currently work: they essentially have a blacklist of callers for which they revert to standard completion. tmm is on the blacklist for both packages. Certainly, for any alternative completion system there will be cases where it needs to fall back to standard completion. In my view, the completion system should be able to determine purely based on the calling context (i.e. its arguments and any relevant dynamically-bound variables) whether or not it needs to punt. Making this decision based on the name of the caller instead of the context to make this decision is admitting that not enough context was provided. I view it as a workaround, not a desirable design pattern, and someday in the future I hope to be able to remove the blacklist from ido-ubiquitous. In the case of tmm, the best heuristic I can think of would be to inspect the key bindings of all the letters and numbers. If any of them are locally rebound in the minibuffer to something other than self-insert-command, then punt. However, this doesn't work in practice because the bindings happen in minibuffer-setup-hook, so putting a check at the front of this hook is too early, and putting it at the end is too late because (in the case of ido-ubiquitous) an error is triggered before reaching the end of the hook. This was partly my motivation for suggesting the change in tmm rather than working around it in ido-ubiquitous: because the blacklist approach is the only way for ido-ubiquitous to fix it. It's obvious that it is possible for someone to create > a `completing-read-function' that causes trouble here > or there. But such trouble is up to the causer to fix > or tame. > For the reasons described above, I would be very surprised if there was *any* alternative completion system that didn't break tmm. The approach of preventing code like `tmm.el' from > letting other code use `completing-read-function' does > not look like it heads in the right direction. But > mine is just one opinion. I ask only that you think > some more about this. > As mentioned above, tmm is the only code I'm aware of that does anything like this, and I don't see this as a general approach to be applied anywhere else. Hopefully the above clarifies my rationale in proposing this change. --001a113fe2da82342f0550fd9bbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Jun 2, 2017 at 11:26 AM Drew Adams <drew.adams@oracle.com> wrote:
I don't understand that argument.=C2=A0 (But to be clear, I do= n't
really care much about `tmm'.)
=C2=A0
Fa= ir enough. My post certainly assumes quite a bit familiarity with tmm. I= 9;m happy to elaborate below.
=C2=A0
I don't see that that is an argument for _preventing_ the
use of a `completing-read-function' by tmm.=C2=A0 I see it
only as a statement that it might not be helpful to use
some particular values of `completing-read-function' with
tmm.

If there is a general problem then consider adding a
comment in `tmm.el' (or perhaps put it in some doc
string) that says what you are really saying: Some
values of `completing-read-function' might not be
helpful with `tmm', and if you find that is the case,
consider binding that variable to nil.

But now that I've taken a quick look (just now) at the
use by tmm of `comple= ting-read', I don't see that there
is a problem to be fixed in `= tmm.el'.=C2=A0 I don't see that
its use of `completing-read'= is particularly exotic or
problematic.=C2=A0 This is it:

(comple= ting-read
=C2=A0(concat gl-str " (up/down to change, PgUp to menu):= ")
=C2=A0(tmm--completion-table (reverse tmm-km-list)) nil t nil=C2=A0(cons 'tmm--history (- (* 2 history-len) index-of-default)))
I don't see anything at all unusual about that.

And the col= lection function, `tmm--completion-table',
is likewise pretty ordina= ry, I think:

(defun tmm--completion-table (items)
=C2=A0 (lambda = (string pred action)
=C2=A0 =C2=A0 (if (eq action 'metadata)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 '(metadata (display-sort-function . identity))=
=C2=A0 =C2=A0 =C2=A0 (complete-with-action action items string pred))))=

You say:

> tmm already pretty much relies on the assumpti= on that
> completing-read is actually calling completing-read-default= .

I don't see any evidence of that.

tmm's weirdness is not in the actual call to completing-read. T= hat completing-read call is wrapped by "(minibuffer-with-setup-hook #&= #39;tmm-add-prompt ...)", which in turn calls=C2=A0tmm-define-keys, wh= ich sets up a bunch of non-standard key bindings, which have the effect of = implementing a menu system with single-keypress activation of menu items, r= ather than completion of a substring with string matching. The result is no= t even recognizable as completing-read. The use of completing-read is merel= y an implementation detail in a system that is *not* actually doing complet= ion of any kind. So pluggable completion backends don't make any sense = for tmm, and I can't imagine any other value of completing-read-functio= n that would make sense for tmm besides completing-read-default. Looking at= the "git blame" output for tmm, that call to completing-read has= definitely not been updated since completing-read-function was introduced = except for minor bugfixes, so it makes sense that tmm would be expecting on= e and only one implementation of completing-read.


This kind of argument coul= d (inappropriately, IMO) be
applied to any number of completely normal u= ses of
`completing-read'.

I see no reason to impose a dichoto= my of either a
`completing-read-function' similar to yours or else`completing-read-default'.=C2=A0 There are likely other
benign val= ues of the variable, besides just
`completing-read-default'.

I'm not trying to set a general precedent = here. tmm is the only code that I'm aware of that uses completing-read = in this way.

It sounds like (and no, I haven't looked into it;
it just so= unds like it) you have some particular
`completing-read-function' va= lues in mind, which
you have found are incompatible with tmm's use o= f
`completing-read'.

The alterna= tive completing-read-function providers that I am aware of are of are ido-u= biquitous (written by me), ivy, and helm. I'll also include icicles, ev= en though uses some other mechanism besides modifying completing-read-funct= ion. ido-ubiquitous and ivy both have code to deactivate themselves when co= mpleting-read is called by tmm because otherwise their completion systems w= ould break it, while icicles and helm simply break tmm when enabled. Thus, = to my knowledge there is currently no other completing-read-function that d= oesn't break tmm (except for those that make exceptions specifically fo= r tmm).

If so, that's not an argument for preventing the use of
other val= ues of `completing-read-function' with tmm.
(Clearly the value `comp= leting-read-default' is fine,
for instance.)=C2=A0 That's not an= argument for tmm to do
something to prevent all use of `completing-read= -function'.

Instead, it's an argument for the code that defi= nes and
uses a particular `completing-read-function' to take
care= of the contexts where it makes sense, and to stop
itself from being use= d in other contexts, where it might
cause trouble.

Only that code= knows the kinds of context where its own
`completing-read-function'= makes sense and where it does
not.=C2=A0 Code such as tmm should not tr= y to guess what kinds
of trouble different values of `completing-read-fu= nction'
might cause.

I don't think tmm should throw up it= s hands and say, "Gee,
there might be some values of `completing-re= ad-function'
that are troublesome, so let's just prevent all use= of
that variable."=C2=A0 That doesn't make sense, to me.

Based on my explanation above, that is preci= sely what I think tmm should do: avoid using completing-read-function entir= ely. To look at it another way, tmm was originally written to use completin= g-read as an implementation detail, and later the function that used to be = called completing-read was renamed to completing-read-default, but tmm was = never updated to use the new name. This patch rectifies that.
=C2= =A0
If you want addi= tional suggestions, maybe describe just
what the problem is that your co= mpletion function causes
for tmm.=C2=A0 It's hard to offer suggestio= ns if you only
state that it is incompatible, without going into any
= detail.=C2=A0 (Not that you must ask for input about this.
But if you wo= uld like some then giving more detail might
help.)

Please use you= r own judgment (as I said, I don't really
care much about `tmm')= , but a priori this sounds like
overkill.

It sounds a bit like tr= ying to bend Emacs to fit your
`completing-read-function'.=C2=A0 I c= an understand such a
motivation, believe me; I don't ascribe a bad i= ntention
to you.=C2=A0 A guess is that you are not sure what to do,
t= o prevent inappropriate application of your value of
`completing-read-fu= nction' in this or that context.

If you think it causes trouble = in some contexts, or it
is not able to handle some contexts properly, th= en
I'd suggest you consider walling it off from those use
cases.= =C2=A0 It might take some time to discover which
contexts it causes trou= ble for, but that's OK - you
could add them as you discover them.=C2= =A0 Tmm sounds like
a start.=C2=A0

The right approach, IMO, is to teach your code= when to
use its `completing-read-function' and when not to use
i= t.=C2=A0 Put differently, consider teaching your
`completing-read-functi= on' when and where to hold back
and just punt to the default behavio= r.

This is exactly how ido-ubiquitous a= nd ivy both currently work: they essentially have a blacklist of callers fo= r which they revert to standard completion. tmm is on the blacklist for bot= h packages. Certainly, for any alternative completion system there will be = cases where it needs to fall back to standard completion. In my view, the c= ompletion system should be able to determine purely based on the calling co= ntext (i.e. its arguments and any relevant dynamically-bound variables) whe= ther or not it needs to punt. Making this decision based on the name of the= caller instead of the context to make this decision is admitting that not = enough context was provided. I view it as a workaround, not a desirable des= ign pattern, and someday in the future I hope to be able to remove the blac= klist from ido-ubiquitous.

In the case of tmm, the= best heuristic I can think of would be to inspect the key bindings of all = the letters and numbers. If any of them are locally rebound in the minibuff= er to something other than self-insert-command, then punt. However, this do= esn't work in practice because the bindings happen in minibuffer-setup-= hook, so putting a check at the front of this hook is too early, and puttin= g it at the end is too late because (in the case of ido-ubiquitous) an erro= r is triggered before reaching the end of the hook. This was partly my moti= vation for suggesting the change in tmm rather than working around it in id= o-ubiquitous: because the blacklist approach is the only way for ido-ubiqui= tous to fix it.

It's obvious that it is possible for someone to create
a = `completing-read-function' that causes trouble here
or there.=C2=A0 = But such trouble is up to the causer to fix
or tame.

For the reasons described above, I would be very surprised= if there was *any* alternative completion system that didn't break tmm= .

The= approach of preventing code like `tmm.el' from
letting other code u= se `completing-read-function' does
not look like it heads in the rig= ht direction.=C2=A0 But
mine is just one opinion.=C2=A0 I ask only that = you think
some more about this.
=C2=A0
As= mentioned above, tmm is the only code I'm aware of that does anything = like this, and I don't see this as a general approach to be applied any= where else.=C2=A0

Hopefully the above clarifies my= rationale in proposing this change.
--001a113fe2da82342f0550fd9bbc-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 16:46:04 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 20:46:05 +0000 Received: from localhost ([127.0.0.1]:51948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGtSO-0008R1-3v for submit@debbugs.gnu.org; Fri, 02 Jun 2017 16:46:04 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:35337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGtSL-0008QI-0h for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 16:46:02 -0400 Received: by mail-it0-f54.google.com with SMTP id m62so17639064itc.0 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 13:46:00 -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=1KzOCvn2v7WrI+iAiqhX9miXOTq/QGMI74yt+9Btnl4=; b=Eo9DBlu8s/ApM3nQkCa7eTkpDcSxf1HDoBNVQrpC0XnGEpuKvewWYvEXZ5z3icYLJG r4zK6MBYt1dkTyluIjumLP8MUDjUNb8QPTpAw20xl/jokg2UhLOByQQ+YHpJIQ21us5F kUR65utpnS6VJilp2B+0oq3/CuHOq/GrhLRsjnzX0yTNOYZJxuxAN6CAKXsHHrfuqu7J wMuK5IH301cfiDS936du+MEwnT27EAre8DnnT0AaxUurRYaKaAiw39+ogSZJRsnKzsGU bjVNAAFMFXQSmppPxzaT/eduk+aGPd/fH8RNf4wyM0CYZIlMiYw9g3eS0QIYImjTPilK 6CHQ== 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=1KzOCvn2v7WrI+iAiqhX9miXOTq/QGMI74yt+9Btnl4=; b=pFLSOAOsdnuU4UG1DIjaK18xldalrJVZoVrWuN1dFXyXn/9+Z29ckU2+wP1XOByuIa MO51jMTMFv14+A0LQqGhyq2QqI5ZSY3SMfnpWYNRLyUhBrjFuvSj82cVOYyKOs/7xSM3 PWQt5xMt5XZ4dIRHqqX6cJQdbzgSueday+F4wFiQVHzvoq1CTLwwP8GlZsk1JozJ7zXl 1KdXJ0bkogyRaWkCldduNZov7L8n96S8DII3nqTcnOII961VWXDpjkRAw8APRBlvkVO6 EwPazCR88kOXQlighU3twE+SK9KhkqMRB+pYu+Iu57aau7V0nzILfFk+Edy7zVQv8fYY 3QbQ== X-Gm-Message-State: AODbwcBM3Qc6RQnvDsza4vybPjHIZTZPV2lMJqk/l68XlvyMtINy1k4C fMFKmKLb8wOoCihHacGwfBlNkxZlL3j/ X-Received: by 10.107.135.20 with SMTP id j20mr10072332iod.56.1496436355094; Fri, 02 Jun 2017 13:45:55 -0700 (PDT) MIME-Version: 1.0 References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> In-Reply-To: From: Ryan Thompson Date: Fri, 02 Jun 2017 20:45:44 +0000 Message-ID: Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , 27193@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113f8e7a5ff86f0551003dd2" X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 27193 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 (/) --001a113f8e7a5ff86f0551003dd2 Content-Type: text/plain; charset="UTF-8" I should revise what I said slightly. Alternate completion implementations might never be able to do away completely with blacklists, because things like read-file-name also use completing-read. Still, I stand by my statement that nothing else I'm aware of uses completing-read in the same way as tmm. On Fri, Jun 2, 2017 at 1:37 PM Ryan Thompson wrote: > On Fri, Jun 2, 2017 at 11:26 AM Drew Adams wrote: > >> I don't understand that argument. (But to be clear, I don't >> really care much about `tmm'.) >> > > Fair enough. My post certainly assumes quite a bit familiarity with tmm. > I'm happy to elaborate below. > > >> I don't see that that is an argument for _preventing_ the >> use of a `completing-read-function' by tmm. I see it >> only as a statement that it might not be helpful to use >> some particular values of `completing-read-function' with >> tmm. >> >> If there is a general problem then consider adding a >> comment in `tmm.el' (or perhaps put it in some doc >> string) that says what you are really saying: Some >> values of `completing-read-function' might not be >> helpful with `tmm', and if you find that is the case, >> consider binding that variable to nil. >> >> But now that I've taken a quick look (just now) at the >> > use by tmm of `completing-read', I don't see that there >> is a problem to be fixed in `tmm.el'. I don't see that >> its use of `completing-read' is particularly exotic or >> problematic. This is it: >> >> (completing-read >> (concat gl-str " (up/down to change, PgUp to menu): ") >> (tmm--completion-table (reverse tmm-km-list)) nil t nil >> (cons 'tmm--history (- (* 2 history-len) index-of-default))) >> >> I don't see anything at all unusual about that. >> >> And the collection function, `tmm--completion-table', >> is likewise pretty ordinary, I think: >> >> (defun tmm--completion-table (items) >> (lambda (string pred action) >> (if (eq action 'metadata) >> '(metadata (display-sort-function . identity)) >> (complete-with-action action items string pred)))) >> >> You say: >> >> > tmm already pretty much relies on the assumption that >> > completing-read is actually calling completing-read-default. >> >> I don't see any evidence of that. >> > > tmm's weirdness is not in the actual call to completing-read. That > completing-read call is wrapped by "(minibuffer-with-setup-hook > #'tmm-add-prompt ...)", which in turn calls tmm-define-keys, which sets up > a bunch of non-standard key bindings, which have the effect of implementing > a menu system with single-keypress activation of menu items, rather than > completion of a substring with string matching. The result is not even > recognizable as completing-read. The use of completing-read is merely an > implementation detail in a system that is *not* actually doing completion > of any kind. So pluggable completion backends don't make any sense for tmm, > and I can't imagine any other value of completing-read-function that would > make sense for tmm besides completing-read-default. Looking at the "git > blame" output for tmm, that call to completing-read has definitely not been > updated since completing-read-function was introduced except for minor > bugfixes, so it makes sense that tmm would be expecting one and only one > implementation of completing-read. > > >> This kind of argument could (inappropriately, IMO) be >> applied to any number of completely normal uses of >> `completing-read'. >> >> I see no reason to impose a dichotomy of either a >> `completing-read-function' similar to yours or else >> `completing-read-default'. There are likely other >> benign values of the variable, besides just >> `completing-read-default'. >> > > I'm not trying to set a general precedent here. tmm is the only code that > I'm aware of that uses completing-read in this way. > > It sounds like (and no, I haven't looked into it; >> it just sounds like it) you have some particular >> `completing-read-function' values in mind, which >> you have found are incompatible with tmm's use of >> `completing-read'. >> > > The alternative completing-read-function providers that I am aware of are > of are ido-ubiquitous (written by me), ivy, and helm. I'll also include > icicles, even though uses some other mechanism besides modifying > completing-read-function. ido-ubiquitous and ivy both have code to > deactivate themselves when completing-read is called by tmm because > otherwise their completion systems would break it, while icicles and helm > simply break tmm when enabled. Thus, to my knowledge there is currently no > other completing-read-function that doesn't break tmm (except for those > that make exceptions specifically for tmm). > > If so, that's not an argument for preventing the use of >> other values of `completing-read-function' with tmm. >> (Clearly the value `completing-read-default' is fine, >> for instance.) That's not an argument for tmm to do >> something to prevent all use of `completing-read-function'. >> >> Instead, it's an argument for the code that defines and >> uses a particular `completing-read-function' to take >> care of the contexts where it makes sense, and to stop >> itself from being used in other contexts, where it might >> cause trouble. >> >> Only that code knows the kinds of context where its own >> `completing-read-function' makes sense and where it does >> not. Code such as tmm should not try to guess what kinds >> of trouble different values of `completing-read-function' >> might cause. >> >> I don't think tmm should throw up its hands and say, "Gee, >> there might be some values of `completing-read-function' >> that are troublesome, so let's just prevent all use of >> that variable." That doesn't make sense, to me. >> > > Based on my explanation above, that is precisely what I think tmm should > do: avoid using completing-read-function entirely. To look at it another > way, tmm was originally written to use completing-read as an implementation > detail, and later the function that used to be called completing-read was > renamed to completing-read-default, but tmm was never updated to use the > new name. This patch rectifies that. > > >> If you want additional suggestions, maybe describe just >> what the problem is that your completion function causes >> for tmm. It's hard to offer suggestions if you only >> state that it is incompatible, without going into any >> detail. (Not that you must ask for input about this. >> But if you would like some then giving more detail might >> help.) >> >> Please use your own judgment (as I said, I don't really >> care much about `tmm'), but a priori this sounds like >> overkill. >> >> It sounds a bit like trying to bend Emacs to fit your >> `completing-read-function'. I can understand such a >> motivation, believe me; I don't ascribe a bad intention >> to you. A guess is that you are not sure what to do, >> to prevent inappropriate application of your value of >> `completing-read-function' in this or that context. >> >> If you think it causes trouble in some contexts, or it >> is not able to handle some contexts properly, then >> I'd suggest you consider walling it off from those use >> cases. It might take some time to discover which >> contexts it causes trouble for, but that's OK - you >> could add them as you discover them. Tmm sounds like >> a start. > > >> The right approach, IMO, is to teach your code when to >> use its `completing-read-function' and when not to use >> it. Put differently, consider teaching your >> `completing-read-function' when and where to hold back >> and just punt to the default behavior. >> > > This is exactly how ido-ubiquitous and ivy both currently work: they > essentially have a blacklist of callers for which they revert to standard > completion. tmm is on the blacklist for both packages. Certainly, for any > alternative completion system there will be cases where it needs to fall > back to standard completion. In my view, the completion system should be > able to determine purely based on the calling context (i.e. its arguments > and any relevant dynamically-bound variables) whether or not it needs to > punt. Making this decision based on the name of the caller instead of the > context to make this decision is admitting that not enough context was > provided. I view it as a workaround, not a desirable design pattern, and > someday in the future I hope to be able to remove the blacklist from > ido-ubiquitous. > > In the case of tmm, the best heuristic I can think of would be to inspect > the key bindings of all the letters and numbers. If any of them are locally > rebound in the minibuffer to something other than self-insert-command, then > punt. However, this doesn't work in practice because the bindings happen in > minibuffer-setup-hook, so putting a check at the front of this hook is too > early, and putting it at the end is too late because (in the case of > ido-ubiquitous) an error is triggered before reaching the end of the hook. > This was partly my motivation for suggesting the change in tmm rather than > working around it in ido-ubiquitous: because the blacklist approach is the > only way for ido-ubiquitous to fix it. > > It's obvious that it is possible for someone to create >> a `completing-read-function' that causes trouble here >> or there. But such trouble is up to the causer to fix >> or tame. >> > > For the reasons described above, I would be very surprised if there was > *any* alternative completion system that didn't break tmm. > > The approach of preventing code like `tmm.el' from >> letting other code use `completing-read-function' does >> not look like it heads in the right direction. But >> mine is just one opinion. I ask only that you think >> some more about this. >> > > As mentioned above, tmm is the only code I'm aware of that does anything > like this, and I don't see this as a general approach to be applied > anywhere else. > > Hopefully the above clarifies my rationale in proposing this change. > --001a113f8e7a5ff86f0551003dd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I should revise what I said slightly. Alternate completion= implementations might never be able to do away completely with blacklists,= because things like read-file-name also use completing-read. Still, I stan= d by my statement that nothing else I'm aware of uses completing-read i= n the same way as tmm.

On Fri, Jun 2, 2017 at 1:37 PM Ryan Thompson <rct@thompsonclan.org> wrote:
On Fri, Jun 2, 2017 at 11:26 AM Drew Adams <drew.adams@oracle.com> wrote:
I don't understand that argument.=C2= =A0 (But to be clear, I don't
really care much about `tmm'.)
=C2=A0
<= /div>
Fair enough. My post = certainly assumes quite a bit familiarity with tmm. I'm happy to elabor= ate below.
=C2=A0
I don't see that that is an argument for _preventing_ the
use of a `completing-read-function' by tmm.=C2=A0 I see it
only as a statement that it might not be helpful to use
some particular values of `completing-read-function' with
tmm.

If there is a general problem then consider adding a
comment in `tmm.el' (or perhaps put it in some doc
string) that says what you are really saying: Some
values of `completing-read-function' might not be
helpful with `tmm', and if you find that is the case,
consider binding that variable to nil.

But now that I've taken a quick look (just now) at the
use by tmm of `comple= ting-read', I don't see that there
is a problem to be fixed in `= tmm.el'.=C2=A0 I don't see that
its use of `completing-read'= is particularly exotic or
problematic.=C2=A0 This is it:

(comple= ting-read
=C2=A0(concat gl-str " (up/down to change, PgUp to menu):= ")
=C2=A0(tmm--completion-table (reverse tmm-km-list)) nil t nil=C2=A0(cons 'tmm--history (- (* 2 history-len) index-of-default)))
I don't see anything at all unusual about that.

And the col= lection function, `tmm--completion-table',
is likewise pretty ordina= ry, I think:

(defun tmm--completion-table (items)
=C2=A0 (lambda = (string pred action)
=C2=A0 =C2=A0 (if (eq action 'metadata)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 '(metadata (display-sort-function . identity))=
=C2=A0 =C2=A0 =C2=A0 (complete-with-action action items string pred))))=

You say:

> tmm already pretty much relies on the assumpti= on that
> completing-read is actually calling completing-read-default= .

I don't see any evidence of that.

tmm's w= eirdness is not in the actual call to completing-read. That completing-read= call is wrapped by "(minibuffer-with-setup-hook #'tmm-add-prompt = ...)", which in turn calls=C2=A0tmm-define-keys, which sets up a bunch= of non-standard key bindings, which have the effect of implementing a menu= system with single-keypress activation of menu items, rather than completi= on of a substring with string matching. The result is not even recognizable= as completing-read. The use of completing-read is merely an implementation= detail in a system that is *not* actually doing completion of any kind. So= pluggable completion backends don't make any sense for tmm, and I can&= #39;t imagine any other value of completing-read-function that would make s= ense for tmm besides completing-read-default. Looking at the "git blam= e" output for tmm, that call to completing-read has definitely not bee= n updated since completing-read-function was introduced except for minor bu= gfixes, so it makes sense that tmm would be expecting one and only one impl= ementation of completing-read.


This kind of argument could (inappropriately, IMO) be
applied= to any number of completely normal uses of
`completing-read'.
I see no reason to impose a dichotomy of either a
`completing-read-fun= ction' similar to yours or else
`completing-read-default'.=C2=A0= There are likely other
benign values of the variable, besides just
`= completing-read-default'.

I'm not trying to set a = general precedent here. tmm is the only code that I'm aware of that use= s completing-read in this way.

It sounds like (and no, I haven't looked into it;
it just sou= nds like it) you have some particular
`completing-read-function' val= ues in mind, which
you have found are incompatible with tmm's use of=
`completing-read'.

The alternative completing-read= -function providers that I am aware of are of are ido-ubiquitous (written b= y me), ivy, and helm. I'll also include icicles, even though uses some = other mechanism besides modifying completing-read-function. ido-ubiquitous = and ivy both have code to deactivate themselves when completing-read is cal= led by tmm because otherwise their completion systems would break it, while= icicles and helm simply break tmm when enabled. Thus, to my knowledge ther= e is currently no other completing-read-function that doesn't break tmm= (except for those that make exceptions specifically for tmm).
<= /div>

If so, that's not an argument fo= r preventing the use of
other values of `completing-read-function' w= ith tmm.
(Clearly the value `completing-read-default' is fine,
fo= r instance.)=C2=A0 That's not an argument for tmm to do
something to= prevent all use of `completing-read-function'.

Instead, it'= s an argument for the code that defines and
uses a particular `completin= g-read-function' to take
care of the contexts where it makes sense, = and to stop
itself from being used in other contexts, where it might
= cause trouble.

Only that code knows the kinds of context where its o= wn
`completing-read-function' makes sense and where it does
not.= =C2=A0 Code such as tmm should not try to guess what kinds
of trouble di= fferent values of `completing-read-function'
might cause.

I d= on't think tmm should throw up its hands and say, "Gee,
there m= ight be some values of `completing-read-function'
that are troubleso= me, so let's just prevent all use of
that variable."=C2=A0 That= doesn't make sense, to me.

=
Based on my explanation ab= ove, that is precisely what I think tmm should do: avoid using completing-r= ead-function entirely. To look at it another way, tmm was originally writte= n to use completing-read as an implementation detail, and later the functio= n that used to be called completing-read was renamed to completing-read-def= ault, but tmm was never updated to use the new name. This patch rectifies t= hat.
=C2= =A0
If you want addi= tional suggestions, maybe describe just
what the problem is that your co= mpletion function causes
for tmm.=C2=A0 It's hard to offer suggestio= ns if you only
state that it is incompatible, without going into any
= detail.=C2=A0 (Not that you must ask for input about this.
But if you wo= uld like some then giving more detail might
help.)

Please use you= r own judgment (as I said, I don't really
care much about `tmm')= , but a priori this sounds like
overkill.

It sounds a bit like tr= ying to bend Emacs to fit your
`completing-read-function'.=C2=A0 I c= an understand such a
motivation, believe me; I don't ascribe a bad i= ntention
to you.=C2=A0 A guess is that you are not sure what to do,
t= o prevent inappropriate application of your value of
`completing-read-fu= nction' in this or that context.

If you think it causes trouble = in some contexts, or it
is not able to handle some contexts properly, th= en
I'd suggest you consider walling it off from those use
cases.= =C2=A0 It might take some time to discover which
contexts it causes trou= ble for, but that's OK - you
could add them as you discover them.=C2= =A0 Tmm sounds like
a start.=C2=A0

The right approach, IMO, is to teach your code= when to
use its `completing-read-function' and when not to use
i= t.=C2=A0 Put differently, consider teaching your
`completing-read-functi= on' when and where to hold back
and just punt to the default behavio= r.

This is exactly how ido-ubiquitous and ivy both curre= ntly work: they essentially have a blacklist of callers for which they reve= rt to standard completion. tmm is on the blacklist for both packages. Certa= inly, for any alternative completion system there will be cases where it ne= eds to fall back to standard completion. In my view, the completion system = should be able to determine purely based on the calling context (i.e. its a= rguments and any relevant dynamically-bound variables) whether or not it ne= eds to punt. Making this decision based on the name of the caller instead o= f the context to make this decision is admitting that not enough context wa= s provided. I view it as a workaround, not a desirable design pattern, and = someday in the future I hope to be able to remove the blacklist from ido-ub= iquitous.

In the case of tmm, the best heuristic I= can think of would be to inspect the key bindings of all the letters and n= umbers. If any of them are locally rebound in the minibuffer to something o= ther than self-insert-command, then punt. However, this doesn't work in= practice because the bindings happen in minibuffer-setup-hook, so putting = a check at the front of this hook is too early, and putting it at the end i= s too late because (in the case of ido-ubiquitous) an error is triggered be= fore reaching the end of the hook. This was partly my motivation for sugges= ting the change in tmm rather than working around it in ido-ubiquitous: bec= ause the blacklist approach is the only way for ido-ubiquitous to fix it.

=
It's obvious that it = is possible for someone to create
a `completing-read-function' that = causes trouble here
or there.=C2=A0 But such trouble is up to the causer= to fix
or tame.

For the reasons described above, I wou= ld be very surprised if there was *any* alternative completion system that = didn't break tmm.

Th= e approach of preventing code like `tmm.el' from
letting other code = use `completing-read-function' does
not look like it heads in the ri= ght direction.=C2=A0 But
mine is just one opinion.=C2=A0 I ask only that= you think
some more about this.
=C2=A0
=
As mentioned above, = tmm is the only code I'm aware of that does anything like this, and I d= on't see this as a general approach to be applied anywhere else.=C2=A0<= /div>

Hopefully the above clarifies my rationale in prop= osing this change.
--001a113f8e7a5ff86f0551003dd2-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 17:26:00 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 21:26:00 +0000 Received: from localhost ([127.0.0.1]:51984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGu50-0000uH-3r for submit@debbugs.gnu.org; Fri, 02 Jun 2017 17:25:59 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:16649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGu4w-0000u2-SG for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 17:25:56 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v52LPlS2016284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 21:25:48 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v52LPlFH011332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Jun 2017 21:25:47 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v52LPioN031320; Fri, 2 Jun 2017 21:25:45 GMT MIME-Version: 1.0 Message-ID: <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> Date: Fri, 2 Jun 2017 14:25:42 -0700 (PDT) From: Drew Adams To: Ryan Thompson , 27193@debbugs.gnu.org Subject: RE: bug#27193: 25.2; tmm should use completing-read-default References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@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="__1496438744561258540abhmp0009.oracle.com" X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27193 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 (--) --__1496438744561258540abhmp0009.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =C2=A0 I don't understand that argument.=C2=A0 (But to be clear, I don't really care much about `tmm'.) =C2=A0 Fair enough. My post certainly assumes quite a bit familiarity with tmm. I'= m happy to elaborate below. =C2=A0 I am familiar with tmm. I don't care much about it (or for it). I use HYPER= LINK "https://www.emacswiki.org/emacs/LaCarte"LaCarte instead. =C2=A0 I don't see that its use of `completing-read' is particularly exotic or problematic.=C2=A0 This is it: (completing-read ...) I don't see anything at all unusual about that. And the collection function, `tmm--completion-table', is likewise pretty ordinary, I think... You say: > tmm already pretty much relies on the assumption that > completing-read is actually calling completing-read-default. I don't see any evidence of that. =C2=A0 tmm's weirdness is not in the actual call to completing-read. That completi= ng-read call is wrapped by "(minibuffer-with-setup-hook #'tmm-add-prompt ..= .)", which in turn calls=C2=A0tmm-define-keys, which sets up a bunch of non= -standard key bindings, which have the effect of implementing a menu system= with single-keypress activation of menu items, rather than completion of a= substring with string matching.=20 =C2=A0 I could have added that to the list of things that I do not find extraordin= ary or problematic in general for `completing-read-function': the key bindi= ngs, the completion function, all of it. =C2=A0 The case that needs to be made for your proposal is really (IMO) that there= are NO values of `completing-read-function', apart from `completing-read-d= efault', which would be compatible with the tmm code. =C2=A0 I don't think you can make that case. I sense you are extrapolating from yo= ur own particular use of `completing-read-function' (and similar uses). =C2=A0 The result is not even recognizable as completing-read. =C2=A0 I don't think so. Certainly no more unrecognizable than Ido, which doesn't = use *Completions*, defines its own keys, etc. There is lots of room for dif= ferent uses of `completing-read', and some of those uses might not look muc= h like the behavior of `completing-read-default'. Nothing wrong with that, = in itself. =C2=A0 And whether a user might or might not realize that `completing-read' is bei= ng used is not relevant, IMO.=20 =C2=A0 And your proposed fix is simply to impose `completing-read-default', which = hardly supports your argument that tmm provides some kind of anomalous, non= -completing-read `completing-read'. `completing-read-default' is the canoni= cal `completing-read' behavior, if there ever was one. And that's the behav= ior that tmm provides by default. =C2=A0 The use of completing-read is merely an implementation detail =C2=A0 How so? Please think about providing a different implementation of tmm, whi= ch doesn't use `completing-read'. That will let us know whether `completing= -read' is used only as an implementation detail. =C2=A0 in a system that is *not* actually doing completion of any kind.=20 =C2=A0 Of course it does completion.=C2=A0 Erase chars in the minibuffer from the = right and then hit TAB - completion. It's not a completion to write home ab= out, but it's completion. =C2=A0 So pluggable completion backends don't make any sense for tmm,=20 =C2=A0 That too sounds overly broad. I think that you have too readily convinced y= ourself that this and that don't make any possible sense, and you are prone= to nail things down to prevent what you see as the nonsensical. If such we= re truly nonsensical then they would likely never exist, and there would be= no reason to forbid them. =C2=A0 I sense that you think of "pluggable completion backends", that is, uses of= `completing-read-function', as necessarily something similar to what your = code does. =C2=A0 [FWIW I don't think of `completing-read-function' as providing only a "plug= gable completion backend". Do you think of `isearch-search-fun-function' as= a "pluggable search backend"? Backend? frontend? There are many angles to = something like completion or search or... There is not just a backend and a= frontend. Likewise, what you call an "alternative completion system". =C2=A0 Really, we're just talking about a completion function - a value for `compl= eting-read-function'. That has wide scope - there are few constraints on wh= at it must do. I don't see the justice in adding a constraint for tmm that = it cannot do anything except `completing-read-default'.] =C2=A0 and I can't imagine any other value of completing-read-function that would = make sense for tmm besides completing-read-default.=20 =C2=A0 All you need to imagine is something similar to `completing-read-default' b= ut slightly different in some respect. That's all you need to imagine, but = nothing prevents more imagination. =C2=A0 And what you or I can imagine is not really the point. The question is whet= her tmm.el must limit itself to `completing-read-default'. I don't see why = it should, just because we know of some values of `completing-read-function= ' that don't do the right thing for tmm. =C2=A0 Looking at the "git blame" output for tmm, that call to completing-read has= definitely not been updated since completing-read-function was introduced = except for minor bugfixes,=20 =C2=A0 That's irrelevant. =C2=A0 so it makes sense that tmm would be expecting one and only one implementati= on of completing-read. =C2=A0 That does not follow at all. =C2=A0 This kind of argument could (inappropriately, IMO) be applied to any number of completely normal uses of `completing-read'. I see no reason to impose a dichotomy of either a `completing-read-function' similar to yours or else `completing-read-default'.=C2=A0 There are likely other benign values of the variable, besides just `completing-read-default'. =C2=A0 I'm not trying to set a general precedent here. tmm is the only code that I= 'm aware of that uses completing-read in this way. =C2=A0 I agree that it is not a common way of using it. It doesn't follow that the= only possible value of `completing-read-function' that is compatible with = tmm is `completing-read-default'. Not at all. =C2=A0 It sounds like (and no, I haven't looked into it; it just sounds like it) you have some particular `completing-read-function' values in mind, which you have found are incompatible with tmm's use of `completing-read'. =C2=A0 The alternative completing-read-function providers that I am aware of are o= f are ido-ubiquitous (written by me), ivy, and helm. I'll also include icic= les, even though uses some other mechanism besides modifying completing-rea= d-function. ido-ubiquitous and ivy both have code to deactivate themselves = when completing-read is called by tmm because otherwise their completion sy= stems would break it, while icicles and helm simply break tmm when enabled.= Thus, to my knowledge there is currently no other completing-read-function= that doesn't break tmm (except for those that make exceptions specifically= for tmm). =C2=A0 Again, it is irrelevant that there are uses of `completing-read-function' t= hat break tmm. And what you or I am aware of, or even what might exist anyw= here today, does not define the scope of possibilities. =C2=A0 [I drink values of the variable `liquid'. Some values, such as strong sulfu= ric acid, are quite incompatible with my proper functioning. That doesn't m= ean that the only possible value or the only compatible value for me is the= default value, `water'. =C2=A0 I drink blindly - I don't know what's in the glass. The only requirement my= mouth imposes is that the variable value be a liquid. It is up to whoever = fills my glass to DTRT.] =C2=A0 And if those uses of `completing-read-function' are incompatible with tmm, = and they thus deactivate themselves for tmm commands, that is exactly the r= ight approach, IMO. It is exactly that which I suggested to you (without kn= owing that that is what you already do). =C2=A0 [Tmm does work with Icicles, BTW. (But Icicles does not use `completing-rea= d-function', among other reasons because it wants to work also with older E= macs versions.)] =C2=A0 If so, that's not an argument for preventing the use of other values of `completing-read-function' with tmm. (Clearly the value `completing-read-default' is fine, for instance.)=C2=A0 That's not an argument for tmm to do something to prevent all use of `completing-read-function'. Instead, it's an argument for the code that defines and uses a particular `completing-read-function' to take care of the contexts where it makes sense, and to stop itself from being used in other contexts, where it might cause trouble. Only that code knows the kinds of context where its own `completing-read-function' makes sense and where it does not.=C2=A0 Code such as tmm should not try to guess what kinds of trouble different values of `completing-read-function' might cause. I don't think tmm should throw up its hands and say, "Gee, there might be some values of `completing-read-function' that are troublesome, so let's just prevent all use of that variable."=C2=A0 That doesn't make sense, to me. =C2=A0 Based on my explanation above, that is precisely what I think tmm should do= : avoid using completing-read-function entirely. =C2=A0 I know you think that, but I don't see why. There are surely values of `com= pleting-read-function' that do not bother tmm. We know of one already: `com= pleting-read-default'. Why would you suppose that there can be no others? =C2=A0 To look at it another way, tmm was originally written to use completing-rea= d as an implementation detail, and later the function that used to be calle= d completing-read was renamed to completing-read-default, but tmm was never= updated to use the new name. This patch rectifies that. =C2=A0 That's completely imagination. `completing-read-default' is not the new nam= e of what was once `completing-read'. `completing-read' has never used code= like `completing-read-default'. (It has always been written in C.) =C2=A0 What I would say that perhaps you will think goes a bit in your direction i= s this: If you can rewrite `tmm.el' so that it has the same behavior withou= t using `completing-read', and the code is at least as simple and easy to m= aintain, then I'd say go ahead and do that. =C2=A0 That would support your idea that `completing-read' is only an implementati= on detail etc., and the question of `completing-read-function' would become= moot. =C2=A0 If you want additional suggestions, maybe describe just what the problem is that your completion function causes for tmm.=C2=A0 It's hard to offer suggestions if you only state that it is incompatible, without going into any detail.=C2=A0 (Not that you must ask for input about this. But if you would like some then giving more detail might help.) Please use your own judgment (as I said, I don't really care much about `tmm'), but a priori this sounds like overkill. It sounds a bit like trying to bend Emacs to fit your `completing-read-function'.=C2=A0 I can understand such a motivation, believe me; I don't ascribe a bad intention to you.=C2=A0 A guess is that you are not sure what to do, to prevent inappropriate application of your value of `completing-read-function' in this or that context. If you think it causes trouble in some contexts, or it is not able to handle some contexts properly, then I'd suggest you consider walling it off from those use cases.=C2=A0 It might take some time to discover which contexts it causes trouble for, but that's OK - you could add them as you discover them.=C2=A0 Tmm sounds like a start.=C2=A0 The right approach, IMO, is to teach your code when to use its `completing-read-function' and when not to use it.=C2=A0 Put differently, consider teaching your `completing-read-function' when and where to hold back and just punt to the default behavior. =C2=A0 This is exactly how ido-ubiquitous and ivy both currently work: they essent= ially have a blacklist of callers for which they revert to standard complet= ion. tmm is on the blacklist for both packages.=20 =C2=A0 That's great. Problem solved. That's the right approach, IMO. =C2=A0 Certainly, for any alternative completion system=20 =C2=A0 Any? Again with the superlatives. There is more to the world... =C2=A0 there will be cases where it needs to fall back to standard completion. In = my view, the completion system should be able to determine purely based on = the calling context (i.e. its arguments and any relevant dynamically-bound = variables) whether or not it needs to punt. Making this decision based on t= he name of the caller instead of the context to make this decision is admit= ting that not enough context was provided. I view it as a workaround, not a= desirable design pattern, and someday in the future I hope to be able to r= emove the blacklist from ido-ubiquitous. =C2=A0 In the case of tmm, the best heuristic I can think of would be to inspect t= he key bindings of all the letters and numbers. If any of them are locally = rebound in the minibuffer to something other than self-insert-command, then= punt.=20 =C2=A0 That would be silly, IMHO. There can be plenty of uses of `completing-read'= where letter or number keys are bound to commands other than `self-insert-= command'. =C2=A0 [FWIW, though not directly relevant, when Icicle mode is on there are no ke= ys bound to `self-insert-command' in any of the minibuffer completion keyma= ps. (But there are keys bound to `icicle-self-insert'.)] =C2=A0 However, this doesn't work in practice because the bindings happen in minib= uffer-setup-hook, so putting a check at the front of this hook is too early= , and putting it at the end is too late because (in the case of ido-ubiquit= ous) an error is triggered before reaching the end of the hook. This was pa= rtly my motivation for suggesting the change in tmm rather than working aro= und it in ido-ubiquitous: because the blacklist approach is the only way fo= r ido-ubiquitous to fix it. =C2=A0 It sounds like it is already doing things the right way. (And yes, it might= mean a slight maintenance chore for you if libraries such as tmm change si= gnificantly.) =C2=A0 It's obvious that it is possible for someone to create a `completing-read-function' that causes trouble here or there.=C2=A0 But such trouble is up to the causer to fix or tame. =C2=A0 For the reasons described above, I would be very surprised if there was *an= y* alternative completion system that didn't break tmm. =C2=A0 Just pick a value of `completing-read-function' that is only slightly diffe= rent from `completing-read-default', to convince yourself otherwise. =C2=A0 I really think you have your particular use case too much in mind, here. `c= ompleting-read-function' =C2=A0just means something that uses the same argu= ments as `completing-read-default' and does something somewhat similar. Its= marching orders are pretty general. =C2=A0 The approach of preventing code like `tmm.el' from letting other code use `completing-read-function' does not look like it heads in the right direction.=C2=A0 But mine is just one opinion.=C2=A0 I ask only that you think some more about this. =C2=A0 As mentioned above, tmm is the only code I'm aware of that does anything li= ke this, and I don't see this as a general approach to be applied anywhere = else.=C2=A0 =C2=A0 OK, that's reassuring. =C2=A0 Hopefully the above clarifies my rationale in proposing this change. =C2=A0 Thanks for clarifying. I hope my comments above clarify my point of view al= so, and I hope they help. --__1496438744561258540abhmp0009.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

 

I don't understand that argument.&nb= sp; (But to be clear, I don't
really care much about `tmm'.)<= /p>

 

<= p class=3DMsoNormal>Fair enough. My post certainly assumes quite a bit fami= liarity with tmm. I'm happy to elaborate below.

 

I am familiar with tmm. I don't care much about it (or for it)= . I use LaCarte ins= tead.

 

I don't see that
its use of `completing-read' is particularly e= xotic or
problematic.  This is it: (completing-read ...)
I don't = see anything at all unusual about that.
And the collection function, `tm= m--completion-table',
is likewise pretty ordinary, I think...

You say:
> tmm already pretty much = relies on the assumption that
> completing-read is actually calling c= ompleting-read-default.
I don't see any evidence of that.

=

 

tmm's weirdness is not in the actual call to completing-re= ad. That completing-read call is wrapped by "(minibuffer-with-setup-ho= ok #'tmm-add-prompt ...)", which in turn calls tmm-define-keys, w= hich sets up a bunch of non-standard key bindings, which have the effect of= implementing a menu system with single-keypress activation of menu items, = rather than completion of a substring with string matching.

=  

I could have added = that to the list of things that I do not find extraordinary or problematic = in general for `completing-read-function': the key bindings, the completion= function, all of it.

 

The case that= needs to be made for your proposal is really (IMO) that there are NO values of `completing-read-function', apart from `completing-read-default= ', which would be compatible with the tmm code.

 

I don't think you can make that case. I sense you are extrapol= ating from your own particular use of `completing-read-function' (and simil= ar uses).

 =

The result is not even recognizable a= s completing-read.

 

I don't think so. Certainly no more unrecognizable than Ido, = which doesn't use *Completions*, defines its own keys, etc. There is lots o= f room for different uses of `completing-read', and some of those uses migh= t not look much like the behavior of `completing-read-default'. Nothing wro= ng with that, in itself.

 

And whethe= r a user might or might not realize that `completing-read' is being = used is not relevant, IMO.

 

And you= r proposed fix is simply to impose `completing-read-default', which hardly = supports your argument that tmm provides some kind of anomalous, non-comple= ting-read `completing-read'. `completing-read-default' is the canonical `co= mpleting-read' behavior, if there ever was one. And that's the behavior tha= t tmm provides by default.

 

The use of completin= g-read is merely an implementation detail

 =

How so? Please think about providing a= different implementation of tmm, which doesn't use `completing-read'. That= will let us know whether `completing-read' is used only as an implementati= on detail.

 = ;

in a system that is *not* actually = doing completion of any kind.

 

Of course it does completion.=C2=A0 Erase chars i= n the minibuffer from the right and then hit TAB - completion. It's not a c= ompletion to write home about, but it's completion.

 

So pluggable completion backends don't make any sense for tmm,

 

That too so= unds overly broad. I think that you have too readily convinced yourself tha= t this and that don't make any possible sense, and you are prone to = nail things down to prevent what you see as the nonsensical. If such were t= ruly nonsensical then they would likely never exist, and there would be no = reason to forbid them.

I sense that= you think of "pluggable completion backends", that is, uses of `= completing-read-function', as necessarily something similar to what your co= de does.

 <= /o:p>

[FWIW I don't think of `co= mpleting-read-function' as providing only a "pluggable completion back= end". Do you think of `isearch-search-fun-function' as a "pluggab= le search backend"? Backend? frontend? There are many angles to someth= ing like completion or search or... There is not just a backend and a front= end. Likewise, what you call an "alternative completion system".<= o:p>

 

Really, we're just talking about a = completion function - a value for `completing-read-function'. That has wide= scope - there are few constraints on what it must do. I don't see t= he justice in adding a constraint for tmm that it cannot do anything except= `completing-read-default'.]

 

and I can't imagin= e any other value of completing-read-function that would make sense for tmm= besides completing-read-default. =

 

All you need to imagine is something similar = to `completing-read-default' but slightly different in some respect. That's= all you need to imagine, but nothing prevents more imagination.

 =

And what you or I can imagine is not r= eally the point. The question is whether tmm.el must limit itself to `compl= eting-read-default'. I don't see why it should, just because we know of som= e values of `completing-read-function' that don't do the right thing for tm= m.

 <= /span>

Looking at the "git blame" output = for tmm, that call to completing-read has definitely not been updated since= completing-read-function was introduced except for minor bugfixes,

 

That's irre= levant.

 

so it makes sense that tmm would be exp= ecting one and only one implementation of completing-read.

&n= bsp;

That does not follow = at all.

 

This kind of argument could (inappropriately, IMO) beapplied to any number of completely normal uses of
`completing-read'.
I see no reason to impose a dichotomy of either a
`completing-read= -function' similar to yours or else
`completing-read-default'.  The= re are likely other
benign values of the variable, besides just
`comp= leting-read-default'.

=  

I'm not trying to set = a general precedent here. tmm is the only code that I'm aware of that uses = completing-read in this way.

 

I agree that = it is not a common way of using it. It doesn't follow that the only possibl= e value of `completing-read-function' that is compatible with tmm is `compl= eting-read-default'. Not at all.

 

It sounds like (and no, I haven't loo= ked into it;
it just sounds like it) you have some particular
`comple= ting-read-function' values in mind, which
you have found are incompatibl= e with tmm's use of
`completing-read'.

<= p class=3DMsoNormal> 

Th= e alternative completing-read-function providers that I am aware of are of = are ido-ubiquitous (written by me), ivy, and helm. I'll also include icicle= s, even though uses some other mechanism besides modifying completing-read-= function. ido-ubiquitous and ivy both have code to deactivate themselves wh= en completing-read is called by tmm because otherwise their completion syst= ems would break it, while icicles and helm simply break tmm when enabled. T= hus, to my knowledge there is currently no other completing-read-function t= hat doesn't break tmm (except for those that make exceptions specifically f= or tmm).

 

Again, it is irrelevant that ther= e are uses of `completing-read-function' that break tmm. And what you or I = am aware of, or even what might exist anywhere today, does not define the s= cope of possibilities.

[I drink val= ues of the variable `liquid'. Some values, such as strong sulfuric acid, ar= e quite incompatible with my proper functioning. That doesn't mean that the= only possible value or the only compatible value for me is t= he default value, `water'.

 

I drink = blindly - I don't know what's in the glass. The only requirement my mouth i= mposes is that the variable value be a liquid. It is up to whoever fills my= glass to DTRT.]

 

And if those uses = of `completing-read-function' are incompatible with tmm, and they thus deac= tivate themselves for tmm commands, that is exactly the right approa= ch, IMO. It is exactly that which I suggested to you (without knowing that = that is what you already do).

 

[Tmm = does work with Icicles, BTW. (But Icicles does not use `completing-read-fun= ction', among other reasons because it wants to work also with older Emacs = versions.)]

 = ;

If so, that's not an argument for preventing the use of
o= ther values of `completing-read-function' with tmm.
(Clearly the value `= completing-read-default' is fine,
for instance.)  That's not an arg= ument for tmm to do
something to prevent all use of `completing-read-fun= ction'.

Instead, it's an argument for the code that defines and
u= ses a particular `completing-read-function' to take
care of the contexts= where it makes sense, and to stop
itself from being used in other conte= xts, where it might
cause trouble.

Only that code knows the kinds= of context where its own
`completing-read-function' makes sense and whe= re it does
not.  Code such as tmm should not try to guess what kind= s
of trouble different values of `completing-read-function'
might cau= se.

I don't think tmm should throw up its hands and say, "Gee,<= br>there might be some values of `completing-read-function'
that are tro= ublesome, so let's just prevent all use of
that variable."&n= bsp; That doesn't make sense, to me.

 

Based o= n my explanation above, that is precisely what I think tmm should do: avoid= using completing-read-function entirely.

 =

I know you think that, but I don't see= why. There are surely values of `completing-read-function' that do not bot= her tmm. We know of one already: `completing-read-default'. Why would you s= uppose that there can be no others?

 

To l= ook at it another way, tmm was originally written to use completing-read as= an implementation detail, and later the function that used to be called co= mpleting-read was renamed to completing-read-default, but tmm was never upd= ated to use the new name. This patch rectifies that.

 

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'>That's completely imagination. `completing-read-default' is not = the new name of what was once `completing-read'. `completing-read' has neve= r used code like `completing-read-default'. (It has always been written in = C.)

 =

What I would say that perhaps y= ou will think goes a bit in your direction is this: If you can rewrite `tmm= .el' so that it has the same behavior without using `completing-read= ', and the code is at least as simple and easy to maintain, then I'd say go= ahead and do that.

 

That would su= pport your idea that `completing-read' is only an implementation detail etc= ., and the question of `completing-read-function' would become moot.

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>

If = you want additional suggestions, maybe describe just
what the problem is= that your completion function causes
for tmm.  It's hard to offer = suggestions if you only
state that it is incompatible, without going int= o any
detail.  (Not that you must ask for input about this.
But = if you would like some then giving more detail might
help.)

Pleas= e use your own judgment (as I said, I don't really
care much about `tmm'= ), but a priori this sounds like
overkill.

It sounds a bit like t= rying to bend Emacs to fit your
`completing-read-function'.  I can = understand such a
motivation, believe me; I don't ascribe a bad intentio= n
to you.  A guess is that you are not sure what to do,
to preve= nt inappropriate application of your value of
`completing-read-function'= in this or that context.

If you think it causes trouble in some con= texts, or it
is not able to handle some contexts properly, then
I'd s= uggest you consider walling it off from those use
cases.  It might = take some time to discover which
contexts it causes trouble for, but tha= t's OK - you
could add them as you discover them.  Tmm sounds like<= br>a start. 


The right approach, IMO, is = to teach your code when to
use its `completing-read-function' and when n= ot to use
it.  Put differently, consider teaching your
`completi= ng-read-function' when and where to hold back
and just punt to the defau= lt behavior.

&nbs= p;

This is exactly how ido-ubiquit= ous and ivy both currently work: they essentially have a blacklist of calle= rs for which they revert to standard completion. tmm is on the blacklist fo= r both packages.

 

That's great. Problem solved. That's the right approach, IMO.<= o:p>

 

Certainly, for any alternative completion syste= m

=  

An= y? Again with the superlatives. There is more to the world...

 

there will be cases where it needs to fall back to standard = completion. In my view, the completion system should be able to determine p= urely based on the calling context (i.e. its arguments and any relevant dyn= amically-bound variables) whether or not it needs to punt. Making this decision based on the name of the caller i= nstead of the context to make this decision is admitting that not enough co= ntext was provided. I view it as a workaround, not a desirable design patte= rn, and someday in the future I hope to be able to remove the blacklist fro= m ido-ubiquitous.

 =

In the case of tmm, the best heur= istic I can think of would be to inspect the key bindings of all the letter= s and numbers. If any of them are locally rebound in the minibuffer to some= thing other than self-insert-command, then punt.

 

That would be silly, IMHO. The= re can be plenty of uses of `completing-read' where letter or number keys a= re bound to commands other than `self-insert-command'.

 

[FWIW, though not directly relevant, when Icicle mode i= s on there are no keys bound to `self-insert-command' in any of the = minibuffer completion keymaps. (But there are keys bound to `icicle-self-in= sert'.)]

 <= /o:p>

However, this doesn't work in practice= because the bindings happen in minibuffer-setup-hook, so putting a check a= t the front of this hook is too early, and putting it at the end is too lat= e because (in the case of ido-ubiquitous) an error is triggered before reac= hing the end of the hook. This was partly my motivation for suggesting the = change in tmm rather than working around it in ido-ubiquitous: because the = blacklist approach is the only way for ido-ubiquitous to fix it.=

 

It sounds like it is already doing things the righ= t way. (And yes, it might mean a slight maintenance chore for you if librar= ies such as tmm change significantly.)

 

It's obvious that it is possible = for someone to create
a `completing-read-function' that causes trouble h= ere
or there.  But such trouble is up to the causer to fix
or ta= me.

 <= /p>

For the reasons described above, I would= be very surprised if there was *any* alternative completion system that di= dn't break tmm.

 <= /o:p>

Just pick a value of `comp= leting-read-function' that is only slightly different from `completing-read= -default', to convince yourself otherwise.

 

I really think you have your particular use case too much in mind, = here. `completing-read-function' =C2=A0just means something that uses the s= ame arguments as `completing-read-default' and does something somewhat simi= lar. Its marching orders are pretty general.

 

The approach of preventing = code like `tmm.el' from
letting other code use `completing-read-function= ' does
not look like it heads in the right direction.  But
mine = is just one opinion.  I ask only that you think
some more about thi= s.

 

As mentioned above, tmm is the only code = I'm aware of that does anything like this, and I don't see this as a genera= l approach to be applied anywhere else. 

 

OK, that's reassuring.

 

Hopefully the abo= ve clarifies my rationale in proposing this change.

 

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'>Thanks for clarifying. I hope my comments above clarify my point= of view also, and I hope they help.

--__1496438744561258540abhmp0009.oracle.com-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 17:37:11 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 21:37:11 +0000 Received: from localhost ([127.0.0.1]:51991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuFq-0001Ar-H8 for submit@debbugs.gnu.org; Fri, 02 Jun 2017 17:37:10 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:35375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuFo-0001Ab-6i for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 17:37:08 -0400 Received: by mail-wm0-f44.google.com with SMTP id b84so34647640wmh.0 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 14:37:08 -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=B2kH6tIErp/cSRjm93B5Zj8giorcc6fTeNjzOoY0BFg=; b=mfg9cjhr8xmOsdqfvUx7rj12IfAL3sKdJNxOOd+X96ZCENY+ZJ5TcCXzF5eqbiRkTL 4CarOd01DsdiZZlXu7e6kFmnT1QeBrAoVxgQnNme3OhavvGzUV0xg5E0gagPgAJ/tg7p Qo3FYkLQ5A6r1zpiq3My/JaMi5qtco+pHVgsgYjJOaES7BF8qncpJBj6t0ajGiodEE0h 0RdJMUcSkST+w8/RTh4gfnFo3+2gZ5rzK/oNfYm1b9v2voYxi0rCkEsKdAPZjGyWItPS enAG5LcTkbtQ1xGFHkljFsHsh3QPhU029ns0XHvgB/9vlSBpBvWTrX99bYzI7U3wpgkI amLg== 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=B2kH6tIErp/cSRjm93B5Zj8giorcc6fTeNjzOoY0BFg=; b=lRYbwtSPbd9rUyASq650jn24TRfxDwl2fnoHCVgC6S5Yx+0fvYbTtQZ76bLcyTPk5L hfbOCi0hVU5p60iaJA3B4CuWns1Ap8gR4fbwCxi/OtqyGA5Fv0pyu/h9zNLICPQlXKV8 LV6+nZAtJXpe0tWBXdFZ6NkOrlPHYneID6tH51LBK5V+XX3J0OxNc9t5EcZDcpNBTeuP 1DDynJJbIfA2sSoL52Zk1QKDBi85NdGNw+cO7IVKIN8b28zWYQw9DmwplCzqPrT4MFvl AZ7CRG0HFgeLdCPyxWHu4xRgHL7XrJAHqW0Y8JwhQzxYBeGC8ExXhoRVshcVrmW+7oi4 66zw== X-Gm-Message-State: AODbwcDAcETIZSOqPa9KVuZdzM4Kv5yRN6w+LCQBqfZeGbcgJhMe/TFO GWdvcRMR6D/DLpoc7L4= X-Received: by 10.28.56.198 with SMTP id f189mr718024wma.111.1496439422170; Fri, 02 Jun 2017 14:37:02 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id g46sm13782553wrg.69.2017.06.02.14.37.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 14:37:01 -0700 (PDT) Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , Ryan Thompson , 27193@debbugs.gnu.org References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> From: Dmitry Gutov Message-ID: <669d7dff-a4bf-75b2-1652-6217efb84c72@yandex.ru> Date: Sat, 3 Jun 2017 00:37: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: <6a2811d5-8a21-47a6-b416-41bda3e36f67@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: 27193 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/3/17 12:25 AM, Drew Adams wrote: > The case that needs to be made for your proposal is really (IMO) that > there are /NO/ values of `completing-read-function', apart from > `completing-read-default', which would be compatible with the tmm code. That would be too strong. > I don't think you can make that case. I sense you are extrapolating from > your own particular use of `completing-read-function' (and similar uses). This is ridiculous. If there are functions that adhere to the contract of completing-read-function, and tmm can't work with them, tmm should use completing-read-default, and that's that. I'll install the submitted patch in a few days if someone doesn't beat me to it. > The result is not even recognizable as completing-read. > > I don't think so. Certainly no more unrecognizable than Ido... You are mixing up concepts right and left. E.g. APIs with their callers. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 18:19:55 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 22:19:55 +0000 Received: from localhost ([127.0.0.1]:52024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuvD-00028g-KD for submit@debbugs.gnu.org; Fri, 02 Jun 2017 18:19:55 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:30754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuvA-00028R-H2 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 18:19:52 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v52MJgZZ025987 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 22:19:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v52MJgZE022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 22:19:42 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v52MJf85028616; Fri, 2 Jun 2017 22:19:41 GMT MIME-Version: 1.0 Message-ID: <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> Date: Fri, 2 Jun 2017 15:19:40 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Ryan Thompson , 27193@debbugs.gnu.org Subject: RE: bug#27193: 25.2; tmm should use completing-read-default References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> <669d7dff-a4bf-75b2-1652-6217efb84c72@yandex.ru> In-Reply-To: <669d7dff-a4bf-75b2-1652-6217efb84c72@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: 27193 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 case that needs to be made for your proposal is really (IMO) that > > there are /NO/ values of `completing-read-function', apart from > > `completing-read-default', which would be compatible with the tmm code. >=20 > That would be too strong. No. That's exactly what you're forcing, if you force `completing-read-default' as the ONLY possible value. Precisely that: you allow no other values. The claim behind that must be that ALL other values would be problematic and so must be disallowed. > > I don't think you can make that case. I sense you > > are extrapolating from your own particular use of > > `completing-read-function' (and similar uses). >=20 > This is ridiculous. If there are functions that adhere to the contract > of completing-read-function, and tmm can't work with them, tmm should > use completing-read-default, and that's that. "Adhere to the contract of `completing-read-function'"? Are you kidding? What contract is that? (defvar completing-read-function 'completing-read-default "The function called by `completing-read' to do its work. It should accept the same arguments as `completing-read'.") Just accept the arguments - that's the only contract. "Do the work" of `completing-read' is completely vague. That means that anytime you can come up with a function that accepts those args and causes trouble, `completing-read-default' should be imposed as the only possible value. THAT is ridiculous. > I'll install the submitted patch in a few days if someone=20 > doesn't beat me to it. Of course you will. > > The result is not even recognizable as completing-read. > > > > I don't think so. Certainly no more unrecognizable than Ido... >=20 > You are mixing up concepts right and left. E.g. APIs with their callers. Nonsense. Ido's completion behavior is as far from that of vanilla `completing-read' as is Tmm's completion behavior ("the result"). From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 18:24:58 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 22:24:58 +0000 Received: from localhost ([127.0.0.1]:52029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGv04-0002Fx-86 for submit@debbugs.gnu.org; Fri, 02 Jun 2017 18:24:57 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:37429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGv02-0002Fk-Of for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 18:24:55 -0400 Received: by mail-wm0-f49.google.com with SMTP id d127so36693786wmf.0 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 15:24:54 -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=S9IAL3bJFXKp8iA75xcoBBe5zXiPC1BhWIWfTXi8B7U=; b=BVcgH5b5o/6VebfIGH70ED1ef0SyRNdczmnfnEddWThJUbVsyVLeiIiXRXWAp9etyI yPjRiAMEBQWjKx960CMy02ENyfRxy1tp6Pi5WJWfUOgpQTjIjddcJpn6tyIi2n3X9rMv DnOF+BvT5NoRKlJ9pjv+wAWNFTbuLOukWetiuWGAyPObGyLanN/wJLQU3yCqMGpKS1AB XLFKhA7KSGKJ6M8iTpxh9NW8i1w6ONn44wUurToV4curAWcoijG98v38C6QB6YNyPYGb aX8ftqkD1fT893G/ASPDv94oD0fAI2X33+Rm09OS1ajCe1Mf/zzZJMyCeWsDkIv03FBY uKoA== 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=S9IAL3bJFXKp8iA75xcoBBe5zXiPC1BhWIWfTXi8B7U=; b=tZUs30vhvXJLDmc20xZsqUf7T2wDjazPZWpxZkMEHjWFVANCDI6+Mp6Xp7zM+6Lk0L B0jjf77WAyBKrDuikRX85z4FWs7V2/keF5w4/JYUzvd6Ke0np2wKTASG4CVygbOy7gLd RYGKLaNWfHE0u2LaVFrqhNVbAOzXb4FyqGLQwZnj/DupfWHAOXehWGfI87DlIO6FPzV+ +A/uB3gEp0Z5KWPiXXxlo0hcO7sR2C2YCptXF1iWEGEhcaMe55Y1fRuZRUIR4QtfnweM brIuHozPdajVnrz10l/fDUrC5cpXqB3BiOPapllONS0f0esg/ZP1xTtfcWiyDv5SdtSj APJg== X-Gm-Message-State: AODbwcCVjvr3s78GtNZcnUcnNmbI+t144mbDDi0PPSKskP8DW4VK0yC4 LhAMbrt7qbfZSoTkLg0= X-Received: by 10.28.145.73 with SMTP id t70mr844452wmd.88.1496442288446; Fri, 02 Jun 2017 15:24:48 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 63sm3596462wmt.9.2017.06.02.15.24.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 15:24:47 -0700 (PDT) Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , Ryan Thompson , 27193@debbugs.gnu.org References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> <669d7dff-a4bf-75b2-1652-6217efb84c72@yandex.ru> <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> From: Dmitry Gutov Message-ID: <48c81c15-3e24-e112-de26-dda8eff42a48@yandex.ru> Date: Sat, 3 Jun 2017 01:24:45 +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: <236c968a-a11f-4a5a-88bc-f60edb50aa18@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: 27193 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/3/17 1:19 AM, Drew Adams wrote: > "Adhere to the contract of `completing-read-function'"? > Are you kidding? What contract is that? So the docstring is not written out fully and seriously enough. Even so, it's not hard to understand. > (defvar completing-read-function 'completing-read-default > "The function called by `completing-read' to do its work. > It should accept the same arguments as `completing-read'.") > > Just accept the arguments - that's the only contract. > "Do the work" of `completing-read' is completely vague. Yup. If the value of this variable accepts the arguments and performs completion, > That means that anytime you can come up with a function that > accepts those args and causes trouble, `completing-read-default' > should be imposed as the only possible value. Pretty much. Except we don't consider the very extremes, like completer functions trying to break examples like this intentionally. So not "a function" but "any reasonable function". It's Emacs, after all. >> I'll install the submitted patch in a few days if someone >> doesn't beat me to it. > > Of course you will. Thanks for the encouragement. >>> The result is not even recognizable as completing-read. >>> >>> I don't think so. Certainly no more unrecognizable than Ido... >> >> You are mixing up concepts right and left. E.g. APIs with their callers. > > Nonsense. Ido's completion behavior is as far from that of > vanilla `completing-read' as is Tmm's completion behavior > ("the result"). Ido is one of the API's possible implementations. TMM is its caller. Comparing them doesn't make any sense. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 18:52:37 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 22:52:37 +0000 Received: from localhost ([127.0.0.1]:52072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvQq-0002uD-4A for submit@debbugs.gnu.org; Fri, 02 Jun 2017 18:52:37 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:34516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvQn-0002tz-D1 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 18:52:34 -0400 Received: by mail-it0-f41.google.com with SMTP id m47so6817474iti.1 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 15:52:33 -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=2+c1phaG+7DLlbhcslO34MvRpQzR2fRnb5cpFG5lIM8=; b=hXfMGiSn3LpVMumHtgIlYut0Olp4wVgSB8L3zKzIz7OOM5NZDk7qxPXIUlke4zG8JS gHbLfa3XDEMTPb8AAahUZjC4uaLyVGvWWvAlAcAEwKUcL5AYxQjpVByvxToVi4eBXeni wZlElJoME+CqFtaQOPNmPoFaUzV/4IFxqpvwokypVTY1sH4RmSED8TV/MG0jCqhSO/jy iGJALcBsT9O9WjjyrN3p1U/yzADHVXgk3+FiEDqUXi2DRppZFJSH51+tSW6UQfE+j06a i22xz5mPCFv9h34cCPfNA5BKN/mGuN5/YpYh/yU4P8OHpzjAeVuNtr/xgbHJJLniiSBY 6G0A== 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=2+c1phaG+7DLlbhcslO34MvRpQzR2fRnb5cpFG5lIM8=; b=kvUyp/P2Iz76DtYWZ1TYFxnW7x8v5B9ymSxRvBtYZ9p0iAS/E9idAVcfpIWSn56o2K b4FqFY1GGlZmcBSq6okw4b562tX4OjrCVUOu0vv9PosBilGNNPo9kgHc72opd1tEBB8u swMcjGCdKSAvzfNFrCilccjfk0rB62iz7QlVr3kgOxfDcdN6UYo/kA/plc1U20JVQY6l aeCW59GFSHqqWsLrRNmhSq/P9BWLmg+DsQFe1dUCAYHvOs8MucCwDiyFh1jzSnfa24Ew 7lPmrVOrcyULIm2MtdxlPxNvztptjNKvTMoyNPRdM3DLlg5pjSP0SrQ3zAGoBVVCOEOq zeGQ== X-Gm-Message-State: AODbwcAOR88g+kbttFcis+/jSL80/R6Amerwo355APYqD/i0yZhFTzil FbZun9+8O4e0tFIBGApXI6VcEgNmx17Z X-Received: by 10.107.165.148 with SMTP id o142mr10435653ioe.179.1496443947524; Fri, 02 Jun 2017 15:52:27 -0700 (PDT) MIME-Version: 1.0 References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> In-Reply-To: <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> From: Ryan Thompson Date: Fri, 02 Jun 2017 22:52:16 +0000 Message-ID: Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , 27193@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a114928f4eb396205510201ee" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27193 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 (/) --001a114928f4eb396205510201ee Content-Type: text/plain; charset="UTF-8" (Note: I think several more replies came in while I was writing this; I haven't read those yet.) Ok, so if I'm understanding correctly, the thrust of your argument is that completing-read is a very general function that supports a very wide range of behaviors/usages, to such a degree that tmm's usage does not seem like an anomalous or unusual way to use it. I might not agree on what constitutes a typical usage of completing-read, but I can definitely agree that it is a very general function, and in practice no alternative value of completing-read-function that works substantially differently from completing-read-default is likely to be capable of replicating all of that functionality. So given your recommendation that alternative completion functions should "punt" cases they can't handle back to completing-read-default, along with the high likelihood that every alternate completion system is going to have something that it can't handle and needs to punt on, would you be interested in a patch that implements that punting mechanism within completing-read itself, so that ido-ubiqutous, ivy, helm, and others don't all have to invent their own punting code? I'm thinking along the lines of wrapping the call to completing-read-function with a condition-case that catches a "completing-read-fallback" signal, and calls completing-read-default instead. So any completion system that wants to punt just has to throw the appropriate signal. Some replies to specific points, which may or may not be moot: > > Please think about providing a different implementation of tmm, which > doesn't use `completing-read'. That will let us know whether > `completing-read' is used only as an implementation detail. > Magit implements a very similar system of using single-key shortcuts to activate items from a textual menu, with multiple levels of menus. It doesn't use completing-read. Of course it does completion. Erase chars in the minibuffer from the right > and then hit TAB - completion. It's not a completion to write home about, > but it's completion. > I would say that the fact that tmm does completion on hitting TAB is an internal implementation detail leaking out, i.e. an unintended side-effect of the fact that it uses completing-read internally. The main functionality of tmm is single-key shortcut access to menu items, not completion of user-entered text with matching strings from a set of choices. > > So pluggable completion backends don't make any sense for tmm, > > > > That too sounds overly broad. I think that you have too readily convinced > yourself that this and that don't make *any possible* sense, and you are > prone to nail things down to prevent what you see as the nonsensical. If > such were truly nonsensical then they would likely never exist, and there > would be no reason to forbid them. > > > > I sense that you think of "pluggable completion backends", that is, uses > of `completing-read-function', as necessarily something similar to what > your code does. > I don't think I'm making a broad statement. My claim is that settings that affect how completion works should not affect tmm because tmm isn't doing completion (or rather, tmm is doing completion only incidentally due to a leaky abstraction). I still stand by this claim, regardless of whether tmm's use of completing-read is considered typical or not. (If you accept this claim, there's probably some other completion-related settings that tmm should also ignore.) [FWIW I don't think of `completing-read-function' as providing only a > "pluggable completion backend". Do you think of > `isearch-search-fun-function' as a "pluggable search backend"? Backend? > frontend? There are many angles to something like completion or search > or... There is not just a backend and a frontend. Likewise, what you call > an "alternative completion system". > Well, I'm not sure exactly what to call it. I suppose "alternative values of completing-read-function" is more technically correct, but it's a real mouthful. Really, we're just talking about a completion function - a value for > `completing-read-function'. That has wide scope - there are few constraints > on what it *must* do. I don't see the justice in adding a constraint for > tmm that it cannot do anything except `completing-read-default'.] > > > > and I can't imagine any other value of completing-read-function that would > make sense for tmm besides completing-read-default. > > > > All you need to imagine is something similar to `completing-read-default' > but slightly different in some respect. That's all you *need* to imagine, > but nothing prevents more imagination.' > I was implicitly assuming that no one would bother to implement a new completion function from scratch unless it differed substantially from an existing one. > > And what you or I can imagine is not really the point. The question is > whether tmm.el must limit itself to `completing-read-default'. I don't see > why it should, just because we know of some values of > `completing-read-function' that don't do the right thing for tmm. > > > > Looking at the "git blame" output for tmm, that call to completing-read > has definitely not been updated since completing-read-function was > introduced except for minor bugfixes, > > > > That's irrelevant. > > > > so it makes sense that tmm would be expecting one and only one > implementation of completing-read. > > > > That does not follow at all. > > > > This kind of argument could (inappropriately, IMO) be > applied to any number of completely normal uses of > `completing-read'. > > I see no reason to impose a dichotomy of either a > `completing-read-function' similar to yours or else > `completing-read-default'. There are likely other > benign values of the variable, besides just > `completing-read-default'. > > > > I'm not trying to set a general precedent here. tmm is the only code that > I'm aware of that uses completing-read in this way. > > > > I agree that it is not a common way of using it. It doesn't follow that > the only possible value of `completing-read-function' that is compatible > with tmm is `completing-read-default'. Not at all. > > > > It sounds like (and no, I haven't looked into it; > it just sounds like it) you have some particular > `completing-read-function' values in mind, which > you have found are incompatible with tmm's use of > `completing-read'. > > > > The alternative completing-read-function providers that I am aware of are > of are ido-ubiquitous (written by me), ivy, and helm. I'll also include > icicles, even though uses some other mechanism besides modifying > completing-read-function. ido-ubiquitous and ivy both have code to > deactivate themselves when completing-read is called by tmm because > otherwise their completion systems would break it, while icicles and helm > simply break tmm when enabled. Thus, to my knowledge there is currently no > other completing-read-function that doesn't break tmm (except for those > that make exceptions specifically for tmm). > > > > Again, it is irrelevant that there are uses of `completing-read-function' > that break tmm. And what you or I am aware of, or even what might exist > anywhere today, does not define the scope of possibilities. > > > > [I drink values of the variable `liquid'. Some values, such as strong > sulfuric acid, are quite incompatible with my proper functioning. That > doesn't mean that the only *possible* value or the only *compatible* > value for me is the default value, `water'. > > > > I drink blindly - I don't know what's in the glass. The only requirement > my mouth imposes is that the variable value be a liquid. It is up to > whoever fills my glass to DTRT.] > > > > And if those uses of `completing-read-function' are incompatible with tmm, > and they thus deactivate themselves for tmm commands, that is exactly the > *right* approach, IMO. It is exactly that which I suggested to you > (without knowing that that is what you already do). > > > > [Tmm does work with Icicles, BTW. (But Icicles does not use > `completing-read-function', among other reasons because it wants to work > also with older Emacs versions.)] > > > > If so, that's not an argument for preventing the use of > other values of `completing-read-function' with tmm. > (Clearly the value `completing-read-default' is fine, > for instance.) That's not an argument for tmm to do > something to prevent all use of `completing-read-function'. > > Instead, it's an argument for the code that defines and > uses a particular `completing-read-function' to take > care of the contexts where it makes sense, and to stop > itself from being used in other contexts, where it might > cause trouble. > > Only that code knows the kinds of context where its own > `completing-read-function' makes sense and where it does > not. Code such as tmm should not try to guess what kinds > of trouble different values of `completing-read-function' > might cause. > > I don't think tmm should throw up its hands and say, "Gee, > there might be some values of `completing-read-function' > that are troublesome, so let's just prevent *all* use of > that variable." That doesn't make sense, to me. > > > > Based on my explanation above, that is precisely what I think tmm should > do: avoid using completing-read-function entirely. > > > > I know you think that, but I don't see why. There are surely values of > `completing-read-function' that do not bother tmm. We know of one already: > `completing-read-default'. Why would you suppose that there can be *no* > others? > > > > To look at it another way, tmm was originally written to use > completing-read as an implementation detail, and later the function that > used to be called completing-read was renamed to completing-read-default, > but tmm was never updated to use the new name. This patch rectifies that. > > > > That's completely imagination. `completing-read-default' is not the new > name of what was once `completing-read'. `completing-read' has never used > code like `completing-read-default'. (It has always been written in C.) > > > > What I would say that perhaps you will think goes a bit in your direction > is this: If you can rewrite `tmm.el' so that it has the *same behavior* > without using `completing-read', and the code is at least as simple and > easy to maintain, then I'd say go ahead and do that. > > > > That would support your idea that `completing-read' is only an > implementation detail etc., and the question of `completing-read-function' > would become moot. > I've provided Magit's popups as an example of similar functionality implemented without completing-read. I'm not a user of tmm, I just want to make sure my completion function doesn't break it. > > > If you want additional suggestions, maybe describe just > what the problem is that your completion function causes > for tmm. It's hard to offer suggestions if you only > state that it is incompatible, without going into any > detail. (Not that you must ask for input about this. > But if you would like some then giving more detail might > help.) > > Please use your own judgment (as I said, I don't really > care much about `tmm'), but a priori this sounds like > overkill. > > It sounds a bit like trying to bend Emacs to fit your > `completing-read-function'. I can understand such a > motivation, believe me; I don't ascribe a bad intention > to you. A guess is that you are not sure what to do, > to prevent inappropriate application of your value of > `completing-read-function' in this or that context. > > If you think it causes trouble in some contexts, or it > is not able to handle some contexts properly, then > I'd suggest you consider walling it off from those use > cases. It might take some time to discover which > contexts it causes trouble for, but that's OK - you > could add them as you discover them. Tmm sounds like > a start. > > > The right approach, IMO, is to teach your code when to > use its `completing-read-function' and when not to use > it. Put differently, consider teaching your > `completing-read-function' when and where to hold back > and just punt to the default behavior. > > > > This is exactly how ido-ubiquitous and ivy both currently work: they > essentially have a blacklist of callers for which they revert to standard > completion. tmm is on the blacklist for both packages. > > > > That's great. Problem solved. That's the right approach, IMO. > > > > Certainly, for any alternative completion system > > > > Any? Again with the superlatives. There is more to the world... > > > > there will be cases where it needs to fall back to standard completion. In > my view, the completion system should be able to determine purely based on > the calling context (i.e. its arguments and any relevant dynamically-bound > variables) whether or not it needs to punt. Making this decision based on > the name of the caller instead of the context to make this decision is > admitting that not enough context was provided. I view it as a workaround, > not a desirable design pattern, and someday in the future I hope to be able > to remove the blacklist from ido-ubiquitous. > > In the case of tmm, the best heuristic I can think of would be to inspect > the key bindings of all the letters and numbers. If any of them are locally > rebound in the minibuffer to something other than self-insert-command, then > punt. > > > > That would be silly, IMHO. There can be plenty of uses of > `completing-read' where letter or number keys are bound to commands other > than `self-insert-command'. > > > > [FWIW, though not directly relevant, when Icicle mode is on there are *no* > keys bound to `self-insert-command' in any of the minibuffer completion > keymaps. (But there are keys bound to `icicle-self-insert'.)] > My heuristic was meant specifically for ido-ubiquitous: the heuristic is that if any letters or numbers are bound to something other than self-insert-command, the caller is probably doing something fancy that won't work well with ido completion. In any case, it was merely meant as one example of how a completion function might infer from context whether it should punt without having to identify callers by name. Anyway, regardless of whether this patch is accepted or not, ido-ubiquitous will still need a blacklist either way, since functions like read-file-name that are already covered by normal ido-mode will always be on that blacklist. So I'm not exactly submitting this patch to make my implementation easier. I just thought that having tmm ignore completing-read-function would make it less fragile and mean one less obstacle for anyone implementing a new complting-read-function. --001a114928f4eb396205510201ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Note: I think several more replies came in while I w= as writing this; I haven't read those yet.)

Ok, so = if I'm understanding correctly, the thrust of your argument is that com= pleting-read is a very general function that supports a very wide range of = behaviors/usages, to such a degree that tmm's usage does not seem like = an anomalous or unusual way to use it. I might not agree on what constitute= s a typical usage of completing-read, but I can definitely agree that it is= a very general function, and in practice no alternative value of completin= g-read-function that works substantially differently from completing-read-d= efault is likely to be capable of replicating all of that functionality.
So given your recommendation that alternative completion f= unctions should "punt" cases they can't handle back to comple= ting-read-default, along with the high likelihood that every alternate comp= letion system is going to have something that it can't handle and needs= to punt on, would you be interested in a patch that implements that puntin= g mechanism within completing-read itself, so that ido-ubiqutous, ivy, helm= , and others don't all have to invent their own punting code? I'm t= hinking along the lines of wrapping the call to completing-read-function wi= th a condition-case that catches a "completing-read-fallback" sig= nal, and calls completing-read-default instead. So any completion system th= at wants to punt just has to throw the appropriate signal.

Some replies to specific points, which may or may not be moot:

=

=C2= =A0

Please t= hink about providing a different implementation of tmm, which doesn't u= se `completing-read'. That will let us know whether `completing-read= 9; is used only as an implementation detail.


Magit implements a very si= milar system of using single-key shortcuts to activate items from a textual= menu, with multiple levels of menus. It doesn't use completing-read.

Of c= ourse it does completion.=C2=A0 Erase chars in the minibuffer from the righ= t and then hit TAB - completion. It's not a completion to write home ab= out, but it's completion.


I would say that the fact that tmm does completion on hitti= ng TAB is an internal implementation detail leaking out, i.e. an unintended= side-effect of the fact that it uses completing-read internally. The main = functionality of tmm is single-key shortcut access to menu items, not compl= etion of user-entered text with matching strings from a set of choices.
=C2=A0

=C2=A0

=

So pluggable completion backends don't make any = sense for tmm,

=C2=A0

=

That = too sounds overly broad. I think that you have too readily convinced yourse= lf that this and that don't make any possible sense, and you are= prone to nail things down to prevent what you see as the nonsensical. If s= uch were truly nonsensical then they would likely never exist, and there wo= uld be no reason to forbid them.

=C2=A0

I sense that you think of &= quot;pluggable completion backends", that is, uses of `completing-read= -function', as necessarily something similar to what your code does.

=C2=A0
<= div>I don't think I'm making a broad statement. My claim is that se= ttings that affect how completion works should not affect tmm because tmm i= sn't doing completion (or rather, tmm is doing completion only incident= ally due to a leaky abstraction). I still stand by this claim, regardless o= f whether tmm's use of completing-read is considered typical or not. (I= f you accept this claim, there's probably some other completion-related= settings that tmm should also ignore.)

[FWIW I don't think of `completing-read-funct= ion' as providing only a "pluggable completion backend". Do y= ou think of `isearch-search-fun-function' as a "pluggable search b= ackend"? Backend? frontend? There are many angles to something like co= mpletion or search or... There is not just a backend and a frontend. Likewi= se, what you call an "alternative completion system".
<= /p>


Well, I'm not sur= e exactly what to call it. I suppose "alternative values of completing= -read-function" is more technically correct, but it's a real mouth= ful.

<= u>=C2=A0Really, we're just talking a= bout a completion function - a value for `completing-read-function'. Th= at has wide scope - there are few constraints on what it must do. I don't see the justice = in adding a constraint for tmm that it cannot do anything except `completin= g-read-default'.]

=C2=A0

and I can't i= magine any other value of completing-read-function that would make sense fo= r tmm besides completing-read-default.

<= u>=C2=A0

All you need to imagine is something similar to `compl= eting-read-default' but slightly different in some respect. That's = all you need to imagine, but nothing prevents more imagination.'=


=
I was implicitly assuming that no one would bother to implement a new = completion function from scratch unless it differed substantially from an e= xisting one.

=C2=A0

And what you or I can imagine is not r= eally the point. The question is whether tmm.el must limit itself to `compl= eting-read-default'. I don't see why it should, just because we kno= w of some values of `completing-read-function' that don't do the ri= ght thing for tmm.

= =C2=A0

Looking at the "git blame" output for tmm, that call t= o completing-read has definitely not been updated since completing-read-fun= ction was introduced except for minor bugfixes,

=C2=A0

=

That's irrelevant.

=
<= div>

=C2= =A0

so it makes sense that tmm woul= d be expecting one and only one implementation of completing-read.

=C2=A0

=

That does not follow at all.=

=C2=A0

This kind of argument could (inappr= opriately, IMO) be
applied to any number of completely normal uses of`completing-read'.

I see no reason to impose a dichotomy of eit= her a
`completing-read-function' similar to yours or else
`comple= ting-read-default'.=C2=A0 There are likely other
benign values of th= e variable, besides just
`completing-read-default'.

=C2=A0

=

I'm not trying to set a general precedent here. = tmm is the only code that I'm aware of that uses completing-read in thi= s way.

=C2=A0

I agree that it is not a common way of using it. It= doesn't follow that the only possible value of `completing-read-functi= on' that is compatible with tmm is `completing-read-default'. Not a= t all.

=C2= =A0

It sounds like (and no, I haven't looked into it;it just sounds like it) you have some particular
`completing-read-func= tion' values in mind, which
you have found are incompatible with tmm= 's use of
`completing-read'.

=

=C2=A0

The alternative completing-read-function providers that I am aware of a= re of are ido-ubiquitous (written by me), ivy, and helm. I'll also incl= ude icicles, even though uses some other mechanism besides modifying comple= ting-read-function. ido-ubiquitous and ivy both have code to deactivate the= mselves when completing-read is called by tmm because otherwise their compl= etion systems would break it, while icicles and helm simply break tmm when = enabled. Thus, to my knowledge there is currently no other completing-read-= function that doesn't break tmm (except for those that make exceptions = specifically for tmm).

=C2=A0

Again, it is irrelevant that ther= e are uses of `completing-read-function' that break tmm. And what you o= r I am aware of, or even what might exist anywhere today, does not define t= he scope of possibilities.

<= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS","s= ans-serif";color:#244061">=C2=A0

[I drink values of the variable `= liquid'. Some values, such as strong sulfuric acid, are quite incompati= ble with my proper functioning. That doesn't mean that the only poss= ible value or the only compatible value for me is the default va= lue, `water'.

=C2=A0

I drink blindly - I don't know what= 9;s in the glass. The only requirement my mouth imposes is that the variabl= e value be a liquid. It is up to whoever fills my glass to DTRT.]=

=C2=A0

And if those uses of `completing-read-function' are incompatible = with tmm, and they thus deactivate themselves for tmm commands, that is exa= ctly the right approach, IMO. It is exactly that which I suggested t= o you (without knowing that that is what you already do).

=C2=A0=

[T= mm does work with Icicles, BTW. (But Icicles does not use `completing-read-= function', among other reasons because it wants to work also with older= Emacs versions.)]

= =C2=A0

If so, that's not an argument for prevent= ing the use of
other values of `completing-read-function' with tmm.<= br>(Clearly the value `completing-read-default' is fine,
for instanc= e.)=C2=A0 That's not an argument for tmm to do
something to prevent = all use of `completing-read-function'.

Instead, it's an argu= ment for the code that defines and
uses a particular `completing-read-fu= nction' to take
care of the contexts where it makes sense, and to st= op
itself from being used in other contexts, where it might
cause tro= uble.

Only that code knows the kinds of context where its own
`co= mpleting-read-function' makes sense and where it does
not.=C2=A0 Cod= e such as tmm should not try to guess what kinds
of trouble different va= lues of `completing-read-function'
might cause.

I don't t= hink tmm should throw up its hands and say, "Gee,
there might be so= me values of `completing-read-function'
that are troublesome, so let= 's just prevent all use of
that variable."=C2=A0 That do= esn't make sense, to me.

=C2=A0

Based o= n my explanation above, that is precisely what I think tmm should do: avoid= using completing-read-function entirely.<= /u>

=C2=A0

I know you think that, but I don't see why. There = are surely values of `completing-read-function' that do not bother tmm.= We know of one already: `completing-read-default'. Why would you suppo= se that there can be no others?

=
=

=C2=A0

To look at it another way, tmm was originall= y written to use completing-read as an implementation detail, and later the= function that used to be called completing-read was renamed to completing-= read-default, but tmm was never updated to use the new name. This patch rec= tifies that.

=C2=A0

That's completely imagination. `completin= g-read-default' is not the new name of what was once `completing-read&#= 39;. `completing-read' has never used code like `completing-read-defaul= t'. (It has always been written in C.)

=C2=A0<= /p>

What I would say = that perhaps you will think goes a bit in your direction is this: If you ca= n rewrite `tmm.el' so that it has the same behavior without usin= g `completing-read', and the code is at least as simple and easy to mai= ntain, then I'd say go ahead and do that.

=C2=A0

That would sup= port your idea that `completing-read' is only an implementation detail = etc., and the question of `completing-read-function' would become moot.=


=
I've provided Magit's popups as an example of similar function= ality implemented without completing-read. I'm not a user of tmm, I jus= t want to make sure my completion function doesn't break it.
= =C2=A0

<= /u>

=C2=A0

If you want additional suggestions, maybe describe just
what the= problem is that your completion function causes
for tmm.=C2=A0 It's= hard to offer suggestions if you only
state that it is incompatible, wi= thout going into any
detail.=C2=A0 (Not that you must ask for input abou= t this.
But if you would like some then giving more detail might
help= .)

Please use your own judgment (as I said, I don't really
ca= re much about `tmm'), but a priori this sounds like
overkill.
It sounds a bit like trying to bend Emacs to fit your
`completing-read-= function'.=C2=A0 I can understand such a
motivation, believe me; I d= on't ascribe a bad intention
to you.=C2=A0 A guess is that you are n= ot sure what to do,
to prevent inappropriate application of your value o= f
`completing-read-function' in this or that context.

If you = think it causes trouble in some contexts, or it
is not able to handle so= me contexts properly, then
I'd suggest you consider walling it off f= rom those use
cases.=C2=A0 It might take some time to discover which
= contexts it causes trouble for, but that's OK - you
could add them a= s you discover them.=C2=A0 Tmm sounds like
a start.=C2=A0<= /p>


The right approach, IMO, is to teach your code when to<= br>use its `completing-read-function' and when not to use
it.=C2=A0 = Put differently, consider teaching your
`completing-read-function' w= hen and where to hold back
and just punt to the default behavior.=

=C2=A0

This is exactly how ido-ubiquitous and i= vy both currently work: they essentially have a blacklist of callers for wh= ich they revert to standard completion. tmm is on the blacklist for both pa= ckages.

=C2=A0

<= /div>
<= div>

That's = great. Problem solved. That's the right approach, IMO.

= =C2=A0

Certainly, for any alter= native completion system

=C2=A0

Any? Again with the superlatives. There is more to the world...=

=C2=A0

there will be = cases where it needs to fall back to standard completion. In my view, the c= ompletion system should be able to determine purely based on the calling co= ntext (i.e. its arguments and any relevant dynamically-bound variables) whe= ther or not it needs to punt. Making t= his decision based on the name of the caller instead of the context to make= this decision is admitting that not enough context was provided. I view it= as a workaround, not a desirable design pattern, and someday in the future= I hope to be able to remove the blacklist from ido-ubiquitous.

=

In the case of tmm, the best heuristi= c I can think of would be to inspect the key bindings of all the letters an= d numbers. If any of them are locally rebound in the minibuffer to somethin= g other than self-insert-command, then punt. =

=C2=A0

That would be silly, IMHO. There can be plenty of = uses of `completing-read' where letter or number keys are bound to comm= ands other than `self-insert-command'.

=C2=A0<= /p>

[FWIW, though not= directly relevant, when Icicle mode is on there are no keys bound t= o `self-insert-command' in any of the minibuffer completion keymaps. (B= ut there are keys bound to `icicle-self-insert'.)]


My heuristic was= meant specifically for ido-ubiquitous: the heuristic is that if any letter= s or numbers are bound to something other than self-insert-command, the cal= ler is probably doing something fancy that won't work well with ido com= pletion. In any case, it was merely meant as one example of how a completio= n function might infer from context whether it should punt without having t= o identify callers by name.

Anyway, regardless of = whether this patch is accepted or not, ido-ubiquitous will still need a bla= cklist either way, since functions like=C2=A0read-file-name=C2=A0that are already covered by normal ido-mode=C2=A0will always be on t= hat blacklist. So I'm not exactly submitting= this patch to make my implementation easier. I just thought that having tm= m ignore completing-read-function would make it less fragile and mean one l= ess obstacle for anyone implementing a new complting-read-function.<= /div>
--001a114928f4eb396205510201ee-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 19:08:56 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 23:08:56 +0000 Received: from localhost ([127.0.0.1]:52090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvge-00055s-Kc for submit@debbugs.gnu.org; Fri, 02 Jun 2017 19:08:56 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:38162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvgd-00055f-85 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 19:08:55 -0400 Received: by mail-it0-f46.google.com with SMTP id r63so33261496itc.1 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 16:08:55 -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=+hBqJjPD2w2U2HL9yWIUn6lXOnK1NsXjVCFOJglexy8=; b=Y+U94ifR64S5woz51M0vNFHUlApXs+HbcZlVPtlKaZ5VceCIGhq29fByrScBDP33VT KFCvlfGA4lu/sfC9RaF/cdyRniGJpgKCKS1ofQsotSPF3xtFS5YYLSShWzmtQEeE4/c3 ypML0XD9Q0Y7h3yHSoka9XYW27g1Lu6NfpeVQueHcGVTVxgTpXaSAS0UsSYyhY8hr8zG N1bJzTE8iBIpeKEl5E8tUD9JGBUBkzWUqmsszx5GWT0hXbLFOOrnOP6IH9Ymc4s60X+i rNxxZB+wRlFn4YRKzq4pcYZuqOxfc5MFrCTshRRtNaibPLENe6PdOm69f2HdZxuNlQLg G4aw== 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=+hBqJjPD2w2U2HL9yWIUn6lXOnK1NsXjVCFOJglexy8=; b=Msc8uOiUGIuskhk46i1GPaRdiduhPa//YwKNb8K9l0vjc3G7bSZYHx+HZ0rrUVbaa0 Xzx3vkhp1ZChpr7WwwWbInBImKlZ2+BA2Gtq7e1ketXUNWiugZ/dtknyC6Lvi16qlPmA KQbZPo4VHpb77His5c4Cd2YNlj2rQSHbelSzdGYwSJ14Uq3i/Zh5X3wIMkhOL61QvuuM GHahs5uubrx8gIjMvqi5dspC0oNhRfhmJ6z7ytS1AdsDAwnlNXBGUQUOPNWgICMUf69O G0uc0tH+a7zi+qUvXvj54+XcO1b9w8d+a4nmL0S2n0LtSnKRWMx1YYFM28lp1rDG1Z6b R6iQ== X-Gm-Message-State: AODbwcDziPxkLWzHjqAgGx4/zGmeceAr1vmGqNZJoGJx4lQ1fMt5G7/0 sFrMTKLy8DSktFX0fUBrgV5jWooflvOl X-Received: by 10.36.54.210 with SMTP id l201mr1950845itl.65.1496444929669; Fri, 02 Jun 2017 16:08:49 -0700 (PDT) MIME-Version: 1.0 References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> <669d7dff-a4bf-75b2-1652-6217efb84c72@yandex.ru> <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> In-Reply-To: <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> From: Ryan Thompson Date: Fri, 02 Jun 2017 23:08:38 +0000 Message-ID: Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , Dmitry Gutov , 27193@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a1144046875ab1a0551023ca9" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27193 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 (/) --001a1144046875ab1a0551023ca9 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 6:19 PM Drew Adams wrote: > Ido's completion behavior is as far from that of > vanilla `completing-read' as is Tmm's completion behavior > ("the result"). > This is kind of my point. If someone calls ido-completing-read, you wouldn't expect it to do something different based on the value of completing-read-function, even if it ido used completing-read internally (which it might have actually done in the past, but currently does not), because by calling ido-completing-read the code has already specified it wants ido completion. Similarly, tmm is implementing a very different behavior from completing-read that is only recognizable as regular completion if you specifically go looking for leaks in the abstraction, and for the same reason I don't think tmm should be paying attention to completing-read-function. --001a1144046875ab1a0551023ca9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Jun 2, 2017 at 6:19 PM Drew Adams <drew.adams@oracle.com> wrote:
Ido's completion behavior is as far from that of
vanilla `completing-read' as is Tmm's completion behavior
("the result").

This is kind = of my point. If someone calls ido-completing-read, you wouldn't expect = it to do something different based on the value of completing-read-function= , even if it ido used completing-read internally (which it might have actua= lly done in the past, but currently does not), because by calling ido-compl= eting-read the code has already specified it wants ido completion. Similarl= y, tmm is implementing a very different behavior from completing-read that = is only recognizable as regular completion if you specifically go looking f= or leaks in the abstraction, and for the same reason I don't think tmm = should be paying attention to completing-read-function.
--001a1144046875ab1a0551023ca9-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 19:10:30 2017 Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 23:10:30 +0000 Received: from localhost ([127.0.0.1]:52099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGviA-00058i-8V for submit@debbugs.gnu.org; Fri, 02 Jun 2017 19:10:30 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:33648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvi8-00058W-Vn for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 19:10:29 -0400 Received: by mail-it0-f45.google.com with SMTP id w68so11218436itc.0 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 16:10:29 -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=jpQa9jrDBk35YbDEve90DCy30vm4tFRtnRLkHAQnEvg=; b=ZLlS6/zEB711bZ2C1rh2aMK5fJYqLNfVI09ZoCy5bwgLEiuMdIhin3uMA1jhq0ZZ3P +R/92t6w4p2XLgAZ1jeS6lEHnhaXSEFynjmIO5gvzIZ/D7Q3bZQGb7A7cgArQehAjirq eiixV0Dd8U8YzHjH9NvDTsfU8W8+i9xn3ITVktSBsk80CyozqoxZH8BgD0umQ8euP/RM hBKqOD3W600GvQ0EGkg4ASqBqIepQz4QvkCDFRKSdWq9XkjYzDMfxTI9zLMZjuyxhxfo ANgO8sTALBepkgvWHRCGPPoG5P/D4pvGH50D6ZvFR8XckkD/gAT3llqpiQZCSEbHmwBx NNhg== 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=jpQa9jrDBk35YbDEve90DCy30vm4tFRtnRLkHAQnEvg=; b=Isr0DsgHV48nFiVN1XiR69lYQ/gW2ltAxE8DgHm6R5l9izqP0W34YYX6QMZyRXtYrQ u2BfIVTpJU39C5ZF5GcvD2SeVvi9GEj/WFv4y5as9lX5sPVVdbh4oUAm0/05KjWlQ1Jr eVmVzCjCORKkxEh2eEcRDfsB/t8unU2J0DRA8qD1ka4D0r+dZryw6UNc9DjpAxRdaIX7 HD128JAjCmFc7J20af7B2zjkd4Bh3ztt8t7mVh/lrQac85y+4YZyUJvCxogu+vtOSJOF cMO1fkBnHmtEnRTw41kUj6sgsIcFbYVDr5T/hY1QDHKEqScGatrRq3O7bFUkoWQvQDqU CAvQ== X-Gm-Message-State: AODbwcAL1f0z55Nx4Q5fkqLM+SJC4vZtjLCTi1ovwvV+4g6kP7bENhNz ZmXBpf1joryXwwxlYE2IoK3C6hed3/287cM= X-Received: by 10.36.108.212 with SMTP id w203mr1896138itb.55.1496445023629; Fri, 02 Jun 2017 16:10:23 -0700 (PDT) MIME-Version: 1.0 References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> <669d7dff-a4bf-75b2-1652-6217efb84c72@yandex.ru> <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> In-Reply-To: From: Ryan Thompson Date: Fri, 02 Jun 2017 23:10:13 +0000 Message-ID: Subject: Re: bug#27193: 25.2; tmm should use completing-read-default To: Drew Adams , Dmitry Gutov , 27193@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113f7a740f4fa70551024226" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27193 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 (/) --001a113f7a740f4fa70551024226 Content-Type: text/plain; charset="UTF-8" Or to put the same thing in a more user-centric context, I think users would be surprised if changing the value of completing-read-function changed the behavior of tmm. On Fri, Jun 2, 2017 at 7:08 PM Ryan Thompson wrote: > On Fri, Jun 2, 2017 at 6:19 PM Drew Adams wrote: > >> Ido's completion behavior is as far from that of >> vanilla `completing-read' as is Tmm's completion behavior >> ("the result"). >> > > This is kind of my point. If someone calls ido-completing-read, you > wouldn't expect it to do something different based on the value of > completing-read-function, even if it ido used completing-read internally > (which it might have actually done in the past, but currently does not), > because by calling ido-completing-read the code has already specified it > wants ido completion. Similarly, tmm is implementing a very different > behavior from completing-read that is only recognizable as regular > completion if you specifically go looking for leaks in the abstraction, and > for the same reason I don't think tmm should be paying attention to > completing-read-function. > --001a113f7a740f4fa70551024226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Or to put the same thing in a more user-centric context, I= think users would be surprised if changing the value of completing-read-fu= nction changed the behavior of tmm.

On Fri, Jun 2, 2017 at 7:08 PM Ryan Thompson <rct@thompsonclan.org> wrote:
On Fri, Jun 2, 2017 at 6:19 PM Drew Adams <drew.adams@oracle.com> = wrote:
Ido's completion behavio= r is as far from that of
vanilla `completing-read' as is Tmm's completion behavior
("the result").

This is kind of my point. If som= eone calls ido-completing-read, you wouldn't expect it to do something = different based on the value of completing-read-function, even if it ido us= ed completing-read internally (which it might have actually done in the pas= t, but currently does not), because by calling ido-completing-read the code= has already specified it wants ido completion. Similarly, tmm is implement= ing a very different behavior from completing-read that is only recognizabl= e as regular completion if you specifically go looking for leaks in the abs= traction, and for the same reason I don't think tmm should be paying at= tention to completing-read-function.
--001a113f7a740f4fa70551024226-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 20:02:15 2017 Received: (at 27193-done) by debbugs.gnu.org; 3 Jun 2017 00:02:15 +0000 Received: from localhost ([127.0.0.1]:52144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGwWF-0006KP-Ea for submit@debbugs.gnu.org; Fri, 02 Jun 2017 20:02:15 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGwWD-0006K6-BF for 27193-done@debbugs.gnu.org; Fri, 02 Jun 2017 20:02:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGwW7-0007OM-QB for 27193-done@debbugs.gnu.org; Fri, 02 Jun 2017 20:02:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGwW7-0007O6-O2 for 27193-done@debbugs.gnu.org; Fri, 02 Jun 2017 20:02:07 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1dGwW7-00044D-3f; Fri, 02 Jun 2017 20:02:07 -0400 From: Glenn Morris To: 27193-done@debbugs.gnu.org Subject: Re: bug#27193: 25.2; tmm should use completing-read-default References: X-Spook: Cyber terror Vaccine Firewalls Coast Guard Federal X-Ran: 9h7()\xyH*TTy!)7N-IQY3Y&ck&|yFOo2pBe%uyp4rM~uFqhv-0Zt^_N)+f&"Chj@Ox.'9 X-Hue: blue X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 02 Jun 2017 20:02:06 -0400 In-Reply-To: (Ryan's message of "Fri, 2 Jun 2017 00:50:52 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27193-done 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 (-----) Version: 26.1 Thanks; applied as b406174. (FYI the patch in your mail seemed mangled.) From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 20:16:07 2017 Received: (at 27193) by debbugs.gnu.org; 3 Jun 2017 00:16:07 +0000 Received: from localhost ([127.0.0.1]:52167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGwje-0006fb-Ub for submit@debbugs.gnu.org; Fri, 02 Jun 2017 20:16:07 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:23322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGwjb-0006er-Ob for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 20:16:04 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v530FuPL016449 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Jun 2017 00:15:57 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v530FukQ008679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Jun 2017 00:15:56 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v530FtZ0026272; Sat, 3 Jun 2017 00:15:55 GMT MIME-Version: 1.0 Message-ID: <3c7b01d3-57f9-4a69-ae5a-523041009cb8@default> Date: Fri, 2 Jun 2017 17:15:52 -0700 (PDT) From: Drew Adams To: Ryan Thompson , 27193@debbugs.gnu.org Subject: RE: bug#27193: 25.2; tmm should use completing-read-default References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@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: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27193 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 (--) > So given your recommendation that alternative completion > functions should "punt" cases they can't handle back to > completing-read-default, along with the high likelihood > that every alternate completion system is going to have > something that it can't handle and needs to punt on, would > you be interested in a patch that implements that punting > mechanism within completing-read itself, so that > ido-ubiqutous, ivy, helm, and others don't all have to > invent their own punting code? I'm thinking along the lines > of wrapping the call to completing-read-function with a > condition-case that catches a "completing-read-fallback" > signal, and calls completing-read-default instead. So any > completion system that wants to punt just has to throw > the appropriate signal. First, I can tell that you have read and thought about what I wrote. Thanks for that. I have not wasted my time, in that case. For the rest, as you can probably guess, I'm not in really in favor of changing `completing-read'. Tmm is something I don't really care about. `completing-read' is something I do care about. A priori, I would prefer that you do whatever it is that you think you need to do to `tmm.el' than to `completing-read' and related code. That said, what you say does not sound objectionable. It might be helpful. But I represent just one opinion, and I haven't really thought about this. If you think such control is something that could be generally helpful then I'd suggest that you bring it up for discussion on emacs-devel@gnu.org. That should help. In terms of implementation, maybe `catch' and `throw' would be a better fit than `condition-case' with a signal handler, but maybe not. And you might have to worry about where handling takes place, in case of recursive completion - dunno. From unknown Thu Jun 19 14:06:22 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 01 Jul 2017 11:24:07 +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