* Don’t tokenize
* Don’t build metadata to support folds and soft wraps
Remaining issues:
* Max line length is hard coded
* Foldable indicators should be disabled
* Folding via API should be disallowed
A `Project` will always have a `DefaultDirectoryProvider` that
will be used if there are no other `DirectoryProvider` objects
that can produce a `Directory` for a path.
I tested this using my test `HgRepositoryProvider`. Now when I run the following from the
command line:
atom <path-to-directory-with-hg-repository>
And then run the following in the console:
atom.project.getRepositories()
I get an array with an `HgRepository` in it. Previously, I got an empty array because the
`Project`'s paths were set before my `HgRepositoryProvider` was registered.
I tested this by creating a dummy implementation of an `HgRepositoryProvider`
(with the optional `createRepositorySync()` method implemented) and an `HgRepository`
in an Atom package with the following stanza in the `package.json`:
```
"providedServices": {
"atom.repository-provider": {
"versions": {
"0.1.0": "createHgRepositoryProvider"
}
}
},
```
I opened a path with an Hg repository from the command line using Atom.
I verified that `atom.project.repositoryProviders` contains both a
`GitRepositoryProvider` and an `HgRepositoryProvider`.
I also verified that running the following printed out an `HgRepository`:
```
var Directory = require('pathwatcher').Directory;
atom.project.repositoryForDirectory(
new Directory(atom.project.getPath(), /* symlink */ false)).then(
function(repo) { console.log('repo: %o', repo); });
```
One thing that stands out to me about the current API for the
atom.repository-provider service is that the function used to create
a `RepositoryProvider` does not receive any arguments. If the creation
of the `GitRepositoryProvider` were done via the service, this would
be a problem because it needs a reference to `atom.project`, which is
not defined when it is created. (We work around this because it is
created in `Project`'s constructor, so it can pass `this` to
`new GitRepositoryProvider()`.)
We would have to create a `RepositoryProviderFactory` or something if
we wanted to specify arguments when creating a `RepositoryProvider`,
in general. Maybe that's too crazy / not an issue, in practice.
Though note that `GitRepository` cannot access `atom.project` lazily
because it uses it in its constructor to do the following:
```
if @project?
@subscriptions.add @project.eachBuffer (buffer) => @subscribeToBuffer(buffer)
```
So long as we can guarantee that `atom.project` is defined before the
other providers are initialized, I think we should be OK.
Follow-up work:
* Replace the use of `RepositoryProvider.createRepositorySync()` with
`RepositoryProvider.repositoryForDirectory()` in `Project.setPaths()`.
* Replace all uses of `Project.getRepositories()` with
`Project.repositoryForDirectory()` in packages that are bundled with Atom
by default.
* Implement `Directory.exists()` and/or `Directory.existsSync()` and update
`git-repositor-provider.coffee`, as appropriate.
* Eliminate `GitRepositoryProvider.repositoryForDirectory()`'s use of
synchronous methods.
* Somewhat orthogonal to this diff, but the following fields need to be
removed from `Project` because they enforce the idea of a single root:
`path`, `rootDirectory`, and `repo`. This has implications around the
existing use of `@rootDirectory?.off()` and `@destroyRepo()`.
