[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Making project-files the "canonical" generic, was: Re: [Emacs-diffs] mas

From: Dmitry Gutov
Subject: Making project-files the "canonical" generic, was: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el
Date: Sat, 12 Jan 2019 04:10:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

Stephen, 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, or in some other third-party code?

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?

On 27.12.2018 17:39, Stefan Monnier wrote:
Not sure what you mean by "keep them in sync".
Making sure to implement them in a compatible fashion.  My point is, it's
probably better to leave just one if the other can (almost?) always be
efficiently implemented in terms of it.
Right.  But I'm not sure which one should be the "canonical" one.
Currently, the "canonical" one is the completion-table, and the
files-list is defined based on it (while it's current definition only
handles flat completion, that could be improved).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]