Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"open declaration" should open module in same project instead of module in other workspace project with the same name #65

Open
davidmichaelkarr opened this issue Jan 7, 2016 · 1 comment

Comments

@davidmichaelkarr
Copy link
Contributor

Let's say that I have two Yang projects in the workspace, projects "yang1" and "yang2". Project "yang2" has module "bar.yang", and both projects have a module named "baz.yang", with similar but slightly different specifications.

Module "bar.yang" in "yang2" imports module "baz". It also references a type defined in "baz" with a prefix.

While editing module "bar.yang", put the cursor on the type name reference from module "baz". Press F3 for "open declaration". It's a reasonable assumption that this will open "baz.yang" in "yang2". In my test case, it opens "baz.yang" in project "yang1".

This behavior is likely dependent on the order in which these modules are indexed. I don't know whether it will matter, but other project names with different ordering might produce different results.

@davidmichaelkarr
Copy link
Contributor Author

The solution in OpenDeclarationAction requires casting the "editorInput" to "FileEditorInput" and getting the project from that, and passing that to the search function. A byproduct of this change is that you could now set the current project to depend on another project, and it will look in that project in addition to the current project. This creates a new concern, in that perhaps it should prefer defs in the current project over defs in dependent projects. I haven't yet looked at the parsing process in these scenarios.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant