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: Making project-files the "canonical" generic Date: Thu, 17 Jan 2019 06:04:57 +0300 Message-ID: <97148725-3ddf-ef4a-34cc-7e3c734a2e8f@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> 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 1547694259 10571 195.159.176.226 (17 Jan 2019 03:04:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 03:04:19 +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 04:04:15 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 1gjxyY-0002cf-Mo for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 04:04:14 +0100 Original-Received: from localhost ([127.0.0.1]:58360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjy0f-0001wZ-Rh for ged-emacs-devel@m.gmane.org; Wed, 16 Jan 2019 22:06:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjxzM-0001uA-1T for emacs-devel@gnu.org; Wed, 16 Jan 2019 22:05:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjxzK-0005wQ-Ts for emacs-devel@gnu.org; Wed, 16 Jan 2019 22:05:03 -0500 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:40862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gjxzK-0005p3-Kv for emacs-devel@gnu.org; Wed, 16 Jan 2019 22:05:02 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id v5so6589967lfe.7 for ; Wed, 16 Jan 2019 19:05:01 -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=yk1A4Rexo7/bUcKYogfrjjRi8zWZzRhJtHZMDsVleMI=; b=BC07zQsJ0+UgXhx/QmXE8eA5KqA5TNAjR+2/rfM1zRMPbLIfoHWGDhagrdmS1Upyun /vlfA68VTWuVSvij6CyTAEvDVDfsyNeIiAw7kl3QTXH7b/DEfg7aMY+dEimbgKsqc4Z3 G3vTWdZKJziU4nacjQ/i7i28/UMl+ewR7J6APguZFk0H69dKezwSFsFDms/Gvs/t4/nI svMTVkC8dMXhfG3o2MP449HxVgb2TExWWDn1F6f8E6n3qg+1GkTRbDcrw7vqCTCUILSJ F0UMh4wt2q8hgMXm9+G+LOsZ3EUO8s+DxKzdsQOLIPrYWhD9BLDH9Q4yBkq4y2p2F1c+ No0A== 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=yk1A4Rexo7/bUcKYogfrjjRi8zWZzRhJtHZMDsVleMI=; b=fExlU4zdTvbp4x0J8vjY4VwV3udgmWa5p1uzzbSUjTyHNV9cnVq9K4OjrLhtXpMF7N sJNB3o3aYlfEJGubv3xYmV03pLSxAxcXIpbvCKdGscm973bzjA4hClJmcfg5wrQFr1tg /txDaHksVSnBlJrd6hzPdMy+VbVmkuA9u2CUVdLaQQ+PU9Mt2oKkm/rKyq+PEHV2mXgv R1bwViNfwumyBp8nGNqOaETNE3VOlRL+6ZU4ZQ7QXPe0NfEJfi+de5GuKkSQzfBU6UfI sONTo7mS820m9PVBsdWxvvCHPyJxvG5kMtDH57MeT+MxjTVBDNgrE6Kg/seTiTE0YEhQ Y/5g== X-Gm-Message-State: AJcUukcLGmVpkwOcfAFSjyeVNyIYB3BnlduCNaFuB8BHzI1g/oBF1+h5 UFYKYmuMsoEhfV/vS1A4+vHncna/ X-Google-Smtp-Source: ALg8bN7W2ZO6I4Ldkwq+UAasYqCTZ22Gc2z3rBUJEAtIwrbPgOl9l4sglUPDn8k3U93lnKw2X4yWeg== X-Received: by 2002:a19:4bc9:: with SMTP id y192mr8905796lfa.49.1547694299418; Wed, 16 Jan 2019 19:04:59 -0800 (PST) Original-Received: from [192.168.0.108] ([79.175.3.65]) by smtp.googlemail.com with ESMTPSA id l63sm41430lfl.76.2019.01.16.19.04.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 19:04:58 -0800 (PST) In-Reply-To: <86a7k2rabi.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::136 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:232416 Archived-At: On 15.01.2019 04:14, Stephen Leake wrote: >> What is your use for completion table? I mean, the ability to provide >> your implementation. The default implementation should already work if >> project-roots and project-ignores return the correct values. > > In my case, they don't; as I have said elsewhere, the Ada compiler tools > require flat paths, so the Ada project code doesn't use project-roots, > project-ignores. I have code that converts between the two, but calling > that for every use of project-files would be inefficient. Why is that code so inefficient? Can't you get by with a limited list of ignores? I don't see how it can work otherwise. project-files *cannot* describe different information than what project-roots combined with project-ignores do. Any API consumer should be allowed to use any of those function, not just project-files or project-file-completion-table. Does the current implementation of project-find-regexp even work for you (it doesn't use the completion table)? And if so, how? > Providing a more flexible definition of project-path would fix that > problem. We have discussed this before. How would this work? Say, we have project-find-regexp which uses project-roots and project-ignores to build its command. How would it work with a "more flexible definition"? >> The only big reason to do that that I know of, is to use a cached list >> of files (or somehow fetch it quickly another way, without 'find'). >> But project-files is just as suitable for that. > > I could override project-files to return the correct list. Yes. I think I'd rather you did that and stopped there (aside from the project-roots/project-ignores problem). > The completion table style I use does uniquification by appending enough > parent directories to make the file names unique (same as > uniquify-buffer-name-style post-forward-angle-brackets). I might be able > to make that work with the list returned by project-files, but currently > some of the work is done in the completion table code itself, as it is > traversing the directory path. When I wrote it, I tried but did not > succeed in keeping all the completion-style-dependent code out of the > table. Maybe things have changed. I have commented on this in another email, and I understand how you reached that solution. And I don't like it, sorry. Doing all this using a completion style seems impossible, but you could implement the uniquification inside the (new) command, not inside the completion table. Then we'll have two commands for the same purpose, project-find-file and project-????-find-file. After, we could also try to combine them and make the behavior depend on the user preference. The completion table seems like the wrong way to do it, though. > The completion table is also lazy, in the sense that typing characters > in the completion buffer interrupts computation of the table, and it is > later resumed properly. I'm not sure "lazy" is the right term for this; > perhaps "interruptible"? I'm not clear if that mechanism would work thru > project-files. Err, I'm not sure how this works, but I think a project-files implementation could be "interruptible" as well. >> project-files is now used for project-find-file, and will be used for >> project-find-regexp as well. > > ? not in master as of 492ab1136860ef41c33a5e35a85fb721693f892b, fetched > today. Huh, you are right, sorry. It will be used for the default completion table, though. And I have plans for it to be used in project-find-regexp as well. >>> Do we have any examples of that? find-file works >>> that way, but it's not a completion table. >> >> ecomplete-completion-table is the one example that I found quickly, >> but there are probably more. > > ok, so there are real examples that require project-files and > project-file-completion-table to be independent of each other. I don't follow. The fact that some completion tables are kind of tricky doesn't mean we need to allow them here. We should find some specific use to them for our particular purpose. In any case, the comments that mention the "flat" bit are about how difficult those table make it for the commands that try to use them. Which is not an encouragement for having them supported. > And the user interface experience for completion tables is not fully > determined by completion-styles-alist, so my uniquifying completion > table above is not really an outlier. Having UI depend on a backend is not really a great idea, IMO. > But defining a non-flat table on top of project-files is not possible, > or at least very inefficient (you'd have to throw away all the nested > directory content). Could you elaborate on that? What have you tried, and how did it it fail to work? > Low level facilities like project.el should enable _all_ possible use > cases, not rule out some in the name of simplicity. All _feasible_ use cases. The said facility should itself remain usable and discourage buggy code.