| Use formatter while programmatically changing a document [message #1003582] |
Mon, 21 January 2013 10:04  |
Eclipse User |
|
|
|
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  |
| Eclipse User |
|
|
|
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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.08340 seconds
Home