Re: project.el semantics

[John Wiegley <jwiegley@gmail.com>]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> I meant "external to the project" instead of "outside the project", of
> course.

What is the difference between these two? To my ears, they mean exactly the
same thing.

> Do you really think "project-ancillary-roots" is better than
> "project-library-roots"?

Neither sounds good, actually.

I think we're too focused on "projects" having to do with code, where code
uses libraries. A "library-root" presumes things about the content of the
project which I suggest we don't need to presume.

The filesets idea was not meant to complicate the API, but to step back and
reassess the API we really want. I understand now why you chose "root" as a
suffix, and that much makes sense.

Here's where I'm coming from:

When I'm sitting at a buffer in Emacs, that buffer is usually related to
something. It could be just a buffer (like *scratch*) with no relation at all,
but that's pretty rare.

Typically, the only relationship it has is to a file. But it may have other
relationships:

  - To other buffers
  - To other files
  - To other directories
  - To other directories trees

The selection of these "other" things can be based on many, many different
criteria: same file type, same directory, same "project" in the version
control sense, same modification day, etc., etc.

Why confine ourselves to thinking about code projects that use libraries, when
we can imagine a larger picture, where the original idea is just a particular
set of choices?

I'd love to have a programmatic API for associating files and buffers, and a
set of commands able to take these associations into account. I'd use them for
lots of things that have nothing to do with source code. When I'm editing a
Markdown file, for example, I might have a preview buffer showing me a PNG of
the rendered result. These buffers are all related to my current "project",
and I'd like a way to "save all files in project", or "close all buffers in
project".

Projectile gives me some of that today, but it's very much tied to Git and
filesystem searching -- which are great default backends for this type of
functionality, mind you; they just shouldn't be the limit of our thinking.

This is one of the "IDE features" I mentioned several weeks ago, which is why
I want us to spend more time thinking about it. Why start out with a smaller
API that does a very focused thing, when we can imagine something much more
capable?

John