Bugzilla – Full Text Bug Listing
| Summary: | AQL's CompletionProposals seems "duplicated" for the end user | ||
|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Cedric Brun <cedric.brun> |
| Component: | Core | Assignee: | Project inbox <sirius.core-inbox> |
| Status: | CLOSED FIXED | QA Contact: | Maxime Porhel <maxime.porhel> |
| Severity: | normal | ||
| Priority: | P3 | CC: | laurent.redor, maxime.porhel, pierre-charles.david |
| Version: | unspecified | Keywords: | triaged |
| Target Milestone: | 3.0.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://git.eclipse.org/r/47794 https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e17a756534faffe9ade72abfe6df939ee59d6da3 |
||
| Whiteboard: | |||
|
Description
Cedric Brun
Moving it to Sirius to address this in the bridge. This is probably better that AQL returns all the proposals and then the calling code decides to remove or "merge" dupplicates. New Gerrit change created: https://git.eclipse.org/r/47794 (In reply to Cedric Brun from comment #0) > For several services (those which are taking a Set<> or List<> as first > arguments) the code completion seems dupplicated to the end user. > > aql:self.eContents()->se<CTRL-SPACE> > => one can see two "select" proposals whereas only one is expected. I don't reproduce this behavior, using Sirius master (623f0db6eabf6a2387688ff316020546a0690f1f) and AQL 3.6.0.201505040910. you should with AQL's master (or a build from yesterday)
Commit
[465036] Return completion offset for services based on the parameters
Bug: 465036
Change-Id: Iaf9989290ca4f7fa646a517f69072d7fe92f4803
makes the proposals instances different as the cursor offset will be different for services which have an 'optional' parameters (implemented by two services)
Sorry, my report is not precise enough. I've seen this behavior using the Acceleo Interpreter view with "Sirius Interpreter", not through the VSM editor (which likely filters the dupplicate already) Gerrit change https://git.eclipse.org/r/47794 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e17a756534faffe9ade72abfe6df939ee59d6da3 Cédric, I'm closing this since your patch is merged. Feel free to reopen if more work is needed here. Cédric, IMO we should see those duplicate: they seems to be duplicates because in the first opened popup the parameters are not shown, but after some delay, the information pane is also opened with additional information (explanation on the parameter types, ...). The current behavior displays only one select proposal, the information pane shows the one taking a list as parameter: the select(Set, LambdaValue) is not exposed. I think that for this specific case, the Set/List first parameter might be the context type on which the service is called (the type of the collection before the ->).. If true, we have to remove the duplicate. The other thing which bothers me is that the ContentProposal.equals only check the proposal without any checks on the information, cursor position, ... (In reply to Maxime Porhel from comment #8) > Cédric, IMO we should see those duplicate: they seems to be duplicates > because in the first opened popup the parameters are not shown, but after > some delay, the information pane is also opened with additional information > (explanation on the parameter types, ...). > > The current behavior displays only one select proposal, the information pane > shows the one taking a list as parameter: the select(Set, LambdaValue) is > not exposed. > > I think that for this specific case, the Set/List first parameter might be > the context type on which the service is called (the type of the collection > before the ->).. If true, we have to remove the duplicate. > > The other thing which bothers me is that the ContentProposal.equals only > check the proposal without any checks on the information, cursor position, > ... I see your point but in practice keeping those dupplicates proposals leads to fairly bad user experience (and BTW these dups are not present in the VSM editor). Proposals which are *proposing* the same text content are essentially the same as their effect on the text *will be the same*. (In reply to Cedric Brun from comment #9) > Proposals which are *proposing* the same text content are > essentially the same as their effect on the text *will be the same*. For services with different kind and/or number of parameter, we expose only the first found (as the text is the same), but this choice the specifier has to open the services classes or the help of each query language to look for existing services, operations, and their alternatives. Validated on Sirius 3.0.0 RC1 Cédric, I mark this as validated because technically the correction is working as expected regarding the first comments on the issue. But we will have to continue the dicussion on an other ticket (not yet created). Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0. |