feat: new cmdline (local to editor view)

gikari commented 1 year ago

Summary

This creates Neovim command line inside the editor, instead of occupying Qt Creator search bar. This is an enhancement, because:

This makes it more prominent and easier to notice (the cmd lines spawns inside the split we are currently viewing).
We could write longer lines for commands.
We could now see full messages Neovim prints. If there is not enough place, we can scroll the message.

Notes

I found some strange behavior when closing splits, but it existed before my change.
When you start typing the text in the command line, but then change focus using mouse to editor, your cursor is forced to be in the command line, but the editor highlights behave strangely. I am not sure how this behavior should be handled, because in Neovim, when you click the mouse, nothing really changes: you could only select text in the splits, but command line stays active. Should we do the same thing, or should we discard the command line and bring the focus to the editor, that was clicked on?

Test Plan

Press :, / or ? and try to use some neovim command. It should work.
Try to move cursor inside command line. It should work.
Try to print message in the command line, e.g. using an incorrect command.
Try to print multiline message in the command line using :history or echo "something\n\n\n\n\nsomething".
Find other ways to break the command line.

Closes #56

sassanh commented 1 year ago

Thanks! I tried it on my machine and it looks very nice, but I need more time to review the code.

I found some strange behavior when closing splits, but it existed before my change.

Externalizing UI has improved a lot these years, if we drop neovim-qt and upgrade to the latest API we should be able to drop lots of hacks we currently have in the codebase and drop the complexity and improve the stability for a wide range of use cases. Using ext_windows and ext_multigrid for example should resolve issues with splits, etc. I say let's wait for libneovim to be stable and then we plan to refactor our codebase.

When you start typing the text in the command line, but then change focus using mouse to editor, your cursor is forced to be in the command line, but the editor highlights behave strangely. I am not sure how this behavior should be handled, because in Neovim, when you click the mouse, nothing really changes: you could only select text in the splits, but command line stays active. Should we do the same thing, or should we discard the command line and bring the focus to the editor, that was clicked on?

I think we better stick to Neovim behavior whenever possible. Generally speaking people using this plugin probably are satisfied with Neovim user experience and are used to it and prefer to stick with it whenever possible. For example all Vim users know clicking mouse anywhere when cmdline-mode is active won't change anything, now if we change this behavior one may get surprised to see all he has typed blindly were inserting in the buffer instead of being typed in the cmdline just cause his fingered touched his mousepad accidentally. So I think there is value in being consistent with Neovim user experience.

gikari commented 1 year ago

I think we better stick to Neovim behavior whenever possible. Generally speaking people using this plugin probably are satisfied with Neovim user experience and are used to it and prefer to stick with it whenever possible. For example all Vim users know clicking mouse anywhere when cmdline-mode is active won't change anything, now if we change this behavior one may get surprised to see all he has typed blindly were inserting in the buffer instead of being typed in the cmdline just cause his fingered touched his mousepad accidentally. So I think there is value in being consistent with Neovim user experience.

I figured out a way to block the editors interaction with the mouse during command line editing, but I am not sure if it is possible to let the user select text in the buffer. Futhermore, the user can still open a file/split using GUI, which you could not do in Neovim. Should we block this functionality as well?

gikari commented 1 year ago

Externalizing UI has improved a lot these years, if we drop neovim-qt and upgrade to the latest API we should be able to drop lots of hacks we currently have in the codebase and drop the complexity and improve the stability for a wide range of use cases. Using ext_windows and ext_multigrid for example should resolve issues with splits, etc. I say let's wait for libneovim to be stable and then we plan to refactor our codebase.

ext_multigrid

I see, that in the code, we already pass an ext_multigrid option and neovim-qt sends us a multigrid events such as win_viewport and grid_line (for some reason very rapidly, there might be a bug somewhere). Is it possible to utilize that?

If I am not mistaken, ext_windows is in a stage of pull request for neovim currently?

sassanh commented 1 year ago

I figured out a way to block the editors interaction with the mouse during command line editing, but I am not sure if it is possible to let the user select text in the buffer. Futhermore, the user can still open a file/split using GUI, which you could not do in Neovim. Should we block this functionality as well?

I don't think we should block anything (even mouse interaction) I just think it would be better to stick with Neovim user experience. If we accidentally get extra features it's good. So I think it's good that interacting with mouse doesn't discard cmdline (Neovim behavior kept, so users will feel at home), I'm also happy interacting with mouse is possible (extra features, if someone accidentally interacts with the mouse and copies some text from the buffer by mouse, good for them.)

Regarding opening a file/split using GUI, I think it's ok, we don't need to block or manipulate anything. Ideally we should just report it to Neovim and let Neovim instance decide what to do in this situation. If Neovim ignores it or if it opens the window/split while keeping the user in cmdline or if Neovim opens the window/split and discards cmdline, it's all good. If Neovim crashes, then it's bad and we will report a bug in Neovim repository. I say let the Neovim team think about such issues, as they are designing the external user interface and its behavior, if something goes wrong we fix it in Neovim, not in qnvim.

The thing is clicking on "new window"/"new split" button in an IDE/editor while editing cmdline is not something special with qnvim, it can happen in VSCode, JetBrains, Sublime or any other IDE/editor, so for the sake of consistency and avoiding duplications we better decide about it in Neovim.

Sorry for the long post, I tried to explain how I understand this issue.

sassanh commented 1 year ago

I see, that in the code, we already pass an ext_multigrid option and neovim-qt sends us a multigrid events such as win_viewport and grid_line (for some reason very rapidly, there might be a bug somewhere). Is it possible to utilize that?

If I am not mistaken, ext_windows is in a stage of pull request for neovim currently?

Sorry, I forgot we already use ext_multigrid.

My knowledge about new Neovim api is poor, so I can't brainstorm with you about it. I'm willing to learn about it once libnvim is out and stable and we can easily and directly communicate with Neovim instance with a third party library. It's beyond the scope of this pull request anyway. I think the user experience of cmdline in this pull request is already very good.

sassanh commented 1 year ago

Relevant: https://github.com/neovim/neovim/issues/21693

sassanh commented 1 year ago

Sorry, this PR got closed automatically when I merged qtc-6 to master, kindly reopen it when you got the time.

sassanh / qnvim