| Content assist behavior in embedded xtext ocl editor [message #1032748] |
Wed, 03 April 2013 07:42  |
Eclipse User |
|
|
|
Hi,
I am currently trying to implement an embedded ocl editor to be
included in the GMF tooling project to support edition of OCL
constraints.
I have been looking at a solution based on the essential ocl xtext
editor available in the console example. The behavior during content
assist seems odd, as it seems the context is not changing while typing.
For example in the xtext console example, if I start with as context an
EClass and write:
self.eAllAttributes->collect(e | e.) <- context lost
At this point the content assist seems to think e is an EClass as it
proposes solutions for it and not for an EAttribute.
If I start to write eType for example, the content assist start to
propose it to me, but then when I reach the dot, the context is lost
again.
self.eAllAttributes->collect(e | e.eType. ) <- context lost
Is it a current limitation or am I doing something wrong?
BRs,
Guillaume
|
|
|
|
| Re: Content assist behavior in embedded xtext ocl editor [message #1032790 is a reply to message #1032771] |
Wed, 03 April 2013 08:35  |
| Eclipse User |
|
|
|
Ed,
Thanks for the answer, I will take a look at the papyrus implementation.
> I don't understand your example since you seem it is not clear where
> the cursor is. It is helpful to use "@" in such examples.
Sorry for that, the cursors are supposed to be at the last dot.
>> self.eAllAttributes->collect(e | e.@)
>> self.eAllAttributes->collect(e | e.eType.@ )
BRs,
Guillaume
On 2013-04-03 14:15:00 +0200, Ed Willink said:
> Hi
>
> You might want to look at
> org.eclipse.papyrus.uml.textedit.constraintwithessentialocl.xtext for
> an example of the re-use.
>
> Poor context assist following navigation operator seems to be an Xtext
> feature. I asked a question on the TMF newsgroup and Sebastian seems to
> suggest that I need to write some tacky code to correct the considered
> options. Not high on my priority list at present. I don't like writing
> code that will probably go wrong within 12 months.
>
> I don't understand your example since you seem it is not clear where
> the cursor is. It is helpful to use "@" in such examples.
>
> Regards
>
> Ed Willink
>
>
> On 03/04/2013 12:42, Guillaume Hillairet wrote:
>> Hi,
>>
>> I am currently trying to implement an embedded ocl editor to be
>> included in the GMF tooling project to support edition of OCL
>> constraints.
>>
>> I have been looking at a solution based on the essential ocl xtext
>> editor available in the console example. The behavior during content
>> assist seems odd, as it seems the context is not changing while typing.
>>
>> For example in the xtext console example, if I start with as context an
>> EClass and write:
>>
>> self.eAllAttributes->collect(e | e.) <- context lost
>>
>> At this point the content assist seems to think e is an EClass as it
>> proposes solutions for it and not for an EAttribute.
>>
>> If I start to write eType for example, the content assist start to
>> propose it to me, but then when I reach the dot, the context is lost
>> again.
>>
>> self.eAllAttributes->collect(e | e.eType. ) <- context lost
>>
>> Is it a current limitation or am I doing something wrong?
>>
>> BRs,
>> Guillaume
|
|
|
Powered by
FUDForum. Page generated in 0.03250 seconds
Home