Adding visual line mode and repeat find motions, fixing some bugs, etc

[JustBobinAround]

Hi,

I'm currently working on a personal fork of evil-helix that hopefully will closely match my current neovim setup. I don't plan to make that a PR as I think it will go outside the scope of the evil-helix project being a soft fork. With that said, I plan on trying to maintain a branch with features that I think would benefit evil-helix and are in scope. I know this is a fairly large PR, so if you'd only like certain features, let me know and I'll make a cherry-picked branch.

Overall issues fixed

• The keymap! macro that was created to map keys to functions in helix-term/src/keymap/default.rs was not correct. This is really an upstream issue with helix itself, but it probably wouldn't hurt to add. This fix allows for chaining of commands in an array like format. This is great for iterating on experimental configs before combining a motion into a single function. See fixing macro bug I found commit.
• When in visual mode, if a user selects two words moving forward, i.e. pressing ee, and then presses b once, the last word is selected and the head and anchor flip positions. If the expected behavior is to act like vim, then the selection head should simply move back one word. The anchor should remain in the same spot no matter the motion. See fixing visual mode move_impl bug commit.
• When in visual mode, if a user attempts to extend to char using find_char operations, the selection is not extended. This has been fixed in commit fixing how find works with selections.
• When in visual mode, if a user attempts to paste from the normal yank register on a selected item, the selected item will persist and the pasted item will be appended after the selection. In vim, this would replace the selection with the pasted item. This was fixed in making visual paste replace like vim.

Features being added

Visual line mode, i.e. V, is now possible in evil-helix.

In vim, visual line mode functions more like a range and a cursor. This is not really possible with the way helix is currently setup. However, the middle cursor is mostly useless in vim anyways and is most likely just a byproduct of how visual line mode was implemented. With this in mind, the visual line mode implementation for evil-helix simply does not include the cursor and coerces the selection range to always be at the start and ends of lines. There is an edge case in this implementation to be aware of:

• This implementation is not perfectly alike to vim as motions outside of j and k will send evil-helix back into plain select mode. This was done purposefully to avoid having to overhaul a variety of command functions which could make merging upstream helix updates difficult.

Commits involving visual line mode implementation:

• adding visual line mode
• account for visual line exit cases

Find motions are now repeatable with ;

Currently there is not a way to repeat a find char motion in evil-helix. For example, if a user wanted to find the second "t" in the string "a test". They would currently have to press ftft. In vim, a user can enter a find motion once, e.g. ft, and then repeat the motion as many times as they want by pressing ;. This has been implemented in the following commits:

• adding repeat find motion ie ;
• fixing how find works with selections

Majority of vim delete motions are now implemented

This section of the adding dd dh dj dk dl etc commit should explain what was implemented:

        "d" => { "Delete"
            "d" => evil_del_current_line,
            "h" => evil_del_char_left,
            "l" => evil_del_char_right,
            "j" => evil_del_two_lines_down,
            "k" => evil_del_two_lines_up,
            "b" => evil_del_prev_word_start,
            "e" => evil_del_next_word_end,
            "w" => evil_del_next_word_start,
            "B" => evil_del_prev_long_word_start,
            "E" => evil_del_next_long_word_end,
            "W" => evil_del_next_long_word_start,
            "0" => evil_del_line_start,
            "$" => evil_del_line_end,
        },

[usagi-flow]

This is amazing! Thank you so much and apologies for replying just now. I'll be going through it in the new few days!

[usagi-flow]

Thanks again for your PR! I finally had a closer look at it, especially the visual line mode, since I wanted to merge at least that feature.

However, I see the issue that it's working a bit differently compared to Vim: When entering, the cursor jumps to the end of line, and when moving it within a line (e.g. with b and w), we lose the line selection.

Another little issue that could become a source of trouble later on is the various modifications to code outside of evil.rs. Although I admit that sometimes it's hard to avoid.

Ideally, some clarity on how upstream helix plans to implement the upcoming plugin system would be great. I could imagine bypassing the scripting engine, but using the same hooks to forward calls to evil.rs.

I'm open for any ideas/suggestions.

[JustBobinAround]

There is definitely a lot of room for improvement. I've been testing this fork as a daily driver at work and there is plenty of things to fix. I'll add the b/w issue to my list. My main issue currently is G and gg not working in line selection. I use that a lot to copy and paste between my editor and web browser.

As for mitigating merge conflicts in the future, I have been exploring a few different ways on how to deal with the issue. So far my current thought has been to create a series of proc macros and/or modifying build.rs so that wrapper functions pointing to evil.rs would be added at compile time instead of being held in helix's main code. If that was possible, most other files would only require 1-2 lines of extra code. This would make merging with upstream helix for updates much easier. I'll admit I haven't made much headway on the idea as of yet because I've been tied up with work. In addition to that, helix's file structure is a bit of a mess and so its hard to avoid circular dependencies when trying to compartmentalize everything to evil.rs.

I'll have to read more on the upcoming plugin system. I haven't had a chance to look at how that works as of yet. I do think that would be a good route to take if it is possible.

Hopefully this weekend I will have some free time to make a new branch for a revised version of visual line mode. I will keep you posted.