Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Use formatter while programmatically changing a document
Use formatter while programmatically changing a document [message #1003582] Mon, 21 January 2013 15:04 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1036
Registered: July 2009
Senior Member
This is kind of the inverse to a recent question in this forum:

What I'm doing:
- programmatically inserting elements into a model that is shown in a visible editor
- using document.modify(IUnitOfWork) for the modification
- finally calling editor.doSave(IProgressMonitor)
(All this happens under my own control, independent of any quick fix or the like).

What I want:
- the text should be formatted according to the formatter configuration for that language

What I get:
- line breaks are correctly generated
- indentation does not work

Next I tried:
- ((SourceViewer)editor.getInternalSourceViewer()).doOperation(SourceViewer.FORMAT);
- editor.doSave(monitor)

This mostly works but in particular situations the document and its resource get out of sync resulting in broken inserts. At a closer look this sometimes happens when formatting added additional (whitespace) characters: the DefaultTextEditComposer still held onto a Resource with shorter content, hence indices don't match any longer and TextEdits garble the content.

Questions:
- I'm guessing the explicit doOperation(FORMAT) shouldn't be needed, right?
- Can I specify SaveOptions with "formatting=true" when using document.modify() & editor.doSave()? (would that help?)
- I guess doOperation(FORMAT) should still be allowed without creating garbage, right?

I do have a workaround which includes sending notifyChanged() to the internal DefaultTextEditComposer. This re-syncs the resource stored in the composer and all is good. This is the only way I found for meeting the requirements, but it looks like an ugly hack.

Am I missing s.t. obvious?

thanks,
Stephan

Re: Use formatter while programmatically changing a document [message #1003730 is a reply to message #1003582] Mon, 21 January 2013 22:20 Go to previous message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 2943
Registered: July 2009
Senior Member
Hi Stephan,

there was a bug in IXtextDocument#modify which sometimes yielded an
outdated resource. Workaround: Perform a dummy read before modifying the
resource.

Manually invoking the formatter is currently necessary. We do not
trigger the formatter for any modifying operation right now (besides an
explicit format).

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 21.01.13 16:04, schrieb Stephan Herrmann:
> This is kind of the inverse to a recent question in this forum:
>
> What I'm doing:
> - programmatically inserting elements into a model that is shown in a
> visible editor
> - using document.modify(IUnitOfWork) for the modification
> - finally calling editor.doSave(IProgressMonitor)
> (All this happens under my own control, independent of any quick fix or
> the like).
>
> What I want:
> - the text should be formatted according to the formatter configuration
> for that language
>
> What I get:
> - line breaks are correctly generated
> - indentation does not work
>
> Next I tried:
> -
> ((SourceViewer)editor.getInternalSourceViewer()).doOperation(SourceViewer.FORMAT);
>
> - editor.doSave(monitor)
>
> This mostly works but in particular situations the document and its
> resource get out of sync resulting in broken inserts. At a closer look
> this sometimes happens when formatting added additional (whitespace)
> characters: the DefaultTextEditComposer still held onto a Resource with
> shorter content, hence indices don't match any longer and TextEdits
> garble the content.
>
> Questions:
> - I'm guessing the explicit doOperation(FORMAT) shouldn't be needed, right?
> - Can I specify SaveOptions with "formatting=true" when using
> document.modify() & editor.doSave()? (would that help?)
> - I guess doOperation(FORMAT) should still be allowed without creating
> garbage, right?
>
> I do have a workaround which includes sending notifyChanged() to the
> internal DefaultTextEditComposer. This re-syncs the resource stored in
> the composer and all is good. This is the only way I found for meeting
> the requirements, but it looks like an ugly hack.
>
> Am I missing s.t. obvious?
>
> thanks,
> Stephan
>
>
Previous Topic:Xtext, debug and method calls
Next Topic:New Release on March 20th
Goto Forum:
  


Current Time: Fri Nov 28 22:11:36 GMT 2014

Powered by FUDForum. Page generated in 0.02174 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software