Lua style

[ajvondrak]

I realize that this project has gone through some flux since its initial version as Lua generated from TypeScript, but I want to commend you on the port to plain old Lua, and for making the API a first class citizen by way of #7. 🙂 Your plugin appears to be the easiest to hack on of all the multicursor implementations I've seen for neovim:

• mg979/vim-visual-multi - vimscript, fairly rigid, mostly centered around a bunch of different key mappings that you have to remap through configs
• smoka7/multicursors.nvim - a hydra submode where (again) everything in the "multicursor mode" has to be specially mapped
• brenton-leighton/multiple-cursors.nvim - surfaces a small API through user commands, but the implementation itself still thinks about things in terms of keymaps; it works by remapping keys for every possible scenario while multiple cursors are in use (even ones as rudimentary as hjkl), which seems like quite the uphill battle versus your more general approach of just feeding keys forward as a rule, but maybe I don't fully appreciate the intricacies of the respective implementations

At any rate, having a Lua-based API of primitive functions goes a long way to making this plugin friendlier to shape into the form I want. I'm still tinkering with it, but it's quite promising!

While I was bashing away, I kept being distracted by a minor style thing. I'm no Lua expert, but I'm used to seeing snake_case rather than the camelCase that I assume this plugin inherited from its TS roots. For example, see the conventions used by:

• the luarocks style guide
• plugins from high-profile authors like folke/lazy.nvim and echasnovski/mini.nvim
• nvim's own naming conventions for its Lua functions

Just thought I'd drop the idea that it's perhaps worth incorporating a Lua linter/formatter stack sooner than later and settling on a fixed style (whether that means keeping the camelCase or not). Not that I've ever done this for a Lua project, so I don't know if it's the linters enforcing that or the authors themselves. 😅

Thanks for the work thus far, and happy hacking!

[jake-stewart]

Thanks.

I think the best approach is to update 1.0 branch to have snake case variations which simply wrap the camel case ones. Remove the camel case variations from a 1.1 branch. This way nothing breaks.

Three downsides:

1. Users have to update their configs if they want to update to 1.1.
2. More work releasing bug fixes since I have two branches.
3. Users on 1.0 who print a cursor will see a metatable of duplicate functions.

Consistency is nice, but is it worth the hassle?