Ctrl+Click to go to definition of method name defined as StringName &"my_method"

[hsandt]

I wanted to quickly to go the source code / definition of a custom method passed as a StringName &"my_method", but since it's not directly referenced as a symbol, the hyperlink won't work.

To do so, we could parse StringNames to see if they fit an existing symbol.

However, I can understand the challenge of this because:

• we'd need to parse many unrelated StringNames as we don't know in advance if they are method names or not
• we don't know what class the method would belong to unless we know more about the function using the StringName and some context (e.g. object.call_deferred(&"my_method") hints us that my_method belongs to object, but we must know object's type
• we could just search through all classes like F1, but then there will be some ambiguity (like Sublime Text, open a disambiguation popup for homonymous symbols?)

Because of these uncertainties I'm opening a discussion rather than a proposal.

Also, it's not critical to me right now as I noticed that Godot 4 is favoring direct symbol (method as first-class citizen) usage of StringName function parameters: signal connection with connect, call_deferred, etc. now have a version that you call directly on the Signal or Callable, and you can pass a Callable too, replacing the need for a first argument StringName containing the signal callback. And those symbols are compatible with Ctrl+click.

[theraot]

Be aware that you can do a deferred call like this: object.my_method.call_deferred(), which might be a solution to your issue, while at the same time a complication for your idea because the method might take a StringName as first parameter: object.emit_signal.call_deferred(&"my_signal").

[hsandt]

Yes, that's the last paragraph mentions about Godot 4 new syntax. I suppose I did open the discussion because I had that draft for a while already, or maybe it was related to one of my older project which is still running in Godot 3. Mickeon below mentioned emit_signal but I don't think Godot would be able to understand that my_signal is a signal due to the indirect call with call_deferred in that case.

[theraot]

@hsandt I just did some testing on Godot 4.3 since you posted your reply...

• It seems Godot is able to find a signal under emit_signal.call_deferred(&"...")... But it will only take you to signals defined on the same class, or to the documentation of built-in signals (but not all of them, it seems to take signals in Node only).
• And Godot will take you to the documentation of methods if there is a built-in method matching the name... But it might take you to the wrong one if there are multiple.
• Godot won't take you to the definition of a method, in general.

[Mickeon]

Ideally, String/StringNames should be reserved for dynamic calls when "the thing they refer to" is not guaranteed to exist.

But at the same time, emit_signal still has some legacy code that does allow the signal name to be linked properly. Try clicking on the String passed inside, and if it does exist it'll send you to the declaration. So this kind of thing is not out of the question as a Quality of Life addition.

[hsandt]

Ah, so that means some custom code could be added to detect this in certain contexts at least. But since we don't know how the passed argument will be used deeper in the code, it would make sense to enable it everywhere (as I see no conflict with another hyperlink system - obviously signal as you mentioned, but following a strict convention, signal and methods will never have the same name).

At the moment I'm using StringNames the way you describe it, for "things expected to exist but that may not", in my case state names which are also animation names (I used Enums at first but they didn't support "subclassing" for a hierarchy of characters, so I gave up and just use wild StringNames now; in counterpart I don't have autocompletion, but that's another issue).