|
| Re: Use formatter while programmatically changing a document [message #1003730 is a reply to message #1003582] |
Mon, 21 January 2013 22:20  |
 Sebastian Zarnekow
Messages: 3118
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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03429 seconds
] 
Search
Help
Register
Login
Home
