From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Fri, 18 Jan 2019 05:19:18 +0300 Message-ID: <69076784-83cb-5cc7-be39-fea990b8535e@yandex.ru> References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> <4e729d1e-bb31-455f-fd44-e99ae5a6b9fa@yandex.ru> <86zhs5r9lr.fsf_-_@stephe-leake.org> <08de4d90-d678-0524-9356-f9a3515bf0c4@yandex.ru> <86a7k2rabi.fsf@stephe-leake.org> <86sgxso27d.fsf@stephe-leake.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1547777892 13977 195.159.176.226 (18 Jan 2019 02:18:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Jan 2019 02:18:12 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 18 03:18:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkJjT-0003U2-AL for ged-emacs-devel@m.gmane.org; Fri, 18 Jan 2019 03:18:07 +0100 Original-Received: from localhost ([127.0.0.1]:58829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkJla-0002bM-GZ for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 21:20:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkJkw-0002b1-WE for emacs-devel@gnu.org; Thu, 17 Jan 2019 21:19:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkJku-0004ft-Oe for emacs-devel@gnu.org; Thu, 17 Jan 2019 21:19:38 -0500 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:41047) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkJkk-0004Xv-9z for emacs-devel@gnu.org; Thu, 17 Jan 2019 21:19:31 -0500 Original-Received: by mail-lj1-x234.google.com with SMTP id k15-v6so10308186ljc.8 for ; Thu, 17 Jan 2019 18:19:22 -0800 (PST) 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=Vh8x/wwOOfZ/PpANOm1frS5jEQ1i2kcPcNVKr/TyDq4=; b=L0JTrhv3nuisziRRfFY461/6gUMaZukyNOETitk2tncwWyCvdSJWGGSZrywjA3oiVU HEqzbKny2Bf8qoVuwi5yznKNLCyg3r4MyQr3UcIdw4j4PT9h/eRIqBN5rAC/nnDCDEaa 8hi/xSohKggPvUN0VoEEV8oL3yNqXfqjv2Qcwu+2YtmabxQcWpz/YH3/sPH80nmW692D jL6C5SONB15XXjn4mDKEhhX1OQjJafYK17D5pdBxD5xkxRWQutXQSrtKjuMfvZuztgHV Vkx5hntA4TvmGog6aUQFcCJ+OdECStGwqXh+IGFzV8+oOaNTAkH9yT8D5V2IiYT9kYJa sCQQ== 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=Vh8x/wwOOfZ/PpANOm1frS5jEQ1i2kcPcNVKr/TyDq4=; b=Cv4g27audnWKc3ksPQn2hCt+tmwA7vKXvxUBJTHVsJHLIxkDV83Glt9rYl6BayI+RL 5kzwzaVAjztlHgW+4AbzfRj4sJuUPcopEV/2eBbxZm/sOTEV3f/IIREKU81PXpr7oMtb kHu7WcBlrpJx69o8e+EbRig3I1y7p9lmgbRdG9OcT1zCMUWVpuVWZn28LDcT+CRsj6C5 N/20NFwTDwcIPDpGTnAHMFVRdaW3VNSX3XvfapnSCrmiAQ41bOw8RTopZuWp7W4JNDnK YbrtlAdoR2jGgnPSgMWh815VnKZoJduxCBEyuL1aREyZM9yFkaY8iw9co5I3lCCMxYi9 DZBQ== X-Gm-Message-State: AJcUukffdIZnYTPBV351lRRoqBYE9JCx8fDdCaYaMbFIk8svHJbARWSO ygOTNhJn4IfOK3vOJ17c9v9Dxwl7 X-Google-Smtp-Source: ALg8bN5YVIi9/LOjnQ1yx7kmbizKrr2UtTF71q4ID04Bj/MRtYJKXhvczjrTliHmzeyakpbicf7d3w== X-Received: by 2002:a2e:4503:: with SMTP id s3-v6mr11260642lja.44.1547777960683; Thu, 17 Jan 2019 18:19:20 -0800 (PST) Original-Received: from [192.168.0.108] ([79.175.3.65]) by smtp.googlemail.com with ESMTPSA id 15-v6sm566752lje.18.2019.01.17.18.19.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jan 2019 18:19:19 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:232449 Archived-At: On 17.01.2019 16:55, Stefan Monnier wrote: > I actually think his approach is interesting and maybe we should think > how our completion system could provide support for these kinds of > "styles". Sure, but in some different way. Having some wrapper middleware could work, but I'm afraid it might stumble against the same problem the current project-find-file does: completion tables are too flexible. So it's hard to make a universal wrapper which would modify them all the same. > Indeed, an important design constraint I followed for the completion > styles is that the user should be able to choose the style (hence the > indirection through completion-category-overrides). Yup. > I think part of Stephen's argument is that the same comment applies to > the new completion behavior of M-x project-find-file you installed > in 8f9d93f3054. Like already said, nobody's stopping you or him or anyone else from adding a new command that shows file names in a different way (e.g. uniquified/abbreviated). As long as both project-find-file and the new command work the same across all project backends, I'm happy. And again, it doesn't have to be a separate command, the behavior could be customizable and dispatched inside the one command's implementation. We can't do that if the said behavior already lives inside the completion table, however. >> Far be it from me to criticize the exact "uniquified" look for the entries, >> but I don't think it's a good place to produce them. If it's not possible to >> implement them via a completion style or something like that, that would >> apply to all project backends and their completion tables if the user so >> chooses, maybe it should just be a different command. > > I'm not sure if it currently can work for any project backend, but its > design definitely aims for it to be backend-agnostic By "it", do you mean uniquify-files.el? > so it can be used > for any (flat) completion table (I don't think it'll work well with > completion-file-name-table). Would you agree that a "flat completion table" is basically always a list of files?