| Incremental updates on editor models [message #1836286] |
Mon, 28 December 2020 06:06  |
Eclipse User |
|
|
|
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
|
|
|
|
| Re: Incremental updates on editor models [message #1836306 is a reply to message #1836290] |
Mon, 28 December 2020 14:48  |
| Eclipse User |
|
|
|
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
|
|
|
|
| Re: Incremental updates on editor models [message #1836349 is a reply to message #1836331] |
Tue, 29 December 2020 14:32 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.04963 seconds
Home