From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: completing-read return meta-information? Date: Sun, 27 Sep 2015 11:45:15 -0400 Message-ID: References: <86y4g6zcuo.fsf@stephe-leake.org> <7c37cd21-a9e0-48fa-b5a2-a32595c43dda@default> <86twquxnpa.fsf@stephe-leake.org> <861tdrwwhx.fsf@stephe-leake.org> <86oaguv5sp.fsf@stephe-leake.org> <86twqh78n7.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443368742 25345 80.91.229.3 (27 Sep 2015 15:45:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 15:45:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 17:45:31 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZgE8h-0005kC-Ub for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2015 17:45:24 +0200 Original-Received: from localhost ([::1]:57842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgE8h-0001s6-CU for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2015 11:45:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgE8e-0001rp-N8 for emacs-devel@gnu.org; Sun, 27 Sep 2015 11:45:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgE8a-0001dZ-I0 for emacs-devel@gnu.org; Sun, 27 Sep 2015 11:45:20 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgE8a-0001dV-Dv for emacs-devel@gnu.org; Sun, 27 Sep 2015 11:45:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArEwA731xV/2yixEVcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIxALNBIUGA0kiDcIzyMBAQEHAgEfizqFBQeELQWLRJNThmmNP4FFI4Fmgi4igngBAQE X-IPAS-Result: A0ArEwA731xV/2yixEVcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIxALNBIUGA0kiDcIzyMBAQEHAgEfizqFBQeELQWLRJNThmmNP4FFI4Fmgi4igngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="165974112" Original-Received: from 69-196-162-108.dsl.teksavvy.com (HELO pastel.home) ([69.196.162.108]) by ironport2-out.teksavvy.com with ESMTP; 27 Sep 2015 11:45:15 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 860B562239; Sun, 27 Sep 2015 11:45:15 -0400 (EDT) In-Reply-To: <86twqh78n7.fsf@stephe-leake.org> (Stephen Leake's message of "Sat, 26 Sep 2015 05:54:52 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190412 Archived-At: >>> Why can't you make completion-try-completion return an absolute filename >>> when there's only one match? >> The string returned from completion-try-completion is displayed in the >> minibuffer, as the completion prefix. That's right (tho only once it's unique). >> I don't want that to be the display string. I think that's a mistake. >> Part of the point of using path completion is that you don't care what >> directory the file is in. So having the absolute path displayed as the >> final completion feels like the system forcing you to care. No, you still don't have to type it, so you're not forced to care. But yes, you get to see it, so you can (even sub-consciously) double-check that it's indeed the one you want. >> More importantly, the user can type at any time; then >> test-completion should return t when it is passed the abbreviated >> display string from the first completion; that is known to be a unique >> valid completion. If the call to completing-read uses `require-match' (which I'd expect to be the case), then hitting RET at any time should work fine since if the file name is incomplete test-completion will return nil, so we'll call completion-try-completion. [ And depending on the exact value of `require-match' the expanded/absolute filename will be shown to the user or not. ] > (cons 'path path)))) IIUC this variable `path' holds a file name, not a list of directories, so the GNU Coding Standard would not want to use "path" here (since this word is only used for a list of directories as in load-path). You could use `filename' instead. Stefan