From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: completing-read return meta-information? Date: Tue, 22 Sep 2015 10:21:10 -0500 Message-ID: <86oaguv5sp.fsf@stephe-leake.org> References: <86y4g6zcuo.fsf@stephe-leake.org> <7c37cd21-a9e0-48fa-b5a2-a32595c43dda@default> <86twquxnpa.fsf@stephe-leake.org> <861tdrwwhx.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442935798 23474 80.91.229.3 (22 Sep 2015 15:29:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 15:29:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 22 17:29:48 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 1ZePVs-0007on-AO for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2015 17:29:48 +0200 Original-Received: from localhost ([::1]:40806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZePVr-0006XD-MN for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2015 11:29:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZePO5-0001YA-Ry for emacs-devel@gnu.org; Tue, 22 Sep 2015 11:21:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZePO0-00009e-VQ for emacs-devel@gnu.org; Tue, 22 Sep 2015 11:21:45 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:42678) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZePO0-000093-Pa for emacs-devel@gnu.org; Tue, 22 Sep 2015 11:21:40 -0400 Original-Received: (qmail 5799 invoked by uid 0); 22 Sep 2015 15:21:38 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Sep 2015 15:21:38 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id LMMU1r00u2UdiVW01MMYKP; Tue, 22 Sep 2015 15:21:37 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=ff-B7xzCdYMA:10 a=jLzFABlbT2mSrxdb0pwA:9 Original-Received: from [76.218.37.33] (port=59507 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZePNp-0002D2-KX for emacs-devel@gnu.org; Tue, 22 Sep 2015 09:21:30 -0600 In-Reply-To: (Stefan Monnier's message of "Mon, 21 Sep 2015 15:51:18 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.18.3 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:190248 Archived-At: Stefan Monnier writes: >> It also achieves the goal of returning an absolute string from >> completing-read; that required advice on completing-read-default to call >> the new function completion-get-data-string. > > 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. I don't want that to be the display string. 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. 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. So this approach would require the user to always type tab, or go thru one more confirmation step after typing . I tried this approach early in this work, and could not make it work consistently. This discussion points out that "user input string" and "display string" have the same format; both can be passed to completion-try-completion and completion-test-completion. The only difference is that the strings returned by completion-all-completions all identifiy unique, valid files. So I think I'll merge those two string types to "user string"; that should make this clearer. > PS: Also, as a user, I think I'd rather see names like "dir/file" than > "file". You only need directory names when there are conflicting names; on many paths, there will be none or few. I mainly used that style because it meant the user string is a prefix of all the completions, which some of the completion primitives expect, so it made things simpler. On the other hand, I use the postfix uniquify style for buffer names, so I'm used to it :). I'll try to implement directory completion in both styles; this should be a user preference, just as it is in buffer names. -- -- Stephe