feat: inline autocompletion

[azmkercso]

Issue #, if available: N/A

Description of changes:
Inline autocompletion feature.
Minor fixes to ghost text display.
Snippet manager preview text.

The popup-based autocompletion is augmented with optional inline-code rendering. This feature is turned off by default, so no unexpected ghost text appears for users in the new version. It can be turned on with the inlineEnabled boolean flag in the Autocomplete widget.
This autocompletion displays the inline completions on a best effort basis (if the completion's prefix allows it), as the autocomplete settings might not be fully compatible with inline completion (eg: matches based on caption not prefix might cannot be rendered inline).
If the inline completions are enabled, the popup position is dynamically updated whenever it would overlay a multi-line inline completion suggestion.

An other external widget was created which can be used for inline-only completion. Here, all the completions are guaranteed to be compatible with inline rendering, and the commands are set up in a way to promote more horizontal (left-right, rather than up-down) controls for autocompletion. This widget could be used as is, to allow both style of completions, or could be used as a reference implementation for integrators.

This external inline autocompletion widget works similarly to the previous popup-based autocompletion with a few differences:

• It displays a slightly different set of completions (strict prefix match with exactMatch, and does not try to match on caption value)
• It always renders a ghost text completion directly into the editor
• It optionally shows a command bar tooltip with the available commands for easy navigation. These commands are dynamically updated, and clickable.
• Editor scrolling with mouse does not cancel the autocompletion (so long snippets can be also inspected)

Keybindings:

• Manual trigger: Alt/Option-C
• Previous suggestion: Alt/Option-[
• Next suggestion: Alt/Option-]
• Accept suggestion: Tab or Ctrl/Cmd-Right
• Close suggestions: Esc

The popup and the inline style autocompletions are mutually exclusive, only one is attached at a time (they share the same editor.completer property). However, they can seamlessly switch when both of them are configured to different keybindings.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[nightwing]

Looks very good, but overall the choice of replacing the existing autocompletion instead of augmenting it, is unexpected for me. Some users may want the behavior of chrome devtools where it both shows the completion inline and a normal popup.

Also i think it would be better to keep this in a separate extension instead of adding to language_tools, because the vast majority of users would not be using this.

And another question, what should happen if the line has an autopaired brace inserted? E.g. if user writes if ( editor inserts closing ) and completer returns a result for the whole if block?

[azmkercso]

Looks very good, but overall the choice of replacing the existing autocompletion instead of augmenting it, is unexpected for me. Some users may want the behavior of chrome devtools where it both shows the completion inline and a normal popup.

Yes, that's a very good point, I am working on a new revision to reuse the current autocompletion instead of a new one and show the popup with inline text. However inline-text only mode requires slightly different navigation and rules, so I think the two different types of completer makes sense (inline-only, and popup with optional inline text).

Also i think it would be better to keep this in a separate extension instead of adding to language_tools, because the vast majority of users would not be using this.

Sure, removing it from there.

[azmkercso]

And another question, what should happen if the line has an autopaired brace inserted? E.g. if user writes if ( editor inserts closing ) and completer returns a result for the whole if block?

Currently when I tested, no autopaired brace was inserted while the autocomplete was active. However the behaviour is not handled explicitly at the moment.
It could either:

• abort the autocompletion, or
• implement the deleteSuffix option, or
• treat only the left prefix of the completion for the possible suggestions, but also replace the additional ) on insert if the first parantheses or the suggested inline text matches the inserted pair (in this case )).

[azmkercso]

Update: enabled optional inline completion, and moved the inline-only autocompletion to a separate extension.
Details are in the updated description

[codecov]

Codecov Report

Patch coverage: 93.39% and project coverage change: +0.39 🎉

Comparison is base (338dacf) 86.20% compared to head (70859cb) 86.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5084      +/-   ##
==========================================
+ Coverage   86.20%   86.60%   +0.39%     
==========================================
  Files         548      555       +7     
  Lines       41704    42931    +1227     
  Branches     6564     6697     +133     
==========================================
+ Hits        35953    37181    +1228     
+ Misses       5751     5750       -1     

Flag	Coverage Δ
unittests	86.60% <93.39%> (+0.39%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/css/editor.css.js	100.00% <ø> (ø)
src/autocomplete.js	69.69% <79.76%> (+4.34%)	⬆️
src/ext/inline_autocomplete.js	89.44% <89.44%> (ø)
src/autocomplete/popup.js	82.03% <93.18%> (+3.27%)	⬆️
src/ext/inline_autocomplete_tooltip_test.js	96.09% <96.09%> (ø)
src/autocomplete/inline.js	96.96% <96.96%> (ø)
src/autocomplete/popup_test.js	97.70% <97.70%> (ø)
src/autocomplete/inline_test.js	99.39% <99.39%> (ø)
src/ext/inline_autocomplete_test.js	99.53% <99.53%> (ø)
src/keyboard/textinput.js	75.94% <100.00%> (ø)
... and 3 more

... and 16 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[nightwing]

• when cursor is at the top of the page toolbar is not visible
• i would expect alt-c the second time to act as next command
• the () around alt-[ make it look like alt-D
• when pressing alt-c at the start empty line, toolbar behaves as if it is cycling through suggestions but editor doesn't show anything

the last issue seems to be caused by a bug in addToken which should do if (column == null || !tokens.lenght) { at

ace/src/virtual_renderer.js

Line 1665 in e0d4ea9

if (column == null) {

[andredcoliveira]

Left some comments. Would it be possible to add this to the kitchen sink so we can play around with it too?

[andredcoliveira]

Would it make sense to test with more than one editor? I interpret it as being a specific use case we want to support based on AceInline's implementation

[azmkercso]

Yes, this needs to support multiple editors, as Autocomplete uses it, which could use a shared editor instance if the sharedPopups config parameter is set to true

[azmkercso]

Would it be possible to add this to the kitchen sink so we can play around with it too?

I added it to the kitchen sink so it can be tested. Alt/Option-C triggers the inline autocompletion, and the usual Ctrl-Space triggers the popup based autocompletion. Only one can be active at a time, the other one is destroyed if the other autocompleter is triggered.

I also added an option which overrides the inlineEnabled option for Autocomplete which is disabled by default (mainly to keep the current behaviour after the update). With this, the popup based autocompletion also renders an inline preview (if possible).

[andredcoliveira]

Looks good to me. Nice set of changes and the addition to the kitchen sink was very much appreciated :).

There is only one detail/edge case that I'd like to leave a note here of:

• when showing inline autocompletion suggestions that contain multiple suggested lines and they go beyond the bottom of the editor, specifically when using the default autocompletion interaction (e.g.: ⌥ + Space for MacOS, not ⌥ + C), the blur behaviour of the auto-completion popup that is to stop showing the suggestion makes it so it's not possible to scroll lower in the editor and see all suggested lines.
  • I don't find this to be a blocker to this PR