From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Making project-files the "canonical" generic Date: Mon, 14 Jan 2019 17:14:41 -0800 Message-ID: <86a7k2rabi.fsf@stephe-leake.org> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1547514768 6934 195.159.176.226 (15 Jan 2019 01:12:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2019 01:12:48 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 15 02:12:44 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 1gjDHY-0001dj-69 for ged-emacs-devel@m.gmane.org; Tue, 15 Jan 2019 02:12:44 +0100 Original-Received: from localhost ([127.0.0.1]:40085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjDJe-0003sv-Rk for ged-emacs-devel@m.gmane.org; Mon, 14 Jan 2019 20:14:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjDJX-0003se-Vv for emacs-devel@gnu.org; Mon, 14 Jan 2019 20:14:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjDJW-00024W-24 for emacs-devel@gnu.org; Mon, 14 Jan 2019 20:14:47 -0500 Original-Received: from smtp73.iad3b.emailsrvr.com ([146.20.161.73]:43233) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gjDJV-00023N-UP for emacs-devel@gnu.org; Mon, 14 Jan 2019 20:14:46 -0500 Original-Received: from smtp18.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id CBDBDE03D4 for ; Mon, 14 Jan 2019 20:14:43 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp18.relay.iad3b.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 7B46BE03D0 for ; Mon, 14 Jan 2019 20:14:43 -0500 (EST) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 ([UNAVAILABLE]. [76.77.182.20]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Mon, 14 Jan 2019 20:14:43 -0500 In-Reply-To: <08de4d90-d678-0524-9356-f9a3515bf0c4@yandex.ru> (Dmitry Gutov's message of "Sun, 13 Jan 2019 03:54:32 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 146.20.161.73 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:232355 Archived-At: Dmitry Gutov writes: > On 12.01.2019 21:53, Stephen Leake wrote: > >>> Did you end up ever using it and/or integrating it with ada-mode, >> >> Yes, but not yet in the ELPA version; I had been maintaining Emacs 24 >> compatibility there. That's now dropped, so I can use Emacs 25 functions >> in future ada-mode releases. > > Very good. If you don't mind sharing a link to the development repo, > that would be great. My ada-mode project stuff is not in a publicly accessible repo at the moment. I guess it's time to fix that. >>> If so, do you see any particular benefits in keeping >>> project-file-completion-table a generic function instead of >>> reimplementing it on top of the (somewhat) newly added project-files >>> generic? >> >> It seems to me a completion table is more useful than a simple file >> list; what is the use case for project-files? I've been vaguely >> following the multifile.el discussion, but I don't remember seeing this. > > 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. Providing a more flexible definition of project-path would fix that problem. > 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. 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. 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. >> I don't have a use-case for project-files, so I'd rather keep the status >> quo. > > 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. > The thing about it is, project-files is easier to implement. So if we > don't have a particular reason for the backend author to provide their > own completion table entirely, we don't need to allow that. Yes, that makes sense. >> 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. 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. >> Requiring project-file-completion-table to be implemented on top of >> project-files prevents such non-flat completion tables, and also lazy >> completion tables (the ada-mode completion table is flat and lazy). >> Allowing user choice in completion tables is important. > > Could you clarify about laziness? See above. >> It seems to me that the default implementation of project-files should >> _not_ use project-file-completion-table, because it could easily be >> incorrect (it should use "find" directly). It is up to the project >> backend to ensure the two functions return consistent results. > > If possible, I'd like to avoid this completion, and only have one of > the other. After all, defining project-files on top of non-flat > completion tables is also possible (I'm told), if not particularly > easy. 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). So I don't think your goal is possible. Low level facilities like project.el should enable _all_ possible use cases, not rule out some in the name of simplicity. I have no objection to the default implemention of project-file-completion-table using project-files, but I don't think we should eliminate the generic function. Completion tables are a powerful feature of Emacs; we should not restrict their use with projects. -- -- Stephe