Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(editing-support): add cutlass-nvim #174

Merged
merged 3 commits into from
May 1, 2023
Merged

Conversation

owittek
Copy link
Member

@owittek owittek commented May 1, 2023

No description provided.

Copy link
Member

@mehalter mehalter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new list_insert_unique syntax

Copy link
Member

@mehalter mehalter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotta get them style points 👀

Copy link
Member

@mehalter mehalter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mehalter mehalter merged commit c39ae53 into AstroNvim:main May 1, 2023
@utkarshgupta137
Copy link
Contributor

utkarshgupta137 commented May 2, 2023

@owittek, is it working for you? Cutlass only works for me if I set lazy = false.

@owittek
Copy link
Member Author

owittek commented May 2, 2023

@owittek, is it working for you? Cutlass only works for me if I set lazy = false.

Yep it works for me. I've set the "User AstroFile" event to load the plugin which triggers as soon as you enter a buffer.

@utkarshgupta137
Copy link
Contributor

Maybe it's because I use neovim-session-manager to load currdir session on startup, but it doesn't work for me unless I add lazy = false.

@sebastianst
Copy link

@owittek it doesn't work for me. The d commands still save the deleted text to the yank register, as if another plugin is restoring the changes to the d bindings by cutlass. I confirmed that the plugin actually loads (with :Lazy), and the cut_key option also works and binds e.g. mm as expected. I don't have much other custom configuration. Any ideas what could be wrong?

@sebastianst
Copy link

I found the culprit: which-key. Disabling it makes cutlass work again.
See also gbprod/cutlass.nvim#20 and folke/which-key.nvim#513
However, the bug reporter there only has the issue that which-key doesn't pop up when pressing d. In my case, which-key does pop up, but cutlass just doesn't work at all. Seems like an ordering issue.

@sebastianst
Copy link

sebastianst commented Sep 11, 2023

I think I fixed it by adding

  {
    "folke/which-key.nvim",
    opts = function(_, opts)
        opts.triggers_blacklist = {
            -- list of mode / prefixes that should never be hooked by WhichKey
            -- this is mostly relevant for keymaps that start with a native binding
            i = { "j", "k", "d", "D", "s", "S" },
            v = { "j", "k", "d", "D", "s", "S", " ", "g" },
            n = { "d", "D", "s", "S", "m" },
        }
        return opts
    end,
  },

to .config/nvim/lua/user/core.lua (or any other lua file in that dir), which adds the keys that cutlass remaps to which-key's blacklist. We could add this to this community package as a quick-fix. Nicer solution would be to make cutlass upstream which-key aware.

However, there are still warnings from :checkhealth which-key:

which-key: require("which-key.health").check()

WhichKey: checking conflicting keymaps ~
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"m"**
- rhs: `d`
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"yS"**
- rhs: `<Plug>(nvim-surround-normal-line)`
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"ys"**
- rhs: `<Plug>(nvim-surround-normal)`
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"d"**
- rhs: `"_d`
- WARNING conflicting keymap exists for mode **"v"**, lhs: **"g"**
- rhs: `<C-O>"_cg`
- WARNING conflicting keymap exists for mode **"v"**, lhs: **" "**
- rhs: `<C-O>"_c `

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants