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

LSP does not auto-complete child nodes attributes ($NodeName) #36473

Closed
rafaeldelboni opened this issue Feb 23, 2020 · 10 comments · Fixed by #36521
Closed

LSP does not auto-complete child nodes attributes ($NodeName) #36473

rafaeldelboni opened this issue Feb 23, 2020 · 10 comments · Fixed by #36521

Comments

@rafaeldelboni
Copy link
Contributor

Godot version:
3.2 branch with this #35864

OS/device including version:
Arch Linux 5.5.4

Issue description:
LSP does not auto-complete child nodes attributes.

Steps to reproduce:
Create a node (call it player) and add a child node, let's say an AnimatedSprite, them create a script for the main node (player).
Start typing $AnimatedSprite is not found in the autocomplete list and typing a . and fl doesn't bring the options flip_h and flip_v.

Minimal reproduction project:
coin-dash.zip

@akien-mga
Copy link
Member

CC @Geequlim

@YuriSizov
Copy link
Contributor

Note that even in the built-in editor your node references autocomplete only if the corresponding scene is currently active. So this probably cannot work via LSP at all, I would assume?

@rafaeldelboni
Copy link
Contributor Author

@pycbouh I just tested in the built-in editor what you mentioned and is true, but this is a expected behavior or a bug? Since the attributes of nodes are "static", that shouldn't be the case to have the dependency of an active node to make the autocompletion works.

@YuriSizov
Copy link
Contributor

I think the problem is in the fact that a script does not necessarily know what node it is attached too. And, actually, can be attached to multiple nodes with different child trees. So the autocomplete function does not make any assumptions and just operates on the active scene.

I think it is "intended" as in "it was the most straightforward solution at a time of implementation". But I believe it should be improved and work regardless.

@rafaeldelboni
Copy link
Contributor Author

rafaeldelboni commented Feb 23, 2020

I can imagine a fallback logic when it doesn't find an active scene it could at least return the default props and methods for the child node type

@YuriSizov
Copy link
Contributor

@rafaeldelboni It does not know, though, by the name of your node alone what kind of node it is. It is true, that the node can be named exactly as its type, by default or otherwise, but there is no guarantee, that a node named "AnimatedSprite" is in fact an AnimatedSprite and not some other type.

@rafaeldelboni
Copy link
Contributor Author

Yeah you right, sorry I didn't thought about renaming the child nodes, your statement makes all the cense.

@rafaeldelboni
Copy link
Contributor Author

Ok I'm brainstorming here, sorry if this isn't the right place, but to attach this script to another node the new node needs at least to have the same structure (same child node names and types) as the other node the script is attached to right? Couldn't we check if there isn't a active scene for that script if is the case get the first one where this script is attached to and set it as active?

@rafaeldelboni
Copy link
Contributor Author

The same is happening when you try get_viewport().get_visible_rect().size the size autocomplete happens only on the built-in editor when a scene is active.

@Geequlim
Copy link
Contributor

The LSP server doesn't parse scene trees because we code in external text editor with LSP client so it is really often we open diffrent script files in the external editor (In godot editor the attached script is actived when we active the scene). When scripts is not attached to the opening scene in the godot editor the node pathes from would be wrong.

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