Code assist should support typeahead with dynamic filtering about kaizen-openapi-editor HOT 13 CLOSED

I noticed that filtering works in some contexts, but not others. It appears to work fine on a method. Typing a 'd' filters down to the keywords "deprecated" and "description". But it doesn't work on a parameter item. Typing a letter just closes the code assist suggestions, instead of filtering it.

from kaizen-openapi-editor.

Making this one high priority. Some users are starting to notice that this doesn't work as expected, and in some cases they have the impression that code assist simply doesn't work.

from kaizen-openapi-editor.

I have looked at this. The problem is that in some cases, the yaml parser fails to parse the content of the document after the user enters a character and invoke content assist. The document becomes invalid while the user enters those new characters.
We need what is returned by the yaml parser to compute the content assist proposals, but in those cases maybe we should allow the proposals provider to use the previous state of the document.

from kaizen-openapi-editor.

As @ghillairet mentioned above this task is more difficult than just filtering a list of strings based on a prefix. We have to deal with a parser results for invalid models. For example, Xtext generates a special lightweight Antlr parser (org.eclipse.xtext.ui.editor.contentassist.antlr.internal.AbstractInternalContentAssistParser) and lexer tailored for content assist.
Finding a right approach for implementation of this feature can take some time.

from kaizen-openapi-editor.

@tfesenko @ghillairet, thanks for the input. I continue to think that this is really important, and we should try to find a way to make it work. I'm quite open to considering some creative solutions for this, if you have any.

from kaizen-openapi-editor.

Not sure if @ghillairet's most recent commit, introducing a unified JSON model, helps with typeahead. But I had a couple of thoughts about this that I wanted to record here, when we're ready to get back to it:

• Could we suspend validation while the code assist UI is displayed? So if the user invokes code assist, starts typing, and introduces a validation error while typing, it shouldn't disrupt the functionality of code assist, which is the user's current focus. There are other typeahead scenarios that this may not address, such as typing a partial string and then invoking code assist; but it would still be a big improvement.
• Can we cache the most recent valid state of the document, and present this when the user invokes code assist? This could address that other case, where the user enters a partial string, which introduces an error, and then invokes code assist. I think this is what Guillaume referred to in this previous comment.

from kaizen-openapi-editor.

@tedepstein Actually I've done something in my latest PR that helps with that issue. (I should update the PR comment I haven't wrote all reasons that made me implement that, but the use of a model is not the reason for that fix)

It is done exactly on that line e0d612d#diff-8bef65b0311b7566e89920c6a04c4972R38 What I do is that I only parse the document until the position of the user's cursor, and remove what he already typed. I found that it makes the content assist work in cases where it didn't before.

from kaizen-openapi-editor.

Note (on task/58 branch):
Typeahead work well at the end of a line:

But it does not work in the middle of a line:

I am not sure if the latter is a common scenario though...

from kaizen-openapi-editor.

Except a limitation noted above (the cursor should be at the very end of the line) I did not notice any issues related to typeahead (all on the task branch).

I submitted several general content-assist bugs, the most important one is #217 "Code-assist for schema properties is incomplete". It's hard to verify typeahead for schema definitions when content-assist shows only generic _key_proposals...

IMO, the paths work much better than schema definitions.

from kaizen-openapi-editor.

Typeahead works quite well (with an exception of #217 "Code-assist for schema properties is incomplete").
I found a new bug: code-assist shows code templates that don't start with the provided prefix:

from kaizen-openapi-editor.

@tfesenko wrote:

code-assist shows code templates that don't start with the provided prefix:

I think we could extract that bug to a new issue, which doesn't need to be considered high-priority. @tfesenko , if you agree, please extract it and close this one.

from kaizen-openapi-editor.

@tfesenko , @ghillairet , should we close this issue?

from kaizen-openapi-editor.

I think yes.

from kaizen-openapi-editor.