PR#3062: Refactor expression completer and unit expressions

[realthunder]

The PR refactors expression completer to complete as much as possible. It can now complete document name/label, object name/label, sub-object name/label, unit, built-in function, property name, property sub path (e.g. Placement.Rotation.Angle), and any Python attributes that are published by the Python object returned directly/indirectly from the property. It can also complete sub-element name of a geo feature, e.g. Face1, Edge2. BTW, although you can refer to geometry sub-element through Property Shape (e.g. Box.Shape.Face1), it is recommend to use dedicated syntax for sub-object/element reference, e.g. Box.<<Face1>>._shape. Because once my topo naming gets merged, it will only support the special syntax. As shown in the following screencast, the completer can help you using that syntax.

Speaking of the sub-object reference, this PR also introduces new alternative syntax for sub-object referencing that is more user friendly. You'll find it much easy to use, e.g. when finding an object in tree view.

Code: Select all

Part002.Part001.Part.Box.Placement

This is a potentially ambiguous syntax, because it is possible that Part002 has a property named Part001. The expression parser accepts this type of syntax and try to resolve it at parsing time and auto change it to the unambiguous version if possible, in order to avoid ambiguity at runtime.

Code: Select all

Part002.<<Part001.Part.Box.>>.Placement

PS. the completer now recognizes TAB and SHIFT-TAB for completion in addition to up and down keys. The following screencast give some brief demonstration. You may also find some unexpected places where expression completer are used.




There are more subtle changes introduced in this PR. The parsing of unit expression has been changed to eliminate the possibility of new unit breaking backward compatibility. Previously, the unit keyword is recognized inside lexical scanner. For example, the unit 'A' will make it impossible for the expression to refer to any object/property with that name. This is not a big problem if we fixed unit keywords. It will be a problem if we keep adding new units (which has happened recently in upstream), because existing expression may refer to some object/property with the now illegal names. This PR addressed this problem by interpreting unit keyword in runtime if there is ambiguity, and give object/property name higher priority over unit, so that existing expression continues to work even if it contains name references that clash with the new unit.

The parser now disambiguate unit reference like this,

* For an identifier immediately following a number, it will only be interpreted as unit, e.g. 1m, where 'm' will always be interpreted as meter.
* For any identifiers inside a bracket that immediately follows a number, they will only be interpreted as unit, e.g. 1(m/s)
* For any other occurrence of an identifier, it will always be treated just like an identifier, and resolved at runtime. If no object or property can be found by that name, it will be tried as unit. For example, 1/m can mean different thing if there is a property named 'm' or not. To refer to unit explicitly, use bracket, 1(1/m)

[Kunda1]

Wow!

[openBrain]

Impressive May we expect it solves issue #4261 ?

[realthunder]

Impressive May we expect it solves issue #4261 ?

I did notice this problem during the development. It is because of the difference in character count when encoding using utf-16 (Qt) and utf-8 (Expression parsing). I just tried and fixed another problem regarding using unicode in display unit. The screencast below also shows that the completer lets you choose alternative form of unit representation.

completer2.gif (350.1 KiB) Viewed 8662 times

[chrisb]

Will the user defined names of constraints be available for completion?

[realthunder]

Will the user defined names of constraints be available for completion?

How is named constraint referenced, in sketch I presume? Something like Constraints.abc? If so, then yes, it will be available for completion.

[chrisb]

Something like Constraints.abc? If so, then yes, it will be available for completion.

Yes and Thanks! Referencing a named constraint inside a sketch is as you described, referencing from outside it is Sketch.Constraints.abc.

[triplus]

Lack of verbose expression auto completion support for sure was one of the sore spots. Good to see this will improve in the future.

P.S. At the time it got implemented, the rationale, to be less verbose and hence user friendly, was the performance penalty.

[realthunder]

Just realized that sketch constraint actually allows the name to contain space, basically any text is allowed. This requires a different way to access them in an expression, i.e. the the map accessing syntax. I have submitted some additional commits to this PR to implement it.

The expression completer will help you with the syntax. You can just type as usual, using '.' followed by some prefixing characters to filter out the entity, and then use Tab key to complete. Remember to stop typing and press Tab before reaching the space, or else the completer will go away, as demonstrated in the following screencast.

You can use the map syntax to access any named constraint, even for those that cannot be recognized by the completer (e.g. name start with space, or digit). For constraints that are named as a valid identifier (no space, starts with an alphabet), you can also accessed through normal attribute syntax.

sketch-constraint.gif (157.92 KiB) Viewed 8323 times

[realthunder]

ping

I am going through the Expression issue tracker, and find it hard to pinpoint exactly which commit to attribute for solving the issue. And many tickets actually involve multiple issues, that are either resolved, or only partially resolved. Any suggestion on what I shall do with those tickets?