Recognizers often ascribe wrong file type, showing spurious error messages #431
Labels
Comments
|
Original implementation in #24 , but it seems to have been broken, or was incomplete. |
tfesenko
added a commit
that referenced
this issue
Aug 10, 2018
Fix contentType for an empty YAML file, now it returns a more generic
YEdit editor.
Why this fix works
1. An empty file always returns `INDETERMINATE` as description. Note
that it's not the `VALID` which is returned when a content describer
actually accepts the input. See
`com.reprezen.swagedit.core.editor.TextContentDescriber.describe(InputStream,
IContentDescription)`:
```
String content = CharStreams.toString(new
InputStreamReader(contents));
if (content.trim().isEmpty()) {
return INDETERMINATE;
}
return isSupported(content) ? VALID : INVALID;
```
2. All ContentDescriber for a given file extensions are equally
important.
Because all the ContentDescriber return `INDETERMINATE`, they are
treated equally important, see
`org.eclipse.core.internal.content.ContentTypeCatalog.collectMatchingByContents(int,
IContentType[], List<ContentType>, ILazySource, Map<String, Object>)`
3. Then `IContentType` are sorted and the first one wins
`org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor(ILazySource,
IContentType[][], Comparator<IContentType>, Comparator<IContentType>)`
sorts the inputs. In case of `INDETERMINATE`,
`ContentTypeCatalog.policyConstantGeneralIsBetter` is used which is...
> A sorting policy where the more generic content type wins.
Lexicographical comparison is done as a last resort when all other
criteria fail.
where more generic content type means, `getDepth()` is based on the
hierarchy defined by the `base-type`:
```
// first criteria: depth - the lower, the better
int depthCriteria = type1.getDepth() - type2.getDepth();
```
--------
By using YEdit as the `base-type`, we make the YEdit the more generic
content type => it will be used in case of empty files.
ghillairet
added a commit
that referenced
this issue
Aug 14, 2018
#431 Recognizers often ascribe wrong file type
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tags: Recognizer
This is a placeholder for an issue I've seen multiple times in regular use and testing. The issue also surfaced as a support ticket from a user who was confused as to why he was seeing errors like this in a YAML file that he intended to be an OpenAPI 2.0 specification:
It's usually possible to resolve this by saving and closing all open files, manually removing errors from the problems view, and reopening the files. But this is an slightly awkward workaround, and not intuitive for many users.
Can we make our validation smarter, so it recognizes when a file is at a point in its lifecycle where its type is not determined yet? It seems to assign a file type in some cases before the user has entered content to clearly indicate OpenAPI 2.0 or 3.0. And once it has ascribed a file type, it doesn't re-evaluate dynamically (enough) to correct itself, until the user takes some action like closing and reopening the file.
I don't know if I'd advocate for highly dynamic re-evaluation of file type, once it has been clearly marked as 2.0 or 3.0. I think the main problem is premature marking of the file as one of those two. Most often 3.0, in my informal observation.
This still needs reproducible test cases, which I haven't yet tried to put together.
The text was updated successfully, but these errors were encountered: