Provide a service API

[basarat]

Particularly interested in getting told about file/folder renames.

Would make it easier for me to support folder / file move style refactoring for atom-typescript.

Would you guys be open to consider such a PR.

[thomasjo]

The tree view uses atom.project.onDidChangePaths to handle renames etc, so not really sure if it makes sense to expose a service just to wrap existing functionality. Are there any other particular scenarios the service would/could cover outside of renames, or is there perhaps some reason for not using the existing event?

[basarat]

atom.project.onDidChangePaths

Exactly what I needed. I just didn't know about it 🌹

[basarat]

Reopening as atom.project.onDidChangePaths is not designed to be triggered on tree view file renames (refs #437 (comment)).

Might investigate adding something along similar lines though.

[thomasjo]

The way this is done in the tree view right now, is that is recursively adds "change" listeners starting at the projects roots (where Project::onDidChangePaths comes into play). It uses it's own Directory and File implementations though, not really sure why they aren't extending the ones exposed by Atom.

I'm starting to see the usefulness of either a service API, or at least some emitted event.

[basarat]

at least some emitted event.

Basically needs to be emitted here : https://github.com/atom/tree-view/blob/master/lib/move-dialog.coffee#L35

[basarat]

Opinion needed before I PR:

1. a new global atom.treeview OR
2. tag this on the atom.project OR
3. something else

If its going to be on atom.project (i.e. 2.) then the design would become:

• onConfirm from move dialog will trigger atom.project.emitter.emit('did-rename-path') (calling it by this name because the command is 'tree-view:rename').
• Add a new function to atom/project here called onDidRenamePath.

[mnquintana]

I don't think a new global for Tree View makes sense since Tree View is a package and can be disabled.

[basarat]

@mnquintana cool. What about 2? or would you suggest something else.

[zephraph]

Would you guys be open to expanding the definition of this issue? I would really like to get the view of any file or directory that was added or changed. Beyond that, I'm sure it would be useful to know when files were moved or deleted as well.

We could have a few different methods in the service that could provide disposables for each of these situations.

Personally, I could also use a service method to get any file or directory views based on extension (or perhaps more generically based on some pattern).

In my case, I'm building a package for robotframework and I'd like to be able to add checkboxes next to files ending in .robot and any directories containing them. This will allow the user to select which tests they want to run directly from the tree view (to function similar to RIDE).

[ricardofbarros]

Is there any news regarding this?

[UziTech]

I created a pull request for this #1162

It is just providing access to the treeView instance, although I'm thinking it might be better to limit it a bit.