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: Sat, 12 Jan 2019 10:53:20 -0800 Message-ID: <86zhs5r9lr.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1547319104 24982 195.159.176.226 (12 Jan 2019 18:51:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2019 18:51:44 +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 Sat Jan 12 19:51:40 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 1giONf-0006Lz-Sg for ged-emacs-devel@m.gmane.org; Sat, 12 Jan 2019 19:51:39 +0100 Original-Received: from localhost ([127.0.0.1]:60508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giOPm-0001Ms-PU for ged-emacs-devel@m.gmane.org; Sat, 12 Jan 2019 13:53:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giOPg-0001MT-L3 for emacs-devel@gnu.org; Sat, 12 Jan 2019 13:53:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1giOPb-0004VO-M6 for emacs-devel@gnu.org; Sat, 12 Jan 2019 13:53:44 -0500 Original-Received: from smtp65.ord1d.emailsrvr.com ([184.106.54.65]:45229) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1giOPb-0004GP-Ey for emacs-devel@gnu.org; Sat, 12 Jan 2019 13:53:39 -0500 Original-Received: from smtp17.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 89D4820101 for ; Sat, 12 Jan 2019 13:53:21 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp17.relay.ord1d.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 3F8A9200E2 for ; Sat, 12 Jan 2019 13:53:21 -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); Sat, 12 Jan 2019 13:53:21 -0500 In-Reply-To: <4e729d1e-bb31-455f-fd44-e99ae5a6b9fa@yandex.ru> (Dmitry Gutov's message of "Sat, 12 Jan 2019 04:10:57 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.106.54.65 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:232323 Archived-At: Dmitry Gutov writes: > Stephen, hi! Hi. > Since it was your initiative that eventually brought us > project-find-file and project-file-completion-table, I'd like to ask: > > 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. > 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. I don't have a use-case for project-files, so I'd rather keep the status quo. I don't understand the comment about the default implementation of project-files only working if the completion table is "flat". Typically I use "flat" to mean "no recursive directories" when describing a path (= list of directories). I don't know what "flat" means for a completion table; what would a non-flat table be? Hmm. Maybe a "non-flat" file completion table means "return files in a directory only if the directory is completely in the string to be completed"? Do we have any examples of that? find-file works that way, but it's not a completion table. 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. 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. It would make sense to make the DIRS arg optional in project-file-completion-table, as it is in project-files. The docstring on project-files should state whether the file-names are absolute, or relative to one of DIRS, or just the basename. project-file-completion-table should state the same. Although perhaps "filename completion table" implies "absolute file names"? -- -- Stephe