-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: