From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Thu, 17 Jan 2019 08:55:23 -0500 Message-ID: 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 X-Trace: blaine.gmane.org 1547733220 14670 195.159.176.226 (17 Jan 2019 13:53:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 13:53:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 17 14:53:36 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 1gk86x-0003k6-OB for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 14:53:35 +0100 Original-Received: from localhost ([127.0.0.1]:45061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk894-0003Mp-AV for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 08:55:46 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk88t-0003LV-0S for emacs-devel@gnu.org; Thu, 17 Jan 2019 08:55:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gk88s-00052Q-5B for emacs-devel@gnu.org; Thu, 17 Jan 2019 08:55:34 -0500 Original-Received: from [195.159.176.226] (port=40862 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gk88r-0004zo-U8 for emacs-devel@gnu.org; Thu, 17 Jan 2019 08:55:34 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gk86h-0003OE-UV for emacs-devel@gnu.org; Thu, 17 Jan 2019 14:53:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 44 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:fn0rpHyGvemxeihIrnK0/j47QLQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:232424 Archived-At: >> I can understand the motivation behind removing common prefixes, but the >> proper way to do that is to implement a completion style and/or table >> that does that, and make that style/table the default for projects. > How exactly would you propose to do that? His completion style relies on an advice to the completing-read code which re-adds the text that was stripped during the completion. Clearly, that won't work when used for completion-at-point. I actually think his approach is interesting and maybe we should think how our completion system could provide support for these kinds of "styles". >> The ada-mode completion style and table eliminates all directories from >> the visible completion string, except the minimum needed to make the >> string unique. I think this is a better solution to the problem; >> project.el should allow the user to choose their prefered solution, by >> choosing a completion style and table. > The user is not choosing a table. The project backend does, and in your case > it presents an entirely different look for file names from the other > backends, with no way for the user to change it. > I think that's bad. 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). 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. > 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 so it can be used for any (flat) completion table (I don't think it'll work well with completion-file-name-table). Stefan