XText Web - assist cancels validation [message #1794658] |
Tue, 04 September 2018 14:57 |
Mykola Makhin Messages: 50 Registered: July 2018 |
Member |
|
|
Hi
I've run into a problem with XText web editor using Ace editor.
I want to trigger auto-completion automatically whenever user changes content of the editor, or changes position of the cursor in the editor.
I've found ways to do that, but, apparently, this has created another issue - concurrent call to assist endpoint cancels currently running validate call. Validate simply returns
{ "conflict": "canceled" }
and ACE editor doesn't seem to do anything about it.
As a result, validation has practically stopped working.
It seems that cancellation is peformed by org.eclipse.xtext.web.server.model.DocumentSynchronizer, but it's hard to tell because of the weird way XTextServlet is implemented (with abstract set of "services" called via dispatcher, and everything being implemented in Xtend instead of Java doesn't help the case either).
Looking at DocumentSynchronizer it seems that it's acting as an optimistic lock of sorts, essentially failing any job on parallel execution.
It's not clear how is it possible to use XText Web at all then, since all AJAX calls to it would be asynchronous and concurrent, and they're going to cancel each other. Moreover, it's not clear why this synchronization takes effect for services like content assist and validation, that don't actually change the content - they only need read access to current state of AST.
Can anyone tell me how to circumvent the issue? Where do I even being with all this?
Thanks!
[Updated on: Tue, 04 September 2018 15:00] Report message to a moderator
|
|
|
Re: XText Web - assist cancels validation [message #1794660 is a reply to message #1794658] |
Tue, 04 September 2018 15:29 |
|
hi, can you please provide a reproducible example? do you use the full text or the incremental mode?
org.eclipse.xtext.web.server.contentassist.ContentAssistService.createProposals(XtextWebDocumentAccess, ITextRegion, int, int) indeed does a prio readonly
=> this will cancel other readers.
i assume this will be done cause you dont want to wait for ca.
since both can have side effects on the ast they cannot run in parallel
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
[Updated on: Tue, 04 September 2018 15:49] Report message to a moderator
|
|
|
Re: XText Web - assist cancels validation [message #1794672 is a reply to message #1794660] |
Tue, 04 September 2018 17:58 |
Mykola Makhin Messages: 50 Registered: July 2018 |
Member |
|
|
Hi. I'm using the defaults thus incremental mode.
The content assist is only triggered by pressing ctrl+space by default though, so I've made a change to make it run on every update to the editor content and on every cursor move:
require(["webjars/ace/1.2.3/src/ace"], function() {
require(["xtext/xtext-ace"], function(xtext) {
window.editor = xtext.createEditor({
baseUrl: baseUrl,
syntaxDefinition: "xtext-resources/generated/mode-mylang"
});
window.editor.xtextServices.editorContext.addServerStateListener(function() {
var cursorPosition = editor.getCursorPosition();
editor.xtextServices.getContentAssist().done(function(proposals){ updateProposals(proposals, cursorPosition); });
});
window.editor.getSelection().addEventListener("changeCursor", function() {
var cursorPosition = editor.getCursorPosition();
editor.xtextServices.getContentAssist().done(function(proposals){ updateProposals(proposals, cursorPosition); });
});
});
});
The updateProposals function will populate separate window with list of proposals that user can click and have inserted at the recorded cursor position.
It's somewhat surprising to me that creating proposals for content assist has some side effects on AST. I'm not sure why AST would change on retrieving list of proposals - seems that should've been a completely "read only" operation for AST.
Is this related to some caching or lazy parsing? o_O
[Updated on: Tue, 04 September 2018 17:59] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05140 seconds