From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: completing-read return meta-information? Date: Mon, 28 Sep 2015 08:58:38 +0300 Message-ID: <5608D70E.9030406@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443419953 4873 80.91.229.3 (28 Sep 2015 05:59:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 05:59:13 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 07:59:08 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 1ZgRSt-0007Mk-F5 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 07:59:07 +0200 Original-Received: from localhost ([::1]:60633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgRSs-0004JI-TY for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 01:59:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgRSg-0004J4-Bp for emacs-devel@gnu.org; Mon, 28 Sep 2015 01:58:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgRSd-0001Rb-4K for emacs-devel@gnu.org; Mon, 28 Sep 2015 01:58:54 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:37564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgRSc-0001RX-UF for emacs-devel@gnu.org; Mon, 28 Sep 2015 01:58:51 -0400 Original-Received: by wicfx3 with SMTP id fx3so85182622wic.0 for ; Sun, 27 Sep 2015 22:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ZropKtKX0uw3X1AX/GvFGDjbcSKNkeO4gLiB9yztFho=; b=WGecRS9YNw2/y4D08Z6ZiGnLg2xyfMN1F6Ujn1HDa8YAZFjvlfHm0jRBd9HxRex88C 2NbjpfUgB1olfKt7U20xGVsXRbY/9sHOiAN4fMjhoVMYsZHD2JEsTxOtWQMUBNJ7eC2E lncUw2Y3i2mwLS9gYkPArxGHcZtLsJ+GmgszealOvb+FjryxqWXFVXxGYSLzOUA1pxnr JGiiBHhSYWKgAC5ylAaX5M97YsSsCIix2RYVUZE+Ump1yY5Hj4JH8dlIvh4DK9iT6len YgbW9HHswyhxalbHiayL/QEL6Pzo+zF/4mMHEzV02y68X0oRqhZUPuVvOG+JTxJBJybX 9dOg== X-Received: by 10.180.189.102 with SMTP id gh6mr15077818wic.95.1443419930331; Sun, 27 Sep 2015 22:58:50 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id l1sm16448126wjx.13.2015.09.27.22.58.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2015 22:58:49 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86oaguv5sp.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::233 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:190427 Archived-At: On 09/22/2015 06:21 PM, Stephen Leake wrote: >> 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 think the key distinction here is between "need to input" and "need to see". As long as the user doesn't need to input the directory, I think it's fine if they end up seeing it at some point. > 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. This sounds like it'll filter out all results if the user *does* input the directory, in all or at least some of the cases. Please think back to the examples I gave in the other thread. > 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. Having it customizable would be ideal, but I'm not sure it's possible to have uniquify-style completions without excluding some valid usage scenarios, like mentioned above.