Smarter cursor placement around inlay hints

[mydumpfire]

Cursor placement and character insertion near inlay hints currently feels a bit janky:

helix_hint.webm

This is how it looks in VS Code:

vscode_hint.webm

Neovim also deals with this pretty well:

neovim.mp4

I'm not sure what they do under the hood, but it feels like they always do the "right" thing, positioning your cursor where it makes the most sense in the current context.

[RossSmyth]

For exploration it seems this is a PR that touched it microsoft/vscode#128140
VSCode's structure is very complex for my small embedded software brain so I have no idea if there are newer PRs.

[pascalkuthe]

Our cursor semantics are fundamentally different than vscodes. Vscode has a cursor between character while we have cursors on characters. Our implementation is consistent with that behavior.

The problem is mostly that you are using bar cursor which are just a visual gimmick and don't reflect the actual cursor semantics which are always block cursor based.

[mydumpfire]

I don't think it's just a gimmick problem. For example notice how the inlay hint gets sandwiched in the middle of the currently inputted text. I don't think this should ever happen, even with block-based cursors.

Neovim is also an editor with a block-based cursor, but it doesn't have this problem at all:

neovim.mp4

Can this be re-opened as an issue?

[The-Lost-Light]

I agree that. The cursor around inlay hint looks weird.

[tp86]

I think the problem is especially visible in append mode.

In append mode cursor is NOT part of selection. Upon entering append mode it is moved one character to the right, on leaving, moved one character to left. Inlay hint just after cursor in normal mode causes cursor to be displayed after hint, while characters are inserted before hint, which is very confusing with long hints.