Drop down for Text.trim 'where' attribute

[JaroslavTulach]

Pull Request Description

Based on Dmitry's hints:

• Extend the Suggestion record so that it can hold information
• In the SuggestionsBuilder populate suggestion records with new extended type data

This PR expands the Suggestion.Attribute structure with optional tagValues hints. It hard-codes these data for the Text.trim method. If we managed to transfer these data to the IDE, display it and use it, we'd have a solid 1st prototype of trivial static drop downs.

TODO

Dmitry also noted:

• Update JSON codecs of suggestion records in the org.enso.languageserver.search.SearchProtocol

That might be necessary step before IDE can accept the newly transmitted tagValues and use them.

Important Notes

It is not the goal of this PR to extract the information directly from the standard library. Enhancing the Enso language type system to provide enough information and extracting them for the Text.trim method is a task for another, orthogonal PR.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the Scala, Java, and Rust style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH ./run dist and ./run watch.

[hubertp]

lgtm so far

[kustosz]

This is nice in its simplicity, but way too brittle I'm afraid. The IDE needs slightly more understanding – like what Location is and where it comes from. What I'm saying is, pasting the string Location.Both is rather incorrect, if Location is not an imported symbol. Or if someone did:

import Standard.Base.Text.Location as Text_Location

The IDE must understand how to handle such renames or auto-imports.

[JaroslavTulach]

This is nice in its simplicity,

Intentionally oversimplified.

but way too brittle I'm afraid. The IDE needs slightly more understanding – like what Location is and where it comes from...
Location.Both is rather incorrect, if Location is not an imported symbol.

Imports! NetBeans IDE has a special TreeMaker support to create a qualified identifier; Simple name will automatically be used if appropriate, adding any needed imports, following user's preferences. To follow the same approach we could say that tagValues are supposed to contain fully qualified names. Then it'd be up to the IDE to handle its imports.

The other approach is to delegate the responsibility to the engine runtime & its language server. The engine would then be responsible for updating the source:

• either by specifying in advance what to do when the selection is made
• or be notified that the selection was made and "realize it"

Specifying this in advance as part of every Suggestion.Attribute may be too costly. Moreover such suggestion would be context sensitive - different depending on the source that calls the function. Are we left with FQNs or a callback on selection?

[kustosz]

To follow the same approach we could say that tagValues are supposed to contain fully qualified names.

I think this is the most sensible approach for now. And the IDE already deals with qualified names in other places, I think. And they have systems for deciding "is this symbol imported already?" and other such queries. Summoning @4e6 to make sure.

[JaroslavTulach]

... sensible approach for now ... the IDE already deals with qualified names ...

OK, let's treat the names as qualified.

[JaroslavTulach]

This PR is no longer relevant after Marcin implemented his #3422 - closing.

[JaroslavTulach]

This PR is no longer relevant after Marcin implemented his #3422 - closing.