Variable autocompletion in expressions

[D8H]

This is committed over: #2702

I didn't find an easy way to use undefined variables without having them calculated at every input so I revert it. I'll create an issue for it.

[4ian]

I didn't find an easy way to use undefined variables without having them calculated at every input so I revert it. I'll create an issue for it.

Indeed, for undefined variables which require a more complex analysis (compared to "just" calling enumerateVariables), we might think about a cache/memoization of the results, with the challenge being (like all caches) to:

• properly invalidate the cache when needed
• and properly index the results with a proper "key".

I think we could have this "cache" created at the initialization of a GenericExpressionField, and passed down to the autocompletions so that autocompletions of variables can be stored there.
When a GenericExpressionField is blurred/destroyed, we release the cache.

This way we would compute variables "only" once per scene/project/object per field.

But all of this is if we want to support "undefined variables". Maybe we don't want to even do this in expressions?

When you write an expression, it might be acceptable to handle in autocompletions only the properly declared variables. It would encourage to declare them. And you always have the variables editor that will help you find undefined variables - and at this moment we can afford the "CPU power" to do it (because we only do it once per dialog, which is fair).

So for now I would say not to worry about this, and create another issue to tackle this later? :)

[4ian]

nitpicking: a variable name is technically not a "Text" (which means, in this context, a "string literal", i.e: a sequence of characters enclosed in double quotation marks), but an "Identifier" (which means, in this context, a sequence of characters, excepted for special separator characters (like spaces, comma, dots...) and that does not start with a number).

So the autocompletion here if really providing you with an "Identifier", so we should set the kind to it (not that it will change anything, but something in the future might rely on this information).

Also add it to the export type ExpressionAutocompletion type (like Text) and this should be good to go!

[4ian]

Looks great! 🚀 Added a nitpicking comment, then we're good!

[D8H]

ExpressionCompletionFinder doesn't give any autocompletion description when the cursor is on a child name. I think it should be ok because the GUI gives the children in the autocompletion of the parent but this is not user friendly.
I opened an issue to make the autocompletion per variable path element: #2715

[4ian]

ExpressionCompletionFinder doesn't give any autocompletion description when the cursor is on a child name. I think it should be ok because the GUI gives the children in the autocompletion of the parent but this is not user friendly.
I opened an issue to make the autocompletion per variable path element: #2715

Yep, this is also a bit similar to the fact that the autocompletion in the variables editor was restricted to "root variables". Support for structure/arrays could be added for expressions and for variable dialogs, so that:

• only variables at the current levels are autocompleted (i.e: you don't get all the autocompletions from the parent)
• it's also supported for any arbitrary child

This improvement could be done to the VariableField, the expressions and the Variable editor dialogs (i.e: everything that relies on enumerateVariables).