Â
Can we just agree that both are important and that it can be hard to
know beforehand which consideration should dominate?
I'd agree to that. But this is not "beforehand", there are really large projects
out there. Given a tree a tree structure such as a file system that can have
very many nodes, not having any means to take advantage of that structure
tree-ness (as project.el clearly doesn't: see the protocol of project-files and
the lack of sub-projects) is going to be a hard limitation. Monorepos
are really popular in many businesses and many of these are large and/or
getting larger.
It does makes sense to start simple, but ignoring scale rarely yields
the "desired behaviour" unless that behavior is waiting forever.
Example: Git "started simple" then grew sparse checkouts, shallow
clones, worktrees. You don't _have_ to use these features, but when you
do need them, it's very good that they are there.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4