Re: make project--find-in-file generic, add interactive filename to project-find-file

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 01/28/2016 02:06 PM, Stephen Leake wrote:
>
>> That works nicely; new patch attached.
>
> Please install, with the following adjustments:
>
>> +(cl-defgeneric project--file-completion-table (_project _dirs)
>
> Let's call it project-file-completion-table (no double-dash). A
> private generic function is an oxymoron.

Ok.

> Should this table also include directories, BTW? That shouldn't make a
> difference in performance, and then we could add a project-dired
> command. Or just open Dired from project-find-file if the input is a
> directory (directories are files, too).

I have not thought about that at all. I never felt like I wanted to do
it. Part of the point of project-find-file is that it allows me to
_ignore_ the directory structure.

So no, I don't think we want to expand this table to include
directories.

A buffer that lists the project directories might be useful for some
things; again, I've never felt like I need it.

>> +  "Return a completion table for files in directories DIRS in PROJECT.
>> +If non-nil, DIRS is a list of absolute directories; it should be some
>> +subset of the project roots and external roots. If nil, the backend
>> +uses all the directories it knows about.
>
> Why should we allow DIRS to be nil, and ask all backends to deal with
> that? Nobody passes nil to it. Out default implementation doesn't
> handle nil there.

I'll delete that part.

>> +PROJECT is used to find the project ignores and other project meta-data."
>> +  )
>
> Why not put the default implementation here? There's no need for the
> separate cl-defmethod declaration.

I find it cleaner to have a separate cl-defgeneric, so the doc string is
clearly about the generic requirement, and not the default
implementation.

And it leaves the default implementation in the same place in the file,
so the git diff is smaller and more usefull.

Pushed.

--
-- Stephe