[Top][All Lists]

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

Re: project.el semantics

From: Dmitry Gutov
Subject: Re: project.el semantics
Date: Thu, 12 Nov 2015 04:21:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

On 11/12/2015 12:30 AM, John Wiegley wrote:

I meant "external to the project" instead of "outside the project", of

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

Not much. You didn't like one word, so I suggested another, to described the same thing.

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.

"Project libraries" paint a quick and simple picture. Which, I imagine, might be good for the first adopters of the API. I'm not going to hold on tight to it, but please keep in mind that simple is often good.

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.

In the current concept, the file, or the non-file-visiting buffer, is related to its default-directory. Then `project-current' takes that directory and determines the current project based on it, using project-find-functions.

project-find-functions being explicitly documented to depend only on the directory, but not on the contents of the current buffer, is a conscious decision: I don't want to see foo.el belong to one project, and README.md lying nearby in the same dir, to another, from the standpoint of this API. Do you disagree?

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

   - To other buffers

Other buffers also often have a default-directory set. So we can extend to them the relations that the original buffer has to their directories.

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

If you intend to keep the tree/no-tree distinction, please keep in mind my comment from the previous email.

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?

The API clients need to have an idea of the kinds of relations the API is dealing with. Otherwise, how would they ask the API anything?

For instance, what will project-find-regexp do? Will it query the API for a list of directories related to the current buffer/file/directory? What kind of directories? What kind of relations will it ask for?

Will we have anything like project-or-libraries-find-regexp? What will it change to?

What will the project-find-file command (current not implemented) look like?

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.

Why don't we save altering operations for the project backends? The API should work with existing backends as well (such as Projectile and EDE), and I'm not sure if they can support what you're describing.

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

That's a very simple example, which can be served by the current API just as well. Do you have any example that will show off the difference?

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

More capable is better than less, provided everything else is equal. But carefully considered limitations are also valuable, because they protect from misuse and other surprises by both backends and consumers.

I don't really see the end result from your description. Judging from just that message, you either want to remove project-library-roots and add a bunch of some other accessors instead, or remove all current cl-defgeneric declarations and declare each project to be a hash-table, using some sets of keys, both predefined (?) and not, and documented to have files and directories as values. The first option is simply vague, the second one, well, writing code for it would definitely be more error-prone: currently, if you mistype the name of a generic function, at least you get a warning.

You'll have to give more specifics either way.

reply via email to

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