AutoPairs masses with macros

[TalAmuyal]

When recording iconst a =(\n as input (using qq), I expect @q to put const a (\n\t\n) but instead I get const a ()\t.

[bryphe]

Nice find @TalAmuyal ! Thanks for tracking this.

Since some of the auto-closing pairs manipulation happens via the msgpack API, it seems that doesn't get picked up as part of the macro (since the macro just records keystrokes, not API calls). It's important for us to have a story for this, as we start to expand out more, similiar features (like snippets) - it'll be a recurring problem.

I can see a few potential solutions to this:

• Modify the auto-closing pairs behavior to send keystrokes, instead of the API calls. This could potentially be cumbersome, but would fix this specific issue.
• See if it's possible for Neovim to handle this - perhaps it could keep track of the API calls / manipulations as part of the macro? This seems pretty complicated though for arbitrary API calls.
• Track macros at the Oni layer - in other words, replay keystrokes for Oni's input handler - which would hit the auto-closing pairs logic in a reproducible way. There'd be challenges in how we rationalize this with the Neovim layer.

[TalAmuyal]

Also (as noted at #1201), auto-completion isn't recorded as part of the input for the dot (.) command.

The source is likely the same and both features likely have the same error with both the dot command and macros.

To reproduce:

Input: i clas\n<esc>0. Expected output: class class Actual output: clas class

Regarding the solution, I believe it should involve telling the Neovim back-end about the changes and let it incorporate it into its engine so no wired side effects occur and in order to avoid duplicating core functionality of Vim itself.

So, TL;DR:

The first option looks to be the best fit. Maybe it could be improved by a batching mechanism (send all keys of the completion in one go).

[vrinek]

See if it's possible for Neovim to handle this [...]

(re: autoClosingPairs); Vim has some plugins that handle auto closing pairs. Would it make sense to replace Oni's implementation with a Neovim plugin?

I've recently disabled Oni's autoClosingPairs and installed the auto-pairs vim plugin. Functionality is comparable and macros work well.

[CrossR]

@vrinek there is a little discussion about that over in #947.

The biggest thing I see is integration with textmate grammars, ie we can disable auto-pairs in a given context. I love having ' ' auto pairs....but it annoys me in comments. With Oni's implementation we can have them be smarter and disable them in comments etc in a language-agnostic way. So for every language with a TM Grammar, we get smarter auto pairs for free.

That said, currently we don't have that and bugs like this...so there is definitely a balance. Currently I've been tempted to disable them a few times, but I think with a few fixes they could be great.

[escorponox]

Any news on this???? It is the only real problem for me atm. I use vim auto-pairs, but #2257 is still a pain for me.

I could try to attack this, but I'd need some guidance at the start and a opinion of the team about the best approach.

[akinsho]

@escorponox, this is issue is a real bug bear of mine and I think most of the other collaborators but I also think there isn't really a clear fix that I personally can envision other than the different strategies @bryphe suggested above,

Modify the auto-closing pairs behavior to send keystrokes, instead of the API calls. This could potentially be cumbersome, but would fix this specific issue.

See if it's possible for Neovim to handle this - perhaps it could keep track of the API calls / manipulations as part of the macro? This seems pretty complicated though for arbitrary API calls.

Track macros at the Oni layer - in other words, replay keystrokes for Oni's input handler - which would hit the auto-closing pairs logic in a reproducible way. There'd be challenges in how we rationalize this with the Neovim layer.

The first solution is possibly the easiest but the least generalisable it will only fix this one issue but there are other related issues like #2501 which it would be nice to find a solution for. Resolving this I think will require some experimentation from whoever took it on