|
|
| Re: Debugging a DSL with spaces in its path [message #1820749 is a reply to message #1820725] |
Tue, 28 January 2020 06:10   |
Eclipse User |
|
|
|
Xtext generates the traceRegion for this example in org.eclipse.xtext.builder.updateTraceInformation:
line 423: AbstractTraceRegion traceRegion = ((ITraceRegionProvider) contents).getTraceRegion()
CompletableTraceRegion [myOffset=0, myLength=4385, useForDebugging=false] associations={
LocationData [TextRegionWithLineInformation [0:51][lineNumber=0, endLineNumber=4]][path=aa%20bb/test2.proc]
} nestedRegions={
CompletableTraceRegion [myOffset=3631, myLength=215, useForDebugging=true] associations={
LocationData [TextRegionWithLineInformation [21:27][lineNumber=1, endLineNumber=3]][path=aa%20bb/test2.proc]
} nestedRegions={
CompletableTraceRegion [myOffset=3704, myLength=39, useForDebugging=true] associations={
LocationData [TextRegionWithLineInformation [33:11][lineNumber=2, endLineNumber=2]][path=aa%20bb/test2.proc]
}
}
}
There is a '%20' in the relative path to the DSL instead of a space: [path=aa%20bb/test2.proc].
This comes from a call to the DefaultTraceURIConverter org.eclipse.xtext.generator.trace.getURIForTrace which returns aa%20bb/test2.proc.
I overrode this method and the problem went away. So we have a workaround (albeit with Discouraged access).
In my version of org.eclipse.xtext.generator.trace.DefaultTraceURIConverter::getURIForTrace(IProjectConfig projectConfig, AbsoluteURI absoluteURI).
I pre-process your absoluteURI using EMF's URI.decode
AbsoluteURI decodedAbsoluteURI = new AbsoluteURI(URI.createURI(URI.decode(absoluteURI.getURI().toString())))
Is this a bug or is there a configuration I have missed?
|
|
|
|
|
|
| Re: Debugging a DSL with spaces in its path [message #1820771 is a reply to message #1820760] |
Tue, 28 January 2020 09:18 |
| Eclipse User |
|
|
|
Hi
Most code where awkward characters can be troublesome have evolved a very diligent API that enables the use of raw/safe representations to be accommodated.
For EMF, whenever you create a URI from a String, you must provide a Boolean argument that says whether conversion to a safe representation has already occurred and should not be repeated. Conversely whenever you convert a URI to a String you must specify whether you want the raw or safe representation.
Most programmers neglect to pay as much attention as they could when specifying these arguments, and for sensible file names, who cares, it is not a problem; "true" will do.
However if you insist on using awkward names you can expect that almost every tool that you use will have multiple representation preservation bugs and you can spend your time complaining to the developers. This one looks like an Xtext oversight.
Much simpler to avoid the problems. I install everything that I care about in C:\Tools not C:\Program%20Files.
(With hindsight, EMF could have distinct RawURI and SafeURI classes so that the type system rather than the programmer's diligence ensures appropriate conversions.)
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.08501 seconds
Home