Eclipse Community Forums: TMF (Xtext) » Incremental updates on editor models

Help

Home

Home » Modeling » TMF (Xtext) » Incremental updates on editor models

Show: Today's Messages :: Show Polls :: Message Navigator

Incremental updates on editor models [message #1836286]

Mon, 28 December 2020 11:06

Lars Fritsche

Messages: 8
Registered: April 2017

Junior Member

Hi,

is there a way to get incremental updates for the Xtext editor models?
My goal would be to get or generate notifications using something like an EContentAdapter that tell me how these models were indirectly changed by a user when he edits the textual representation in the editor.
The reason why a new parsing would not be sufficient is that our tool needs model change notifications to work properly.

Background:
We search for patterns in our model in an incremental way and rely heavily on the EMF notification framework.
Using our tool, information can be synchronized between two different models, which is especially hard when both models have been changed independently.
What we would like to do is to implement an Eclipse View where two separate Xtext editor views are open with files that have identical content.
These files are to be kept synchronized.
A user might then decide to change both models in those editors independently to each other and, thus, inflict some conflicts, e.g., when elements in one editor are deleted but are extended in the other editor.
We would like to detect these changes and implement our own conflict resolution view as a proof-of-concept for textual editors.
For this purpose, we need incremental updates on the editor models or at least the information of what has changed (new/deleted nodes/edges and changed attributes).

Is something like this possible?

Regards
Lars

Report message to a moderator

Re: Incremental updates on editor models [message #1836290 is a reply to message #1836286]

Mon, 28 December 2020 13:15

Uli Merkel

Messages: 250
Registered: June 2013

Senior Member

Hi Lars,

IIRC, a couple of years ago (2015?) on xtextCon in Kiel,
there was an xtext example which combined the textual editor with a graphical editor.
And modifications in on editor was immediately synchronised in the other one.
The visitors were pretty impressed becaus this implementation was very simple to do.

Perhaps Christian (or someone else from itemis) can tell us more who gave the presentation and where to get the sourcecode.

A Healthy New 2021, Uli

Report message to a moderator

Re: Incremental updates on editor models [message #1836306 is a reply to message #1836290]

Mon, 28 December 2020 19:48

Ed Willink

Messages: 7597
Registered: July 2009

Senior Member

Hi

The Xtext semantic model that you see is updated from the node model and you are instructed to expect that the semantic model is regenerated between IUnitOfWork accesses, however in practice unchanged parts are often re-used. This gets you closer to being able to use EMF change tracking, But...

If you run your incremental update analysis very frequently you may have only one editor action to synchronize using some form of semantic identity to correlate old and new. But this will make the editor unacceptably sluggish since the user will have to drop their typing speed. And some actions such as quick fixes / pastes may involve substantial chnages. Worse, considering Java, if the user is adding a for(){} loop and makes a mess of the punctuation the editor may spend a significant time struggling to make sense of the {} mismatches. (It would be much better if the editor partitioned the source text into a hierarchy of {} delimited sections, and avoided detailed parse while the sectioning is bad. Once good, onlky changed sections need be reparsed, but it may be a bugger change.)

The node model and semantic model could be maintained incrementally, but one of the Xtext developers very sensibly observed that such a manually coded incremental conversion was just too hard. You would need a fundamentally incremental tool such as perhaps EMF-IncQuery today or QVTd tomorrow.

Comparison of models to determine incremental changes is really hard and explains why two different Eclipse projects EMF Compare and EMF Diff/Merge offer contrasting approaches, neither of which may be suitable for a model for which you have significant domain insight.

And even when you can compare what is a change? Consider the Java

int before[] = new int[]{1,2,3};

long after[] = new long[]{2,3,1};

Is it a total delete / create? Is it a retype+rename+(a 3 value recreate or a 2-value rotate plus 1-valuedelete/add)?

Or just consider the GIT Merge panes. Sometimes they're pretty good, but other times particularly if you reorder some functions they are very disappointing.

Once you have decided what you want to treat as a change, you can design a per semantic model element semantic identity computation that maximizes the equality for semantically unchanged elements and then allows you to start to decide whether unmatched elements are create/delete or evolve.

(For different reasons Eclipse OCL has a LUSSID class (Locally Unique Semantically Sensitive ID) that enables compact stable xmi:ids to be auto-generated. This might give you some ideas wrt hierarchical computations but it treats a hierarchical name change as delete/create - no evolution.)

Regards

Ed Willink

Report message to a moderator

Re: Incremental updates on editor models [message #1836331 is a reply to message #1836290]

Tue, 29 December 2020 10:09

Lars Fritsche

Messages: 8
Registered: April 2017

Junior Member

Hi,

@Uli: I may have found the mentioned presentations code, which is about connecting Xtext to different GEF editors. Thanks for the hint! I'll have a look into this.

@Ed Willink: Thanks for the detailed reply!
This sounds quite promising.

Does this mean that when a reparsing is triggered the same XtextResource is updated to which I could register a ContentAdapter?
I found a reference to the PartialParsingHelper in some thread. Do I need this component?

Regarding identity computation, is this something I would do to help Xtext figure out, which elements are to be preserved instead of re-creating them?

Our tool (eMoflon) tracks and restores consistency in a rule-based manner.
The incremental part of our engine is only the pattern matcher, which searches for specific patterns that tell us where such a rule could be applied but we are not forced to do this frequently (or element-wise).
Also, the pattern matcher can cope with bigger changes as long as we can tell him (via notifications), which parts have changed.

Regards
Lars

Report message to a moderator

Re: Incremental updates on editor models [message #1836349 is a reply to message #1836331]

Tue, 29 December 2020 19:32

Ed Willink

Messages: 7597
Registered: July 2009

Senior Member

Hi

No. I suspect that you will find that while unchanged bits are often preserved the pessimistically changed bits are trashed. I would guess that for consistently valid transient editing states the changes that a ContentAdapter reports may be ten times larger than 'necessary' . But whenever the transient state loses it e.g. for mismatched punctuation you will find that the Resource may see a 100% change once it exists again. In the meantime you may see that the Outline is blank because the Resource content got lost. Unless you can get adequate results from this in a very short development time, I recommend abandoning a ContentAdapter approach since IMHO it is almost certainly unsound except in trivial cases and may be differently unsound in a future Xtext release..

'Helping' Xtext might be possible, but might be hard, require internal or restricted API, and again might break in a future Xtext release. I suggest that you treat the Xtext Resource as a candidate that you synchronize using semantic similarity with your previous Resource so that you can use the candidate/previous differences as your increments. NB your 'previous' Resource must be a copy (probably using EcoreUtil) to avoid your 'stable' reference being 'improved' by the next edit operation.

Regards

Ed Willink

Report message to a moderator

Previous Topic:	Keyword with whitespace
Next Topic:	Custom scheme for import URIs

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Jun 08 22:10:49 GMT 2023

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter