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: Thu, 17 Jan 2019 05:21:39 +0300 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1547691647 8429 195.159.176.226 (17 Jan 2019 02:20:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 02:20:47 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 To: Stephen Leake , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 17 03:20:42 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 1gjxIQ-00024J-7t for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 03:20:42 +0100 Original-Received: from localhost ([127.0.0.1]:48160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjxKX-00042j-6k for ged-emacs-devel@m.gmane.org; Wed, 16 Jan 2019 21:22:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjxJo-00042c-Kj for emacs-devel@gnu.org; Wed, 16 Jan 2019 21:22:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjxJl-0003d3-06 for emacs-devel@gnu.org; Wed, 16 Jan 2019 21:22:06 -0500 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:38006) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gjxJi-0001Zn-0o for emacs-devel@gnu.org; Wed, 16 Jan 2019 21:22:03 -0500 Original-Received: by mail-lj1-x22b.google.com with SMTP id c19-v6so7217656lja.5 for ; Wed, 16 Jan 2019 18:21:44 -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=4idqLp86Ne7GUdAbd9/zWglK5wTJx8oJPc8SJUm67xg=; b=hSUi5ZZqWAyDDjm9I+8hbDQ3NMMrRxhUOxIl7ESEd7PAMMiBxWoDt+BF5hgXC0HrD9 kCztWEq29I+P0L5miZ6D7mBpNr0Y7q+WJGguvNUGJEiMCmvtBZw8+H8MmamrJ+3tlIQS clmcNLlKEnTHcF7ua8D+ktW54hhmpr11IQ0vu4aF7FNxcaUz3yIhrzrVijWHl5ATAooA B8ecmzGY3oX9f9+u1SxIlVSTLdJTvJZFhu87kMVBbe7dNxGXfIl6705/oFwBealjDwch Co5S+02yPqJ67xU0rF6EHn/Ju3ZFVqT9KiacegHw4bHLZVmNoobi2V6czqDocJLZpfpd j7zA== 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=4idqLp86Ne7GUdAbd9/zWglK5wTJx8oJPc8SJUm67xg=; b=a7goVxXiP+gM3Y2cbfMwRO9Q2NU9KU+jQjH58TyATwMzXMbK+OuN4yJlZT0rsNiR2a qSmSzMLSh4bx/pzQVrUD0NHZaxgEP06F+R5VYXnzdS3omDG2EUIm1Vs2b+u7nh80dM7J pOnMYB+tV5H+sr1z9OjXGaun9JOJsKzWPqpUKeY6vauhScegzGielSPhrheHNKCBtzvc o0bUH1v4tiBXDhWeuDbE581YjS5U687qyIe8eQz8RTemh9UiNeIFhfF5K2w9w0cw6o6i PbZsSr7AIPWxz5E7DYW4vEF5p/1WOrPRjHuhqqZLlMSfjHIXoQI+YOd4Kc8gLtHtNCGE wtHw== X-Gm-Message-State: AJcUukfslz6NWcdeRduo5PUw23+saeaWmK3XvA40aPqnYxUaqId1ulVe cGoWR9SG0RFQdE1RMrKk0Y6cZLIB X-Google-Smtp-Source: ALg8bN5balM0SlNYgFWfokv/x6G2dID4CPyIinLpYAzWETFY0Yei1goyDK3kK6KESYBkSA/jIVB4aw== X-Received: by 2002:a2e:3803:: with SMTP id f3-v6mr4069907lja.169.1547691702122; Wed, 16 Jan 2019 18:21:42 -0800 (PST) Original-Received: from [192.168.0.108] ([79.175.3.65]) by smtp.googlemail.com with ESMTPSA id m21sm26007lfl.97.2019.01.16.18.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 18:21:41 -0800 (PST) In-Reply-To: <86sgxso27d.fsf@stephe-leake.org> 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::22b 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:232413 Archived-At: Hi Stephen, On 16.01.2019 22:02, Stephen Leake wrote: > Commit 8f9d93f3054 (Dmitry Gutov 2018-12-29 415) breaks my ada-mode > completion table. I'm sorry to hear that, but: > That commit modifies the completion table by first calling the actual > completion table to get all the file names, then removing any common > prefix directory, then calling completing read with that file list. Yup. It solved a valid user complaint, with a solution proposed by Stefan. > This violates assumptions made within the ada-mode completion table, and > breaks the expected completion style - it requires typing the remaining > directory names first; the ada-mode completion table allows completing > on the base name only. TBH, I kind of struggling to understand how the previous version worked for you. But I guess when a completion table comes with a strongly coupled completion style, it's kind of possible. > 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? I don't see a way. Styles are an entirely different thing (they don't modify how completion strings are presented), and as for a table... for one thing, if a table removes a common parent directory from the strings, how would it pass that information to the command that's going to use it? To expand the file name later on. > 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. Namely, that e.g. M-x project-find-file can look drastically different for the same user when using different project backends. 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. E.g. named project-uniquify-find-file which would modify the completion table returned by the project (or, more trivially, the list of files). Whereas the completion tables should contain more or less the same kind of entries. IOW, to me this looks like an argument *against* having project-file-completion-table be a generic. The project backend should produce *data*, not formatting, in the same uniform format, for all backends. The more differences there are, the harder it's going to be to consume.