Go to definition behavior change request

Currently, using "Go to definition" with the MS Language Server will jump you to your import statement, likely at the top of your file, rather than jumping you into the class. I understand from a separate issue #850 that this is the intended behavior. Below is a gif of it.

In my view, "Go to definition" means that you go to where the class is defined. Taking me to the top of the file and showing me the import statement doesn't seem nearly as widely used or necessary as jumping directly to where the class is implemented.

Imagine you were in the full version of Visual Studio coding in C#, "Go to definition" would take you to the definition of your class.

If we insist that we need a separate feature to navigate us to the import statement, it seems that we should make a separate button and keyboard shortcut called "Go to declaration", and leave the "Go to definition" function to be the same behavior as Jedi.

The LSP spec has both definition and declaration as of 3.14.0; perhaps we should implement both and have definition recurse until it hits the true assignment.

#494

Jake Bailey (@jakebailey)

this should be a bug, not the intended behaviour. Going by the name Go to definition should take to definition, not to the import.

And even if it is intended behaviour (then it should be called something else, IMO), it is not consistent, like in below situations

constants.py

def a_simple_function():
    pass

run.py

from vscode_test import constants
from vscode_test.constants import a_simple_function
constants.a_simple_function()
a_simple_function()

Goto definition of constants.a_simple_function() takes to constants.py directly where as a_simple_function takes to import and then to definition

Jake Bailey (@jakebailey) Mikhail Arkhipov (@MikhailArkhipov)

Sure. 'Bug' is when something intended to work certain way, but it doesn't. If something is implemented certain way intentionally, with the appropriate test, and it works as designed, it is not technically a bug. Sure, it could be a wrong choice though :-)

Mikhail Arkhipov (@MikhailArkhipov)

Mikhail Arkhipov (@MikhailArkhipov) I don't know about language server implementation, but you also may to look at below issues together as it appears to me to originate from same design (if I am wrong, excuse me for making false noise)

All references are not listed when using ms language server #1174, here not all references are identified (directly imported symbols are only considered for reference, it is not considered as referenced if used as <module>.<symbol>. Sounds like same inconsistency I spoke about in my earlier comment)
import statements are listed as part of reference, though you can argue about this, jedi and other language server implementations (for other languages like java etc.,) doesn't list imports as reference. IMO, imports are not references.

Navigation Menu

Repository navigation

Go to definition behavior change request #1138

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go to definition behavior change request #1138

Description

Activity

jakebailey commented on May 29, 2019

MikhailArkhipov commented on May 29, 2019

jahan01 commented on Jun 5, 2019

MikhailArkhipov commented on Jun 5, 2019

jahan01 commented on Jun 8, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions