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

feature: filetype-specific Lazy-key-mappings #1076

Closed
1 task done
chrisgrieser opened this issue Oct 5, 2023 · 7 comments · Fixed by #1078
Closed
1 task done

feature: filetype-specific Lazy-key-mappings #1076

chrisgrieser opened this issue Oct 5, 2023 · 7 comments · Fixed by #1078
Labels
enhancement New feature or request

Comments

@chrisgrieser
Copy link

chrisgrieser commented Oct 5, 2023

Did you check the docs?

  • I have read all the lazy.nvim docs

Is your feature request related to a problem? Please describe.

The keys from lazy's plugin spec allows for a very concise definition of keymappings with lazy-loading. However, when it comes to filetype-specific keymaps, there is quite a bit of boilerplate:

{
	"iamcco/markdown-preview.nvim",
	lazy = true,
	init = function()
		vim.api.nvim_create_autocmd("FileType", {
			pattern = "markdown",
			callback = function()
				vim.keymap.set("n", "<C-r>", "<Plug>MarkdownPreview", { buffer = true })
			end,
		})
	end,
},

Describe the solution you'd like

Adding a ft key to the Lazy Key Mappings would remove the boilerplate and result in a much cleaner config. It should fit well with lazy's style of configuring things:

{
	"iamcco/markdown-preview.nvim",
	keys = {
		{ "<D-r>", "<Plug>MarkdownPreview", ft = "markdown" },
	},
},

Describe alternatives you've considered

As a workaround, I basically created my own small utility function. reduces boilerplate a bit, but still not a great solution, I guess.

Additional context

No response

@chrisgrieser chrisgrieser added the enhancement New feature or request label Oct 5, 2023
@folke folke closed this as completed in c42e63c Oct 5, 2023
@folke
Copy link
Owner

folke commented Oct 5, 2023

Good idea. Just added this.

@dpetka2001
Copy link
Contributor

I really like this feature. I have a sidenote question. How can you make which-key aware of the new prefix name. Example I currently have in my config

  {
    "toppair/peek.nvim",
    build = "deno task --quiet build:fast",
    keys = {
      {
        "<leader>pp",
        function()
          local peek = require("peek")
          if peek.is_open() then
            peek.close()
          else
            peek.open()
          end
        end,
        desc = "Peek (Markdown Preview)",
        ft = "markdown",
      },
    },
    opts = { theme = "dark" },
  },
  {
    "folke/which-key.nvim",
    opts = {
      defaults = {
        ["<leader>p"] = { name = "+peek" },
      },
    },
  },

which without the ft = "markdown it correctly registers the <leader>p prefix name correctly, but when ft is present in the keys section, then which-key shows when I press <leader> the following: p -> +prefix and it doesn't register correctly the which-key prefix name. Is there any work around to this?

@folke
Copy link
Owner

folke commented Oct 6, 2023

@dpetka2001 that's a bug in which-key. I think there's a PR open to fix that (by reverting another PR). Need to look at it :)

@dpetka2001
Copy link
Contributor

dpetka2001 commented Oct 6, 2023

For the moment, as a work around, I added ft = "markdown for the plugin itself and then added in the init function the following

    init = function()
      require("lazyvim.util").on_load("which-key.nvim", function()
        require("which-key").register({
          ["<leader>p"] = { name = "+peek" },
        })
      end)
    end,

which seems to do the trick for the time being, while maintaining the ft also in the keys section to only register the key when in Markdown files.

Edit: of course that snippet is Lazyvim specific, in case anyone tries to incorporate it in his own custom config with only lazy.nvim and which-key.

@MarcoBuess
Copy link

@folke Was the which-key bug ever adressed? I'm still seeing this issue.

@dpetka2001
Copy link
Contributor

As far as I'm aware, it hasn't been addressed yet. But there's a workaround for it in this issue comment until it gets resolved.

@MarcoBuess
Copy link

MarcoBuess commented Apr 10, 2024

Lets put the reference here in case anyone else comes across this: folke/which-key.nvim#514

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

Successfully merging a pull request may close this issue.

4 participants