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

Go to Definition opens a different copy of a file. #46

Closed
dvirsky opened this issue May 13, 2016 · 13 comments
Closed

Go to Definition opens a different copy of a file. #46

dvirsky opened this issue May 13, 2016 · 13 comments

Comments

@dvirsky
Copy link

dvirsky commented May 13, 2016

This happens on Linux with version 0.5.0 and vscode 1.0 and 1.1.0.

If I have a C file open, and it contains a function, and I click "go to definition" of that function, no matter from what open file (even from the same file) - this will cause the C file containing the function to be re-opened and appear twice in the active files list. The second file appears with the file's absolute path next to it.
This is confusing and causes clutter. I'm not sure if it's a bug in the extension or of vscode itself.

Attached - example of how it looks.
screenshot from 2016-05-12 18-49-33

@dbaeumer
Copy link
Member

dbaeumer commented Jun 1, 2016

@sridmad how does the file URI look like you are returning in this case. This should work and there should be no need for you to do anything special besides returning a propery file url. Something like file:///home/.... What wonders me is that the file path at the end is ///home which indicates that either we do something wrong in the language client or vscode extension host API or the provided file URI is incorrect.

I quickly tested this under Windows and it works. Need to setup Linux first to try there as well.

@sridmad
Copy link
Member

sridmad commented Jun 1, 2016

Let me take a look at the experience on Windows and also the paths we return

@dvirsky
Copy link
Author

dvirsky commented Jun 1, 2016

If you want me to help with debugging on Linux, let me know. BTW I've verified that it happens to other people as well.

@dbaeumer
Copy link
Member

dbaeumer commented Jun 1, 2016

@sridmad just to clarify: I tried a test bed under Windows, not the C++ extension.

@dvirsky
Copy link
Author

dvirsky commented Jun 6, 2016

FWIW it still happens on VSCode 1.2.0

@jgoshi
Copy link
Member

jgoshi commented Aug 23, 2016

Does this still happen with the latest stuff (VSCode 1.4, cpptools 0.8.1)?

@jgoshi
Copy link
Member

jgoshi commented Aug 23, 2016

I was able to repro this and the fix will appear in the next release of cpptools (version 0.9.0).

@jgoshi jgoshi closed this as completed Aug 23, 2016
@dvirsky
Copy link
Author

dvirsky commented Aug 28, 2016

Any ETA on 0.9.0? Besides this bug, the auto-completion suggestions are totally screwed up on the latest version. Is it at least possible to revert to 0.7?

@jgoshi
Copy link
Member

jgoshi commented Aug 29, 2016

Version 0.9.0 should be available within the next week or so. We did some work on auto-completion but there's still many improvements we are currently working on for future releases.

@dvirsky
Copy link
Author

dvirsky commented Aug 29, 2016

Cool. Right now it seems like the auto-complete defaults to all known symbols in a lot of trivial cases. I tried all configuration options to no avail.
Is there any way to downgrade to 0.7? it worked much much better in that sense.

@jgoshi
Copy link
Member

jgoshi commented Aug 29, 2016

Sorry I'm not aware of any way to downgrade.

@dvirsky
Copy link
Author

dvirsky commented Aug 31, 2016

@jgoshi oh well. Is there a way to cause the extension not to do completions at all? there's another extension that uses clang and does decent completion, but lacks all the other great features yours has. I wish I could use both.

@dvirsky
Copy link
Author

dvirsky commented Aug 31, 2016

maybe it's worth adding a configuration option to disable this.

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

No branches or pull requests

4 participants