Re: cl-defgeneric vs random funcall in project.el

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 07/31/2015 05:36 PM, Stephen Leake wrote:
>
>> It would be wrong to add the entire directory tree that contains .git;
>> the user is using emacs 25, so they don't want to see the emacs 24.3
>> files. Obviously, there is a separate case where they do want to see
>> those files; that's a different project configuration.
>
> It's really impractical, IMO, to have different project configurations
> for different use cases. 

Not for me.

> A fancy project backend could have those,
> though, and the user would be able to switch to their heart's content.

Switching is just selecting a different project file.

> We are not discussing a fancy project backend here, though.

I am.

I want to ensure the core project API does not prevent me from writing
the backends I want. It must also provide sufficient reason for me to
use it; the fewer features I need that it has, the less reason I have to
use it.

> To be clear, here are the two main "separate cases": navigating to all
> definitions, and aliases for different Emacs versions; navigating to
> all references to a given function, again, in code for different Emacs
> versions (to be able to rename them, for instance). As a project
> maintainer, I want all of those visible and on the tips of my fingers,
> because I need to maintain all code. Not just the code currently
> loaded in my Emacs.

Yes, that is a valid use case.

And if the default project behavior, without any user add-search-path or
add-ignores, gives you that, that's fine.

>> We could provide:
>>
>> (defun project-create (root)
>> ...
>> `project-root-alist' associates root directories with project objects;
>> ...
>> (defun project-add-search-path (project path)
>> ...
>> (defun project-add-search-ignore (project ignores)
>
> Sorry, this is too much a centralized, manual configuration for my
> taste. 

Is it a problem if they are present for others to use?

We are discussing a core Emacs feature that will be used by many people;
it cannot cater to only your personal opinions.

> What you've described here, could be a separate project backend. One
> you're welcome to write.

Any backend that supports project files will need functions like these;
project files are precisely centralized manual configuration.

So they belong in the root class.

If I end up writing everything in the backend, there's no point in using
the "unified project interface".

> As a real
> example, I have a few small Elisp one-file packages, the Git checkouts
> of which are never in load-path.

Ok, I agree it would be good if the default project implementation
supports this case.


-- 
-- Stephe