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 10:04 Go to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 926
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 17:20 Go to previous message
Sebastian Zarnekow is currently offline Sebastian Zarnekow
Messages: 2807
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: Sat Apr 19 21:52:06 EDT 2014

Powered by FUDForum. Page generated in 0.01403 seconds