| org.eclipse.core.contenttype.contentTypes support [message #1688295] |
Fri, 20 March 2015 08:43  |
Eclipse User |
|
|
|
Hi
I've finally identified why my Xtext editors have an irritating log
message (Bug 453669) when saved, whereas the Xtext Xtext editor does not.
The difference appears to be that Xtext editors used to use the
org.eclipse.core.contenttype.contentTypes extension point but don't any
longer. My editors still do.
The problem seems to arise because an Xtext source may be either ASCII
text as seen in the editor, or an EMF model. Thus when
FileDocumentProvider.getCharsetForNewFile prepares for save, the
RootXMLContentHandlerImpl.contentDescription uses
URIConverter$ReadableInputStream.read which throws an NPE when
attempting to use the null encoding 'identified' in a non-XML file.
Failure to support org.eclipse.core.contenttype.contentTypes seems like
a retrograde step. Is this intentional, or should I raise a Bugzilla
suggesting that an XtextContentHandlerImpl override of
RootXMLContentHandlerImpl is needed to support the dual source file
representation that Xtext facilitates?
Regards
Ed Willink
|
|
|
| Re: org.eclipse.core.contenttype.contentTypes support [message #1688351 is a reply to message #1688295] |
Fri, 20 March 2015 10:17  |
| Eclipse User |
|
|
|
Hi
Correction: the problematic org.eclipse.core.contenttype.contentTypes
support only arises if the (manual) genmodel contains a non-blank
contentTypeIdentifier. i.e. a self-inflicted problem invoking an
unsupported combination of functionalities.
Regards
Ed Willink
On 20/03/2015 12:43, Ed Willink wrote:
> Hi
>
> I've finally identified why my Xtext editors have an irritating log
> message (Bug 453669) when saved, whereas the Xtext Xtext editor does not.
>
> The difference appears to be that Xtext editors used to use the
> org.eclipse.core.contenttype.contentTypes extension point but don't
> any longer. My editors still do.
>
> The problem seems to arise because an Xtext source may be either ASCII
> text as seen in the editor, or an EMF model. Thus when
> FileDocumentProvider.getCharsetForNewFile prepares for save, the
> RootXMLContentHandlerImpl.contentDescription uses
> URIConverter$ReadableInputStream.read which throws an NPE when
> attempting to use the null encoding 'identified' in a non-XML file.
>
> Failure to support org.eclipse.core.contenttype.contentTypes seems
> like a retrograde step. Is this intentional, or should I raise a
> Bugzilla suggesting that an XtextContentHandlerImpl override of
> RootXMLContentHandlerImpl is needed to support the dual source file
> representation that Xtext facilitates?
>
> Regards
>
> Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.04155 seconds
Home