Add Vim mode

[vkbo]

Discussed in #2027

^{Originally posted by idealemu September 21, 2024}
Hi,

How hard would it be to implement a "vim mode" for basic movements in the editor ? I know quite a few open source projects have this feature, or a plugin that enables it, we could look at for inspiration. Since the idea is mainly relevant for editing, IMHO, perhaps this could also be achieved by 'just' having a feature to open the current file in an external editor ?

I already do this by going into the filesystem and opening the corresponding file if I have specific changes I know are easier to make with vim, but since the files are named for the database it is a slightly cumbersome workflow at the moment.

[idealemu]

Basic proof of concept is available here.

Currently it fails 4 tests, but basic vim motions and switching from normal mode to insert mode work.

Future plans:

• Fixing tests, and adding new tests where required (to discuss)
• More vim basic commands as described in #2027
• Cursor type change in normal mode
• Basic visual mode
• Option to actually enable vim mode in settings (currently hardcoded)

[vkbo]

Sounds good. A few structure and style notes that I will suggest later on:

• I think it's better to keep the Vim state local to the GuiDocEditor class and keep it out og GuiMain. There is only one editor, and I expect there isn't anything else the Vim Mode should affect?
• With the above in mind, the enum and class should be in the editor source file fi they are local to the editor. If the enum is needed multiple places, it should be in the enum.py file.

Future plans:

• Option to actually enable vim mode in settings (currently hardcoded)

You can hardcode a flag in the Config class right away, and expose the setting later when the functionality is in place. It's usually how I add new configurable features too. The user's Config instance (singleton) is available from the package root as CONFIG, so should be easy to access.

[Survivian]

Because of a different program I used to use for my writing (QOwnNotes), I know that there's a plugin for PyQt that allows for most conventional VIM movements.

https://github.com/hluk/FakeVim

And after using QOwnNotes for so long, I can confirm that it does most of what a non-power user would need for basic text editing (as I'm not a power user lol). I'm not sure how easy the implementation would be, but the option is there without having to make something in-house.

Or, as the issue text states, it could be used as inspiration to take only what is necessary for NW. Not sure. But I at least wanted to post a direct link to the Qt plugin in question in case it would help.

[vkbo]

Yeah, I'm not adding any external dependencies if I can avoid it. Certainly not unmaintained hobby projects. I have been burned by that before. That's why novelWriter only has one core dependency (PyQt) and one optional (Enchant). I'd like to keep it that way. I'm not a fan of the "reuse before buy before build" approach! 😄

[Survivian]

Understandable LOL.

I hope that maybe it can at least provide an idea for how to handle the more advanced operations. Even if it's old and unmaintained, it works well enough without breaking for at least that much.

[vkbo]

Yeah, that's true. It's useful to look at other implementations for ideas. I also did that for my Bluray subtitle edit app, but the code I looked at was a bit weird, so I ended up writing my own anyway.

[idealemu]

I know that there's a plugin for PyQt that allows for most conventional VIM movements.
https://github.com/hluk/FakeVim

It's written in c++ so trying to convert the main parts to python might actually be more work for me than writing it from scratch, but I might take a look at it for some inspiration 👍

[xahodo]

Would we get vim's undo/redo functionality as well?

It's basically a tree structure (with possibly more than two branches per node) for the undo/redo information, as opposed to a linear structure.

If it's not applicable to this topic, I'm willing to make a separate feature request.

[vkbo]

The undo/redo structure is built-in into the editor's underlying document and is linear in history. It cannot do what you describe.

[idealemu]

I can confirm that I just intend to map the editor's built in undo/redo system to some vim keys and that's it, in my opinion it should also stay consistent how you use NovelWriter whether in vim mode or not.

[vkbo]

Basic proof of concept is available here.

One more thing I just spotted. All variables and functions must use camelCase. The source is all camelCase because the Qt library is, so it matches to be consistent.

[idealemu]

Small update:
Normal mode hjkl motions, and dd to delete current line both work ! Insert mode works as well, and switching between normal mode and insert mode is functional !

All tests pass, except:
FAILED tests/test_gui/test_gui_theme.py::testGuiTheme_LoadIcons - assert 100 == 50
Since I know very little about the existing tests I look it up and asked an LLM and it would seem that it is due to "the test fails because the QPixmap returned by iconCache.getPixmap("add", (50, 50)) is 100×100 pixels instead of the expected 50×50.
That happens on HiDPI screens: Qt automatically doubles the pixel size, but the logical size (as reported by width() / height()) is the original one."

[vkbo]

Yes, this behaviour changed between Qt5 and Qt6. The app now scales to display factor automatically. Before novelWriter 2.7 it was done manually in the code. The LLM is partially correct, but not quite.

Anyway, you can set QT_SCALE_FACTOR=1 to run the tests on 1.0 scale. You may also want to set QT_QPA_PLATFORM=offscreen to avoid the GUI showing when running tests.

I can add the scale factor flag to the run_tests.py script for convenience.