jrockway / eproject

file grouping ("project") extension for emacs
161 stars 41 forks source link

Consider the outermost currently open project as the project root #36

Open thomasf opened 11 years ago

thomasf commented 11 years ago

This is a feature suggestion.

Simple specs:

tjarvstrand commented 11 years ago

+1 to this but it really makes more sense to me to have it as the default.

tjarvstrand commented 11 years ago

Added a pull request in https://github.com/jrockway/eproject/pull/44, though it will consider all projects in eproject-project-project-types, not just the ones with open files.

thomasf commented 11 years ago

Your solution in #44 probably is close enough for me to close this issue as well if your pull request gets pulled.. Im trying it out in my work day right now.. I also agree with your "on by default" point but in the end that is highly dependent on taste and how you work with sub projects so leaving the default way untouched should mean less trouble for everyone.

jrockway commented 11 years ago

Sorry for the delay on commenting. I agree that this is an important issue and people's opinions vary. What do you think about this:

Default to preferring the innermost project. If a custom flag is set, then find the outer projects, and just ask the user which project to prefer for this session. Then always prefer that project for any files that contain that project in the directory root.

(I realized we don't need to check for project-ness every time a file is opened. We can probably just do "does the newly-opened file's path contain any other project root? If so, the file is part of that project.)

dgutov commented 11 years ago

(I realized we don't need to check for project-ness every time a file is opened. We can probably just do "does the newly-opened file's path contain any other project root? If so, the file is part of that project.)

You can miss an inner project this way, if a file in the outer project is opened first.

dgutov commented 11 years ago

+1 to this but it really makes more sense to me to have it as the default.

-1 on the default. It's different from the current behavior, and it's harder to optimize. Better to have the more performant approach as the default.

If a custom flag is set, then find the outer projects, and just ask the user which project to prefer for this session.

I'm likely not the target audience, but I believe that answering that question each time you launch Emacs and start working on the project in question will become tedious quickly.

tjarvstrand commented 11 years ago

-1 on the default. It's different from the current behavior, and it's harder to optimize. Better to have the more performant approach as the default.

I disagree. I can see the point about changing current behaviour, but the performance cost is negligible (at least in the case of just searching up the file tree for a project-file) and I firmly believe that the better default choice is the one that pleases more users.

IMHO, if project A is located inside project B, then in 99% of all cases that is because you consider the former project to be part of the latter. If doing independent development on A completely outside the scope of B, I can't think of a scenario where I wouldn't create a separate repo/directory for this.