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: Sun, 13 Jan 2019 03:54:32 +0300 Message-ID: <08de4d90-d678-0524-9356-f9a3515bf0c4@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> 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 1547340796 22860 195.159.176.226 (13 Jan 2019 00:53:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2019 00:53:16 +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 Sun Jan 13 01:53:12 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 1giU1V-0005lX-VZ for ged-emacs-devel@m.gmane.org; Sun, 13 Jan 2019 01:53:10 +0100 Original-Received: from localhost ([127.0.0.1]:47070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giU3c-0003yS-Cl for ged-emacs-devel@m.gmane.org; Sat, 12 Jan 2019 19:55:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giU2x-0003yC-80 for emacs-devel@gnu.org; Sat, 12 Jan 2019 19:54:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1giU2v-0000Tr-S1 for emacs-devel@gnu.org; Sat, 12 Jan 2019 19:54:39 -0500 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:39008) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1giU2v-0000Of-KB for emacs-devel@gnu.org; Sat, 12 Jan 2019 19:54:37 -0500 Original-Received: by mail-lj1-x233.google.com with SMTP id t9-v6so16049335ljh.6 for ; Sat, 12 Jan 2019 16:54:37 -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=DwPcJDU7NhBsNqvPdu+ZMhwp6DT893i8bgt9nUjILfo=; b=hvlaF0P6E1dsUPRkOv0IJmnC2iZyQsTA+w+2AsmrMZwRj8vSHkhAxqVWMbYeKHlTUG yWhIDTXmZPgK/LCVsRte4YpCrOdQ5sLUckECeb1Ax6zrbcPgDuDXvkJKWrSRmgOENkK+ 3FXTqQPsQxm6L6BpM7MCBU0MGR97Gf7hVVrPYgBOceF1x4xOTfHZzTL6D1s98+WnRrop //Z7w1nOnpA17hZ50iIkABCkQu6p6T7kqym3jCYal+SrFtE7QYDFhAKBFXG8XedOMLk9 M3M0LP4KJ1nino/IDZdmLDXnhJq7fD74D/4u7uX2htSH0vXNJnJTtai0ezD1sYYDf7c0 Y8Ag== 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=DwPcJDU7NhBsNqvPdu+ZMhwp6DT893i8bgt9nUjILfo=; b=J9Wo7qzaMwbYxB5GBpdCohlYH2aYVZaIJNcnELDYRe30IvBCkn8TkoKgs6y0LkZx4B JxFqz6sc5LcJtiBf7Qj00jK3CI3CskRVvd3O59rXQxJUW7Fmfgh5//KPZNNnu3Z+Uj+j qcBvrONyH0uxZNU+X2yJVocKvGlPYUN4yW5ntTvLet1fn6kzPaI/XgNSZ5bcV+Nywzrh bfJx68Ov5+D05zvYrUcTKhMjfRacydc6QfmIZg+IPE8HOS8o1R4HXYF3cvlB9qIXyUI4 SrpZpxcp0h25cF60wawJpQ9alpAVP3wUQr3O+J8zCJSRSIpMyKAe4JRsqBHrIPyXT599 T1lw== X-Gm-Message-State: AJcUukexJIZYEufbgCge4BiU/goKY8QxHyb3ZDLKZAXT8Xn95G2ZtHKS rPDu4nofmu/dg+CJNMb0mbPziy8gibo= X-Google-Smtp-Source: ALg8bN775uVWWHwJ0Vlyi1zOJA0MvoNUVWAQxKHAAFv0mDRA8S1D5SM46gIbWFAi06JynRTw26RHyg== X-Received: by 2002:a2e:9a84:: with SMTP id p4-v6mr11307064lji.73.1547340874142; Sat, 12 Jan 2019 16:54:34 -0800 (PST) Original-Received: from [192.168.0.108] ([79.175.3.69]) by smtp.googlemail.com with ESMTPSA id u12-v6sm16636849ljk.79.2019.01.12.16.54.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jan 2019 16:54:33 -0800 (PST) In-Reply-To: <86zhs5r9lr.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::233 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:232326 Archived-At: 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. >> 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. 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 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. 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. > 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? One where (all-completions "" table) would return not the full list of files, but e.g. include some directories without their contents directly. This can also work for completing-read if the table defines the "completion boundaries" logic. Those completion tables are fairly rare, naturally. > 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"? Pretty much, I guess. > 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. > 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? Having the list of files be returned from a method makes it "lazy" in a way already, since nobody has to fetch that list right away, they can just pass the project instance around (and call the method when necessary). > 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. > It would make sense to make the DIRS arg optional in > project-file-completion-table, as it is in project-files. *Shrug* I have no strong opinion on that. Except that project-file-completion-table doesn't have to be a generic, as far as I can see. > 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"? It probably does, but sure, we could use more expressive docstrings.