From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Dec 2018 04:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 33595@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15438100505018 (code B ref -1); Mon, 03 Dec 2018 04:08:02 +0000 Received: (at submit) by debbugs.gnu.org; 3 Dec 2018 04:07:30 +0000 Received: from localhost ([127.0.0.1]:58588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTfW5-0001Ir-NB for submit@debbugs.gnu.org; Sun, 02 Dec 2018 23:07:30 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTfW4-0001Ib-EL for submit@debbugs.gnu.org; Sun, 02 Dec 2018 23:07:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTfVx-0007eu-C6 for submit@debbugs.gnu.org; Sun, 02 Dec 2018 23:07:23 -0500 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 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gTfVw-0007eG-BL for submit@debbugs.gnu.org; Sun, 02 Dec 2018 23:07:21 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTfVv-0001cK-C2 for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 23:07:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTfVr-0007aq-KL for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 23:07:19 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:56040) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gTfVp-0007Yy-4l for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 23:07:13 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB3442OF089347 for ; Mon, 3 Dec 2018 04:07:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=pVTs3XG1JZIG5lwwROMttME5/2W2TNMwOQywvl/2tKQ=; b=kCUCy3QaRQn/w87LkNiyFYQBpmA3Z49fXyZm/u9xDs4+s82OtFFNqB1aOE5FxSpN+4Iz NpEjMC1ZDQ5LMWMXWHESqMAIGufBTJTqwtRq00zoIwDoYYUlITL3yblcWsIYbXfsf+tC KX8PQKwkSEcJTOifq3Z2pZtMnADozj0D24iguZO/w1zXLdsQzPA4uCkE1HC4UK7bSmAo p+8MfO2dU0goQZXXsN1+0xEaqZCxZ+1ubrgCs5HSwSHvtpt7RYMUzmCI/wWYBiinkuth +m32OHJqFfxmC0/q9KNyyF8xE5PSI3LDpp1AXS3Eiz1iIojzi0O2uHiD7ftKR959ExMY Zw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2p3j8q3y92-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 03 Dec 2018 04:07:10 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB3479nb026483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 3 Dec 2018 04:07:09 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB3478B3026165 for ; Mon, 3 Dec 2018 04:07:08 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 2 Dec 2018 20:07:07 -0800 (PST) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4771.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9095 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812030039 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) 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 (-----) Enhancement request: When `try-completion' returns `t' there is a "unique match which is exact". Please add an abnormal hook at this point, which accepts that sole completion as argument. This feature would make it easier for callers of `completing-read', `read-file-name', etc. to do something at that point with that sole match, while the user can still change her minibuffer input. For example, the caller could display additional information about that sole match. This could alternatively be done in `completion--done', before it calls `exit-fun', but it would also need to be done in the case where there is no exit function. `try-completion' is the logical place to do this, I think, but it is coded in C. I'm not sure which Lisp place would be best as an alternative, if it's not `completion--done'. A hook is handier for this than, say, defining an exit function that tests for `finished' and binding `completion-extra-properties' to a list that contains `:exit-function' with that function as value. A hook lets you add any number of such "sole completion" functions, and their use is not tied to just one call of a completion function. Here's a quick implementation using `completion--done'. It may be all that's required - not sure about the use of `unknown' as `completion--done' arg FINISHED. It just adds these two lines: (when (eq finished 'finished) (run-hook-with-args 'completion-sole-match-functions string)) (defun completion--done (string &optional finished message) (let* ((exit-fun (plist-get completion-extra-properties :exit-function)) (pre-msg (and exit-fun (current-message)))) (cl-assert (memq finished '(exact sole finished unknown))) (when (eq finished 'finished) (run-hook-with-args 'completion-sole-match-functions string)) (when exit-fun (when (eq finished 'unknown) (setq finished (if (eq (try-completion string minibuffer-completion-table minibuffer-completion-predicate) t) 'finished 'exact))) (funcall exit-fun string finished)) (when (and message ;; Don't output any message if the exit-fun already did so. (equal pre-msg (and exit-fun (current-message)))) (completion--message message)))) (defvar completion-sole-match-functions () "Functions to be run when completion results in only one match. Each function must accept that completion as its first arg.") In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.16299 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: [PATCH] RE: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion References: In-Reply-To: Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Dec 2018 18:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154386318817348 (code B ref 33595); Mon, 03 Dec 2018 18:54:01 +0000 Received: (at 33595) by debbugs.gnu.org; 3 Dec 2018 18:53:08 +0000 Received: from localhost ([127.0.0.1]:59403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTtL8-0004Vh-BG for submit@debbugs.gnu.org; Mon, 03 Dec 2018 13:53:08 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:41030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTtL5-0004VA-R3 for 33595@debbugs.gnu.org; Mon, 03 Dec 2018 13:53:04 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB3InFka021728 for <33595@debbugs.gnu.org>; Mon, 3 Dec 2018 18:52:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type; s=corp-2018-07-02; bh=uOIxhbc/oQhoyqqww+W6Tn9bWA8tssOeuhyvdoehils=; b=HGlEgXrbbToZbtkbQhiBLeWbOfX3fpJuW+MHaXSDRZtXaiurT2ht/og+tTizU3PqEb6p RgSWAMXw+ZMJw1sySMvEbiVDZVvzJrakXwx3eRJ95necWD30u3rCkqYYE9+j6RAI1Upp vl1cCVWkAFzlhFqKetG3uSHvc/qpCjw2h+egSRpy7fWeiBRVYBsWhm3nzG9S780re/Up m2AWkm78VBV6dbKbFLKqxHn8xFtZxxjFw88oQicJ8RlrGwhIzocoolNk6fYKX3bYUurk 2cYQwAZcoh2WI2iTnVkBMLOkq/vl7JjsIE1pYGaJw7/WPiXt+ro3ZVMpj+i/SK5fAEYQ vg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2p3jxr849b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <33595@debbugs.gnu.org>; Mon, 03 Dec 2018 18:52:57 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wB3IquBa028521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <33595@debbugs.gnu.org>; Mon, 3 Dec 2018 18:52:56 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB3IqugN021691 for <33595@debbugs.gnu.org>; Mon, 3 Dec 2018 18:52:56 GMT MIME-Version: 1.0 Message-ID: <5de4751e-8389-4400-aafe-9225e9470f01@default> Date: Mon, 3 Dec 2018 10:52:55 -0800 (PST) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4771.0 (x86)] Content-Type: multipart/mixed; boundary="__154386317597254993abhmp0018.oracle.com" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9096 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812030173 X-Spam-Score: -2.3 (--) 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: -3.3 (---) --__154386317597254993abhmp0018.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The attached patch implements this enhancement. Simple example use cases: (defun my-find-file-other-window (filename &optional wildcards) "`find-file-other-window', but show file info if only one completion matc= hes." (interactive (unwind-protect (progn (add-hook 'completion-sole-match-functions 'describe-file) (find-file-read-args "Find file in other window: " (confirm-nonexistent-file-or-buffer))) (remove-hook 'completion-sole-match-functions 'describe-file))) (find-file-other-window filename wildcards)) (defun my-describe-function (function) "`describe-function', but show output if only one completion matches." (interactive (unwind-protect (progn (add-hook 'completion-sole-match-functions (lambda (fn) (describe-function (intern fn)))) (let* ((fn (function-called-at-point)) (enable-recursive-minibuffers t) (val (completing-read (if fn (format "Describe function (default %s): " fn) "Describe function: ") #'help--symbol-completion-table (lambda (f) (or (fboundp f) (get f 'function-documentation))) t nil nil (and fn (symbol-name fn))))) (unless (equal val "") (setq fn (intern val))) (unless (and fn (symbolp fn)) (user-error "You didn't specify a function symbol")) (unless (or (fboundp fn) (get fn 'function-documentation)) (user-error "Symbol's function definition is void: %s" fn)) (list fn)))) (remove-hook 'completion-sole-match-functions (lambda (fn) (describe-function (intern fn))))) (describe-function function)) ---- Or, using macro `with-hook-added' (see bug #33601): (defun my-find-file-other-window (filename &optional wildcards) "`find-file-other-window', but show file info if only one completion matc= hes." (interactive (with-hook-added completion-sole-match-functions describe-file (find-file-read-args "Find file in other window: " (confirm-nonexistent-file-or-buffer)))) (find-file-other-window filename wildcards)) (defun my-describe-function (function) "`describe-function', but show output if only one completion matches." (interactive (with-hook-added completion-sole-match-functions (lambda (fn) (describe-function (intern fn))) (let* ((fn (function-called-at-point)) (enable-recursive-minibuffers t) (val (completing-read (if fn (format "Describe function (default %s): " fn) "Describe function: ") #'help--symbol-completion-table (lambda (f) (or (fboundp f) (get f 'function-documentation))) t nil nil (and fn (symbol-name fn))))) (unless (equal val "") (setq fn (intern val))) (unless (and fn (symbolp fn)) (user-error "You didn't specify a function symbol")) (unless (or (fboundp fn) (get fn 'function-documentation)) (user-error "Symbol's function definition is void: %s" fn)) (list fn)))) (describe-function function)) --__154386317597254993abhmp0018.oracle.com Content-Type: application/octet-stream; name="minibuffer-2018-12-03a.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minibuffer-2018-12-03a.patch" ZGlmZiAtdSBtaW5pYnVmZmVyLmVsIG1pbmlidWZmZXItMjAxOC0xMi0wM2EtcGF0Y2hlZC5lbAot LS0gbWluaWJ1ZmZlci5lbAkyMDE4LTEyLTAzIDA5OjIzOjQ1Ljg1ODYwODIwMCAtMDgwMAorKysg bWluaWJ1ZmZlci0yMDE4LTEyLTAzYS1wYXRjaGVkLmVsCTIwMTgtMTItMDMgMDk6Mjc6MTcuODYy Mzk3MzAwIC0wODAwCkBAIC03NTMsNiArNzUzLDEwIEBACiB0aGUgc2Vjb25kIGZhaWxlZCBhdHRl bXB0IHRvIGNvbXBsZXRlLiIKICAgOnR5cGUgJyhjaG9pY2UgKGNvbnN0IG5pbCkgKGNvbnN0IHQp IChjb25zdCBsYXp5KSkpCiAKKyhkZWZ2YXIgY29tcGxldGlvbi1zb2xlLW1hdGNoLWZ1bmN0aW9u cyAoKQorICAiRnVuY3Rpb25zIHRvIGJlIHJ1biB3aGVuIGNvbXBsZXRpb24gcmVzdWx0cyBpbiBv bmx5IG9uZSBtYXRjaC4KK0VhY2ggZnVuY3Rpb24gbXVzdCBhY2NlcHQgdGhhdCBjb21wbGV0aW9u IGFzIGl0cyBmaXJzdCBhcmcuIikKKwogKGRlZmNvbnN0IGNvbXBsZXRpb24tc3R5bGVzLWFsaXN0 CiAgICcoKGVtYWNzMjEKICAgICAgY29tcGxldGlvbi1lbWFjczIxLXRyeS1jb21wbGV0aW9uIGNv bXBsZXRpb24tZW1hY3MyMS1hbGwtY29tcGxldGlvbnMKQEAgLTE3NjksNiArMTc3Myw4IEBACiAg IChsZXQqICgoZXhpdC1mdW4gKHBsaXN0LWdldCBjb21wbGV0aW9uLWV4dHJhLXByb3BlcnRpZXMg OmV4aXQtZnVuY3Rpb24pKQogICAgICAgICAgKHByZS1tc2cgKGFuZCBleGl0LWZ1biAoY3VycmVu dC1tZXNzYWdlKSkpKQogICAgIChjbC1hc3NlcnQgKG1lbXEgZmluaXNoZWQgJyhleGFjdCBzb2xl IGZpbmlzaGVkIHVua25vd24pKSkKKyAgICAod2hlbiAoZXEgZmluaXNoZWQgJ2ZpbmlzaGVkKQor ICAgICAgKHJ1bi1ob29rLXdpdGgtYXJncyAnY29tcGxldGlvbi1zb2xlLW1hdGNoLWZ1bmN0aW9u cyBzdHJpbmcpKQogICAgICh3aGVuIGV4aXQtZnVuCiAgICAgICAod2hlbiAoZXEgZmluaXNoZWQg J3Vua25vd24pCiAgICAgICAgIChzZXRxIGZpbmlzaGVkCg== --__154386317597254993abhmp0018.oracle.com-- From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: [PATCH] RE: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Dec 2018 18:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154602338029934 (code B ref 33595); Fri, 28 Dec 2018 18:57:02 +0000 Received: (at 33595) by debbugs.gnu.org; 28 Dec 2018 18:56:20 +0000 Received: from localhost ([127.0.0.1]:40657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcxIx-0007mk-Pg for submit@debbugs.gnu.org; Fri, 28 Dec 2018 13:56:20 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:59512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcxIu-0007mR-FT for 33595@debbugs.gnu.org; Fri, 28 Dec 2018 13:56:17 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBSIn0WD126293 for <33595@debbugs.gnu.org>; Fri, 28 Dec 2018 18:56:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=UvPJq0/KsBsxPp1vE5Kwjng9pHLZ/EYv8+Z1LzlnD9M=; b=LX4Rjp1Ow0IrPJHDeb3mb5HlyjXWZeaHHmPKOneK3wY0P3Ii0c4vcSYsH6WWE91bDtE9 0OSYfJQ+vbOfkBcJ9RLO4P3vtn4H6arE66dvJ+EGwPsILFavCKrT0ngDySpJlu3qHb4q 1Osj2drCeMokIEAnO42nrDkOlxVtKXyz9rfUYb3M0S+I04Dd+7SrZFXlox08TSR59DQL XtZBO3cQYo8lYtvBbpxY/fRS/83vdcipku/Ahdjq4Yy80u1+XLbMZCezuJnuI57QhMZz 0bIOOrluG4JsMOKRiVK+3fpwyDzD0QZR+RHnnZv2ZZkASJ9gEHVjhTmqrKP2s735jXT2 Lw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2phcpu2715-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <33595@debbugs.gnu.org>; Fri, 28 Dec 2018 18:56:10 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wBSIu98a002337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <33595@debbugs.gnu.org>; Fri, 28 Dec 2018 18:56:09 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBSIu8Xr008152 for <33595@debbugs.gnu.org>; Fri, 28 Dec 2018 18:56:09 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 28 Dec 2018 10:56:08 -0800 (PST) From: Drew Adams References: <5de4751e-8389-4400-aafe-9225e9470f01@default> In-Reply-To: <5de4751e-8389-4400-aafe-9225e9470f01@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9120 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812280163 X-Spam-Score: -2.3 (--) 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: -3.3 (---) ping. Would someone please consider committing this patch? Thx. ------------------ diff -u minibuffer.el minibuffer-2018-12-03a-patched.el --- minibuffer.el=092018-12-03 09:23:45.858608200 -0800 +++ minibuffer-2018-12-03a-patched.el=092018-12-03 09:27:17.862397300 -0800 @@ -753,6 +753,10 @@ the second failed attempt to complete." :type '(choice (const nil) (const t) (const lazy))) =20 +(defvar completion-sole-match-functions () + "Functions to be run when completion results in only one match. +Each function must accept that completion as its first arg.") + (defconst completion-styles-alist '((emacs21 completion-emacs21-try-completion completion-emacs21-all-completions @@ -1769,6 +1773,8 @@ (let* ((exit-fun (plist-get completion-extra-properties :exit-function)) (pre-msg (and exit-fun (current-message)))) (cl-assert (memq finished '(exact sole finished unknown))) + (when (eq finished 'finished) + (run-hook-with-args 'completion-sole-match-functions string)) (when exit-fun (when (eq finished 'unknown) (setq finished From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: [PATCH] RE: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Dec 2018 08:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams , Stefan Monnier Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154607097822682 (code B ref 33595); Sat, 29 Dec 2018 08:10:02 +0000 Received: (at 33595) by debbugs.gnu.org; 29 Dec 2018 08:09:38 +0000 Received: from localhost ([127.0.0.1]:40808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gd9gg-0005tl-AY for submit@debbugs.gnu.org; Sat, 29 Dec 2018 03:09:38 -0500 Received: from eggsout.gnu.org ([209.51.188.92]:48477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gd9gf-0005ta-FB for 33595@debbugs.gnu.org; Sat, 29 Dec 2018 03:09:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gd9fo-0003bD-Gl for 33595@debbugs.gnu.org; Sat, 29 Dec 2018 03:09:32 -0500 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 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gd9fo-0003b9-Ce; Sat, 29 Dec 2018 03:08:44 -0500 Received: from [176.228.60.248] (port=2631 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gd9fn-0000ld-Vr; Sat, 29 Dec 2018 03:08:44 -0500 Date: Sat, 29 Dec 2018 10:08:25 +0200 Message-Id: <83imzc69hi.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Drew Adams on Fri, 28 Dec 2018 10:56:08 -0800 (PST)) References: <5de4751e-8389-4400-aafe-9225e9470f01@default> 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: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Fri, 28 Dec 2018 10:56:08 -0800 (PST) > From: Drew Adams > > ping. > > Would someone please consider committing this patch? Thx. Stefan, any comments? If okay, I'd like to push this to master. > diff -u minibuffer.el minibuffer-2018-12-03a-patched.el > --- minibuffer.el 2018-12-03 09:23:45.858608200 -0800 > +++ minibuffer-2018-12-03a-patched.el 2018-12-03 09:27:17.862397300 -0800 > @@ -753,6 +753,10 @@ > the second failed attempt to complete." > :type '(choice (const nil) (const t) (const lazy))) > > +(defvar completion-sole-match-functions () > + "Functions to be run when completion results in only one match. > +Each function must accept that completion as its first arg.") > + > (defconst completion-styles-alist > '((emacs21 > completion-emacs21-try-completion completion-emacs21-all-completions > @@ -1769,6 +1773,8 @@ > (let* ((exit-fun (plist-get completion-extra-properties :exit-function)) > (pre-msg (and exit-fun (current-message)))) > (cl-assert (memq finished '(exact sole finished unknown))) > + (when (eq finished 'finished) > + (run-hook-with-args 'completion-sole-match-functions string)) > (when exit-fun > (when (eq finished 'unknown) > (setq finished > > > > From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: [PATCH] RE: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 01:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 33595@debbugs.gnu.org, Drew Adams Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154639219321788 (code B ref 33595); Wed, 02 Jan 2019 01:24:01 +0000 Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 01:23:13 +0000 Received: from localhost ([127.0.0.1]:44221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geVFY-0005fL-Se for submit@debbugs.gnu.org; Tue, 01 Jan 2019 20:23:13 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:45881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geVFW-0005fD-Gt for 33595@debbugs.gnu.org; Tue, 01 Jan 2019 20:23:11 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x021N8RP005735; Tue, 1 Jan 2019 20:23:09 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B70F6AE92F; Tue, 1 Jan 2019 20:23:08 -0500 (EST) From: Stefan Monnier Message-ID: References: <5de4751e-8389-4400-aafe-9225e9470f01@default> <83imzc69hi.fsf@gnu.org> Date: Tue, 01 Jan 2019 20:23:08 -0500 In-Reply-To: <83imzc69hi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Dec 2018 10:08:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered GEN_SPAM_FEATRE=0.1, EDT_SA_DN_PASS=0, RV6451=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6451> : inlines <6990> : streams <1808866> : uri <2773427> X-Spam-Score: -2.3 (--) 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: -3.3 (---) > Stefan, any comments? If okay, I'd like to push this to master. I'll take a look at it later today. From where I sit, I think I won't like it, but I need to look more closely to be sure, Stefan From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 04:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.15464040707573 (code B ref 33595); Wed, 02 Jan 2019 04:42:01 +0000 Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 04:41:10 +0000 Received: from localhost ([127.0.0.1]:44238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geYL7-0001y5-Uk for submit@debbugs.gnu.org; Tue, 01 Jan 2019 23:41:10 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:48671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geYL6-0001xy-I7 for 33595@debbugs.gnu.org; Tue, 01 Jan 2019 23:41:08 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x024f7ZH022535; Tue, 1 Jan 2019 23:41:07 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 12444AE92F; Tue, 1 Jan 2019 23:41:07 -0500 (EST) From: Stefan Monnier Message-ID: References: Date: Tue, 01 Jan 2019 23:41:06 -0500 In-Reply-To: (Drew Adams's message of "Sun, 2 Dec 2018 20:07:07 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6451=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6451> : inlines <6990> : streams <1808879> : uri <2773497> X-Spam-Score: -2.3 (--) 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: -3.3 (---) > Enhancement request: When `try-completion' returns `t' there is a > "unique match which is exact". Please add an abnormal hook at this > point, which accepts that sole completion as argument. I'm not sure exactly what's the intention behind this: would it be an option that influences the UI or the completion table? More concretely, do you expect a hook function places on this variable to apply for "any completion table" or would it be specific to a particular completion table? The example you give in `my-describe-function` gives me the impression that those would inevitably be tightly linked to the completion table. So instead of a hook variable, it would probably make more sense to add a new `completion-extra-properties` alongside to :exit-function. Do you have other example applications than `my-describe-function` (to be honest, I found this example not very compelling). > no exit function. `try-completion' is the logical place to do this, I Definitely not: try-completion can be used in lots of other non-completion uses, can be called many times for a single completion operation, etc... try-completion should be renamed to `find-common-prefix`. Stefan PS: I'm not sure I completely understand the intended behavior of `my-describe-function`, but I get the impression that for this particular example, a maybe even better approach is to use minibuffer-with-setup-hook to set a post-command-hook that calls describe-function whenever the minibuffer names a valid function (whether we get there via completion or plain typing, and regardless if it's the sole completion). From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 07:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154641312222158 (code B ref 33595); Wed, 02 Jan 2019 07:13:01 +0000 Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 07:12:02 +0000 Received: from localhost ([127.0.0.1]:44266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geah8-0005lK-90 for submit@debbugs.gnu.org; Wed, 02 Jan 2019 02:12:02 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:51042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geah6-0005km-2O for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 02:12:00 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x027AIlf071227; Wed, 2 Jan 2019 07:11:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=QKAZyDBTD9YrFS7QZjb42k7oylXhc5Io28se+t7gphM=; b=qvfkSUJus9fvasEF1pHqFnz9iwRjZMeaN5e7kDYYT1eb19+RLhDaVU6tghZh3PRUb+KR 5gfU4N3ImyzWLzj83QbWuk7k/3WSFe9AP/hyfvn+scYG2rljcnwbrr12xlcp0pXUOdkj HUh28dhslGGaiDlIFfF4nhUSHZwNWoHUVJlmmNMDB7GCp0F9GPbOyCagKb3G9NBiKnSo 3vFjqLihwUEy3VOwivYDhZIV/xK9qVHuyV/Iy1t141SQPVLmnMBRGUupVmDcuYhFTdOl Mt7gSooyCLD4D5/xUuSv1n9pkXxumEoNVdCIuVli5g0zsB3Ws7Hc/VDucfO2XC+bkaJB tw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2pp0btrt8v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Jan 2019 07:11:53 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x027BqXF006419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jan 2019 07:11:52 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x027Bouc031774; Wed, 2 Jan 2019 07:11:51 GMT MIME-Version: 1.0 Message-ID: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> Date: Tue, 1 Jan 2019 23:11:49 -0800 (PST) From: Drew Adams References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9123 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020065 X-Spam-Score: -2.3 (--) 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: -3.3 (---) > > Enhancement request: When `try-completion' returns `t' there is a > > "unique match which is exact". Please add an abnormal hook at this > > point, which accepts that sole completion as argument. >=20 > I'm not sure exactly what's the intention behind this: would it be an > option that influences the UI or the completion table? Not sure what that dichotomy is, but it doesn't influence the completion table at all. It's about what gets done with a completion, not how completion is done. > More concretely, do you expect a hook function places on this variable > to apply for "any completion table" or would it be specific to > a particular completion table? The former. At least I don't see how this has anything to do with what kind of completion is used or how it's done. > The example you give in `my-describe-function` gives me the impression > that those would inevitably be tightly linked to the completion table. > So instead of a hook variable, it would probably make more sense to add > a new `completion-extra-properties` alongside to :exit-function. No, I don't think that's relevant. > Do you have other example applications than `my-describe-function` (to > be honest, I found this example not very compelling). >=20 > > no exit function. `try-completion' is the logical place to do this, I >=20 > Definitely not: try-completion can be used in lots of other > non-completion uses, can be called many times for a single completion > operation, etc... try-completion should be renamed to `find-common- > prefix`. Fine. Not `try-completion'. Please try the simple, one-line patch I sent. It's really not a big deal. > PS: I'm not sure I completely understand the intended behavior of > `my-describe-function`, but I get the impression that for this > particular example, a maybe even better approach is to use > minibuffer-with-setup-hook to set a post-command-hook that calls > describe-function whenever the minibuffer names a valid function > (whether we get there via completion or plain typing, and regardless > if it's the sole completion). No, that's something else. This is not about describing everything that shows up in the minibuffer. It's about a user asking to do something with a (full) completion - on demand. Something defined by the person who wrote the code calling for completion. Something specific for the command that is asking for user input, or at least for its candidates. What you say is not clear to me. I don't know whether there are particular completion tables to which this should not apply. I don't see why there would be. This doesn't affect completion at all. It just takes a (full) completion and does something with it - it takes effect when completion is done, but before the function that initiates completion, such as `completing-read', is finished reading user input. The user has not hit RET or C-g. The user can still change the minibuffer input. I don't think what I described or showed in code is complex, so it's not clear to me what's unclear to you. ;-) [To be clear about one thing: This is not at all for _me_, as it has no effect with my setup, which uses Icicles, which (1) completes and uses TAB differently and (2) has a different mechanism for optionally doing something when there is a sole completion. I just thought/think that this might be useful for some users (and it is simple).] When TAB tells you that there is only one completion for your input (and completes to it), you can hit RET to choose that completion (act on it). But in some cases you might want to first, or instead, take some other action on it - in particular, maybe get some more info about it. This lets you do that. Hitting TAB again at that point does nothing now - it's a no-op. If this hook were bound it would instead do something. I imagine that typically its action would be to display some info about that completion or what will happen if you choose it (RET). But the action could be anything, and it could even ignore the completion. She who writes a command that calls `completing-read' or `read-file-name' would decide what sole-completion action, if any, to provide (and document it as part of the command). For one thing, seeing such additional info might help a user decide whether she really wants to choose (RET) that completion. Sometimes it's not obvious from the completed text (e.g. a command or file name) just what is involved. The second of the two simple examples didn't impress you. OK. (Did you try it at all?) The first example depends on a function `describe-file'. I have such a command but forgot that vanilla Emacs doesn't. Here's what `describe-file' shows for file `help-fns+.el' (where it's defined): ~/foobar/help-fns+.el --------------------- File Type: Normal file Permissions: -rw-rw-rw- Size in bytes: 174435 Time of last access: Wed Jul 25 07:59:09 2018 (Pacific Daylight Time= ) Time of last modification: Thu May 10 15:48:56 2018 (Pacific Daylight Time= ) Time of last status change: Wed Jul 25 07:59:09 2018 (Pacific Daylight Time= ) Number of links: 1 User ID (UID): 37786 Group ID (GID): 513 Inode: 281474976869587 Device number: 315267003 And here's the doc string: Describe the file named FILENAME. If FILENAME is nil, describe current directory ('default-directory'). If the file is an image file then: * Show a thumbnail of the image as well. * If you have command-line tool 'exiftool' installed and in your '$PATH' or 'exec-path', then show EXIF data (metadata) about the image. See standard Emacs library 'image-dired.el' for more information about 'exiftool'. If FILENAME is the name of an autofile bookmark and you use library 'Bookmark+', then show also the bookmark information (tags etc.). In this case, a prefix arg shows the internal form of the bookmark. So the idea behind this simple example would be that you could see the file permissions and timestamps, which might help you decide whether you want to hit RET and act on the file (however your command might act on it). The alternative is to hit `C-g' and fiddle a bit to find out such info, and then, if you're reassured it's the right thing to do, invoke your command again. The second example does the same kind of thing, for a function instead of a file - before you choose a function, to do something with it, you might want to check its doc to be more sure. This example has nothing to do with the function that's a completion candidate being "inevitably ... tightly linked to the completion table." It's just an example of choosing among some names (in this case function names). You could as easily be choosing among names "flobitz", "orndorf", and "ornplissle", and want to see some more info about one of them. You can first complete to orndorf, thinking that's probably what you want, but if unsure, hit TAB again to see some more info, then change your input to "ornplissle" and hit RET. It's really trivial - a one-line change, which has no effect at all unless you hit TAB an extra time, and even then it has no effect unless the hook is not empty. Now, it's also possible that a hook function would do the same thing as what RET does - or something similar. I don't expect that that will be common, but it's possible. When completing to an Info node name for `g', a hook function could take you to that node (just like hitting RET will do), for a peek. But as the input-reading command isn't finished you could change your input (or hit C-g) to cancel that movement (e.g. moving back where you were). If you just changed your input you could then move to a different node. Again, not a real example. The point here is just that the extra-TAB action _could_ be the same as or similar to the RET action (which ends inputting). It's up to the code that reads the user input to decide what, if anything, to put on the hook. From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 15:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.15464428823037 (code B ref 33595); Wed, 02 Jan 2019 15:29:02 +0000 Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 15:28:02 +0000 Received: from localhost ([127.0.0.1]:44871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geiR7-0000ml-TJ for submit@debbugs.gnu.org; Wed, 02 Jan 2019 10:28:02 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geiR5-0000mY-Lp for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 10:28:01 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x02FRwrg011886; Wed, 2 Jan 2019 10:27:58 -0500 Received: by pastel.home (Postfix, from userid 20848) id 291A46A7F5; Wed, 2 Jan 2019 10:27:58 -0500 (EST) From: Stefan Monnier Message-ID: References: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> Date: Wed, 02 Jan 2019 10:27:58 -0500 In-Reply-To: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> (Drew Adams's message of "Tue, 1 Jan 2019 23:11:49 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6452=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6452> : inlines <6990> : streams <1808922> : uri <2773730> X-Spam-Score: -2.3 (--) 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: -3.3 (---) >> More concretely, do you expect a hook function places on this variable >> to apply for "any completion table" or would it be specific to >> a particular completion table? > The former. At least I don't see how this has anything to > do with what kind of completion is used or how it's done. Not sure what you mean by "kind of completion" but a completion table describes the "kind" of completion in the sense of describing the set of possible completions (i.e. either a set of function names, or a set of file names, or ...). In your example, the hook function calls `describe-function` so it only makes sense when the completion table is a set of function names, an becomes absurd when it's a set of file names, or Git revisions, ... So in your example, your hook function is very tightly linked to the completion table. I still don't understand this example well enough to understand if/how it's linked to the UI (e.g. what should happen if the user happens to use, say, ido-ubiquitous to complete his function names). >> The example you give in `my-describe-function` gives me the impression >> that those would inevitably be tightly linked to the completion table. >> So instead of a hook variable, it would probably make more sense to add >> a new `completion-extra-properties` alongside to :exit-function. > No, I don't think that's relevant. What do you mean by "relevant"? It would require the code to be a bit different but you could get the exact same behavior with it. >> PS: I'm not sure I completely understand the intended behavior of >> `my-describe-function`, but I get the impression that for this >> particular example, a maybe even better approach is to use >> minibuffer-with-setup-hook to set a post-command-hook that calls >> describe-function whenever the minibuffer names a valid function >> (whether we get there via completion or plain typing, and regardless >> if it's the sole completion). > > No, that's something else. This is not about describing > everything that shows up in the minibuffer. It's about > a user asking to do something with a (full) completion - on > demand. Something defined by the person who wrote the code > calling for completion. Something specific for the command > that is asking for user input, or at least for its candidates. One part I don't fully understand is why this code wants to call `describe-function` only and exactly when the user hits TAB and it completes to an sole match. Why should the user not want to see that same result when typing the name explicitly instead of completing to it? Why should the user not want to see the same result when completing to an exact-but-not-sole match? Another thing I don't understand about your example is: what is the user expected to do after hitting TAB (which completed to a sole match)? The only thing left to do seems to be RET but that's redundant since `describe-function` was already called. > [To be clear about one thing: This is not at all for _me_, as > it has no effect with my setup, which uses Icicles, which (1) > completes and uses TAB differently and (2) has a different > mechanism for optionally doing something when there is a sole > completion. I just thought/think that this might be useful > for some users (and it is simple).] It's not as simple as it seems: if the user goes to some other buffer in the middle of the completion, your completion-sole-match-functions will not wreak havoc in unrelated completions. > When TAB tells you that there is only one completion for your > input (and completes to it), you can hit RET to choose that > completion (act on it). But in some cases you might want to > first, or instead, take some other action on it - in particular, > maybe get some more info about it. This lets you do that. Why only in that specific case? > Hitting TAB again at that point does nothing now - it's a no-op. > If this hook were bound it would instead do something. Ah, so you want this hook to be run when TAB is hit a second time, in which case it normally does nothing (tho that depends on the config, it may also display the *Completions* buffer)? I think I'm beginning to understand. But I think it belongs in the completion data (i.e. alongside :exit-function). Stefan From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 16:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.15464460678598 (code B ref 33595); Wed, 02 Jan 2019 16:22:01 +0000 Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 16:21:07 +0000 Received: from localhost ([127.0.0.1]:44917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gejGV-0002Eb-6X for submit@debbugs.gnu.org; Wed, 02 Jan 2019 11:21:07 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:41504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gejGT-0002Dm-Q3 for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 11:21:06 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x02GIlfc051560; Wed, 2 Jan 2019 16:20:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=XzPY5Nwups7QQRQdpPmuxOG5qrqakEnQ41kwo/W87Jk=; b=0AmIM7B50HvBSaRTT0dFCfIdc4tOUmDamCKwh8CdJjThqWlMsI95yJzIJ1fppzZIeNjm XvCawdru2cjrK4XUh1TpRUO7T4IMCtMzgKjngDs3xjyOd5v3Aptin6jaRRaNHXrnzo/A YT3oWjT4D5XxgCgJpZYvmXsezk9yDuOm4Rr18G/XtN5lgbQDVBLXtyh9cs1hC7DxqGfl HFF4x7krQZ2SASD6pcbjAXiK+Tblq2EDCIjre1LXIrbFDBZXLHIoAclL4FSHG/Z8L2aZ ZS6p4nxItAVI84nxdRjZB4l2qopT9vWq5PSsQhacIN5O39BrUJgsTqV9ZHRZgWb/vHVS rw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2pp1jr2t1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Jan 2019 16:20:59 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x02GKrU0006641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jan 2019 16:20:53 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x02GKqMw003383; Wed, 2 Jan 2019 16:20:53 GMT MIME-Version: 1.0 Message-ID: <4f16869e-5f88-47bc-a118-5ea37cfb6d9a@default> Date: Wed, 2 Jan 2019 08:20:51 -0800 (PST) From: Drew Adams References: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9124 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020147 X-Spam-Score: -2.3 (--) 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: -3.3 (---) > >> More concretely, do you expect a hook function places on this variable > >> to apply for "any completion table" or would it be specific to > >> a particular completion table? > > The former. At least I don't see how this has anything to > > do with what kind of completion is used or how it's done. >=20 > Not sure what you mean by "kind of completion" but a completion table > describes the "kind" of completion in the sense of describing the set of > possible completions (i.e. either a set of function names, or a set of > file names, or ...). >=20 > In your example, the hook function calls `describe-function` so it only > makes sense when the completion table is a set of function names, an > becomes absurd when it's a set of file names, or Git revisions, ... If that's what you meant by your question then yes, I think I answered that when I said that the person who writes the code that invokes `completing-read', say, is the person who adds a function to the hook, or binds the hook - or not (does not use the hook). What you put on the hook typically is specific to the completion candidates you provide, and to the command that uses the candidate the user chooses. If that's what you meant by "tightly linked to the completion table", then yes. But the hook does not change the completion table or change completion in any way. It's only about what a user does with a completion (the "UI" you mentioned?). > So in your example, your hook function is very tightly linked to the > completion table. I still don't understand this example well enough to > understand if/how it's linked to the UI (e.g. what should happen if the > user happens to use, say, ido-ubiquitous to complete his function names). Ido? Idon't. I don't know either. Try it, to see. ;-) > >> The example you give in `my-describe-function` gives me the impression > >> that those would inevitably be tightly linked to the completion table. > >> So instead of a hook variable, it would probably make more sense to ad= d > >> a new `completion-extra-properties` alongside to :exit-function. > > No, I don't think that's relevant. >=20 > What do you mean by "relevant"? It would require the code to be a bit > different but you could get the exact same behavior with it. It's not clear yet that you are clear about what this is about. But if you feel you are, and if you think there's a better way to provide such behavior to users, go for it. As I said, I don't use this myself. It's just something simple that I saw as possible, easy, and (I expect) likely to be of some (limited) use. If you want to close the bug, I won't cry. > >> PS: I'm not sure I completely understand the intended behavior of > >> `my-describe-function`, but I get the impression that for this > >> particular example, a maybe even better approach is to use > >> minibuffer-with-setup-hook to set a post-command-hook that calls > >> describe-function whenever the minibuffer names a valid function > >> (whether we get there via completion or plain typing, and regardle= ss > >> if it's the sole completion). > > > > No, that's something else. This is not about describing > > everything that shows up in the minibuffer. It's about > > a user asking to do something with a (full) completion - on > > demand. Something defined by the person who wrote the code > > calling for completion. Something specific for the command > > that is asking for user input, or at least for its candidates. >=20 > One part I don't fully understand is why this code wants to call > `describe-function` only and exactly when the user hits TAB and it > completes to an sole match. Why should the user not want to see that > same result when typing the name explicitly instead of completing to it? I never said a user could not want that. But there is a difference between typing something and knowing that it is one of a set of provided choices. Doing this only for a sole completion (which is what I'd recommend here) avoids having it kick in at a zillion places where a user likely doesn't want it. In my view of this it would be only on demand, and only when a user knows that what's in the minibuffer is a full completion (what Emacs calls completed and unique). That's the goal here. But feel free to design something different, for some different, but perhaps related, purpose. > Why should the user not want to see the same result when completing to > an exact-but-not-sole match? A user might. See above. Users can want all kinds of things. Different users, and the same user, can want different things at different times. This simple suggestion is not trying to do more than what I suggested. It's not trying to provide an extended eldoc or a partial Icicles/Helm or anything of the sort. The hook function can do pretty much anything with the completion, and it can ignore it. It's not limited to providing more info about the completion. This just lets a user, on demand, invoke an action (defined by whoever wrote the code invoking the input-reading function) on user input that has already been completed (the input is complete and unique). That's all. Really not a big deal. > Another thing I don't understand about your example is: what is the user > expected to do after hitting TAB (which completed to a sole match)? > The only thing left to do seems to be RET but that's redundant since > `describe-function` was already called. >=20 > > [To be clear about one thing: This is not at all for _me_, as > > it has no effect with my setup, which uses Icicles, which (1) > > completes and uses TAB differently and (2) has a different > > mechanism for optionally doing something when there is a sole > > completion. I just thought/think that this might be useful > > for some users (and it is simple).] >=20 > It's not as simple as it seems: if the user goes to some other buffer in > the middle of the completion, your completion-sole-match-functions will > not wreak havoc in unrelated completions. I don't know what you mean. Maybe give a specific example (e.g. recipe, using the patch)? Or not. I haven't tried to look for problems this might introduce, as none came to mind spontaneously. Do you really see something problematic here? I don't want to spend a lot of time on this. If you don't get it, or you don't think it's helpful, or you think it's problematic, please feel free to drop it and close the bug. No harm done. But I'm happy to answer questions about what the behavior or intention is, if I know the answers. IOW, if you're interested then we can continue to chat if something's not clear or there's a problem, but if you're not interested then let's call it quits. > > When TAB tells you that there is only one completion for your > > input (and completes to it), you can hit RET to choose that > > completion (act on it). But in some cases you might want to > > first, or instead, take some other action on it - in particular, > > maybe get some more info about it. This lets you do that. >=20 > Why only in that specific case? See above. Did I answer that sufficiently? > > Hitting TAB again at that point does nothing now - it's a no-op. > > If this hook were bound it would instead do something. >=20 > Ah, so you want this hook to be run when TAB is hit a second time, in > which case it normally does nothing (tho that depends on the config, it > may also display the *Completions* buffer)? Absolutely. If you just try the code I think it will become clear what the behavior and intention are. It's harder to describe than to experience. If you try it then maybe it will be easier to discuss any problems you see or further questions you have. > I think I'm beginning to understand. But I think it belongs in the > completion data (i.e. alongside :exit-function). I don't. But you're the expert on that. Go for it, if you think it's useful and that's a better approach. Do you think that's easier for someone writing a call to `completing-read' or `read-file-name', while giving users the same behavior? You're not just trying to promote uptake of `completion-extra-properties', are you? ;-) Really, I have no problem with your providing this some other way, or with deciding not to provide it at all. From unknown Tue Jun 17 01:43:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Jan 2019 03:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33595@debbugs.gnu.org Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.154648532913865 (code B ref 33595); Thu, 03 Jan 2019 03:16:02 +0000 Received: (at 33595) by debbugs.gnu.org; 3 Jan 2019 03:15:29 +0000 Received: from localhost ([127.0.0.1]:45125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1getTk-0003bY-SK for submit@debbugs.gnu.org; Wed, 02 Jan 2019 22:15:29 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:42905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1getTh-0003bP-Ss for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 22:15:26 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x033FOh3011452; Wed, 2 Jan 2019 22:15:24 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DACDBAE35F; Wed, 2 Jan 2019 22:15:23 -0500 (EST) From: Stefan Monnier Message-ID: References: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> <4f16869e-5f88-47bc-a118-5ea37cfb6d9a@default> Date: Wed, 02 Jan 2019 22:15:23 -0500 In-Reply-To: <4f16869e-5f88-47bc-a118-5ea37cfb6d9a@default> (Drew Adams's message of "Wed, 2 Jan 2019 08:20:51 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6452=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6452> : inlines <6990> : streams <1808969> : uri <2773957> X-Spam-Score: -2.3 (--) 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: -3.3 (---) >> So in your example, your hook function is very tightly linked to the >> completion table. I still don't understand this example well enough to >> understand if/how it's linked to the UI (e.g. what should happen if the >> user happens to use, say, ido-ubiquitous to complete his function names). > > Ido? Idon't. I don't know either. Try it, to see. ;-) More generally, the code you wrote shouldn't presume exactly which completion UI is used, so the API should let you provide some "show extra info" function, and then separately some UI may opt to use this function for example when completing a sole match. >> It's not as simple as it seems: if the user goes to some other buffer in >> the middle of the completion, your completion-sole-match-functions will >> not wreak havoc in unrelated completions. ^^^ now > I don't know what you mean. Maybe give a specific > example (e.g. recipe, using the patch)? Or not. The hook function is active as long as the minibuffer is active, so if the user uses recursive minibuffers, the hook function will apply not just to the originally planned completion but also to other completions that take place in recursive minibuffers. It's basically the same problem as the usual problem of passing extra parameters via dynamic scoping, where the dynamic let-binding doesn't apply only to the first call, but to all nested calls that may occur. Anyway, thanks, I think I see how to introduce that feature (and I suspect it's actually already covered by the company-compatibility extra properties). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 02 22:20:20 2019 Received: (at control) by debbugs.gnu.org; 3 Jan 2019 03:20:20 +0000 Received: from localhost ([127.0.0.1]:45129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1getYS-0003j1-Jb for submit@debbugs.gnu.org; Wed, 02 Jan 2019 22:20:20 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:36988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1getYQ-0003io-VI for control@debbugs.gnu.org; Wed, 02 Jan 2019 22:20:19 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x033H3hg127378 for ; Thu, 3 Jan 2019 03:20:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=DLhBu4/84ImLc+i7p5bQQp3PBLKEhF3vMmqsIEOwy8o=; b=jlQT43Wxfok0B6MpBzYx1eDfI4KSR+RtW5ingGWw7aiPEwTw9W+EOOvkpwaMppdqIRpo CnON07FE7d3OtHZ/hlKs24Dd+DnIzilH4DjOv4zNEHOOqKRusbMmgJWazDaceOvRO02W 75XxTFHKrm3uI8qouytPEJZXtTu0DGdTgAZzQdhZCZp4JJu8fxSaHupXzRqglU7vCEvJ QXkweOy1Rg0c15jkXwH2/agkAe//EmXQvaWSXJb9SSP3q7keUQ3IjcaxFIzaknq/VnA3 hE3o3lR2VUb4EQjtbOra29Kqj8QKJOleXF1NOF20qmSIXEnZ/93ltsEDp9OD7QoZ2nb/ oQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2pp1jr4wmx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 03 Jan 2019 03:20:12 +0000 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 x033KCEQ001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 3 Jan 2019 03:20:12 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x033KCuk000493 for ; Thu, 3 Jan 2019 03:20:12 GMT MIME-Version: 1.0 Message-ID: <001060ce-fd5d-4026-8d30-f9d3ef3f013b@default> Date: Wed, 2 Jan 2019 19:20:10 -0800 (PST) From: Drew Adams To: control@debbugs.gnu.org Subject: close 33595 X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9124 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=344 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030026 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 33595 thanks