Recognizers often ascribe wrong file type, showing spurious error messages

[tedepstein]

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.

[tedepstein]

Original implementation in #24 , but it seems to have been broken, or was incomplete.