Expose private APIs H

[drowning-cat]

It would be great to have access to Mini*.H to partially override internal APIs.
No documentation, no warranty—just simple exposure. This would allow for tweaking minis without the need to clone the repository.

Warning

A potential downside is that exposing internal APIs might lead to more Issues and Pull Requests.

What I am trying to do

{
  'echasnovski/mini.clue',
  lazy = false,
  init = function()
    vim.api.nvim_create_autocmd('FileType', {
      pattern = 'snacks_*',
      callback = function(event)
        MiniClue.enable_buf_triggers(event.buf)
      end,
    })
  end,
  config = function()
    local clues, triggers = {}, {}

    local reg = function(mode, lhs_tbl, rhs, opts)
      local prefix, keys = lhs_tbl[1], table.concat(lhs_tbl)
      vim.keymap.set(mode, keys, rhs, opts)
      table.insert(clues, { mode = mode, keys = keys, postkeys = prefix })
    end

    for _, prefix in ipairs { '<C-w><C-r>' } do
      table.insert(triggers, { mode = 'n', keys = prefix })
      -- stylua: ignore start
      reg('n', { prefix, 'h' }, function() wins.resize 'h' end, { desc = 'Resize left' })
      reg('n', { prefix, 'j' }, function() wins.resize 'j' end, { desc = 'Resize down' })
      reg('n', { prefix, 'k' }, function() wins.resize 'k' end, { desc = 'Resize up' })
      reg('n', { prefix, 'l' }, function() wins.resize 'l' end, { desc = 'Resize right' })
    end

    local miniclue = require 'mini.clue'

    local H = miniclue.H

    H.exit_chars = { '<Esc>', 'q', '' }
    ---@diagnostic disable-next-line: duplicate-set-field
    H.getcharstr = function()
      H.timers.getcharstr:start(0, 50, H.redraw_scheduled)
      local ok, char = pcall(vim.fn.getcharstr)
      H.timers.getcharstr:stop()
      if not ok then
        return
      end
      for _, ch in ipairs(H.exit_chars) do
        if char == H.replace_termcodes(ch) then
          return
        end
      end
      return H.get_langmap()[char] or char
    end

    miniclue.setup {
      triggers = triggers,
      clues = clues,
    }
  end,
},

No need to respond, you can simply close the discussion if it is not planned.

[echasnovski]

Yes, it is not planned. Those are private methods that explicitly kept not exported.

What I am trying to do

Can you please describe what you want to have and why? I.e. the actual use case and desired behavior.

[drowning-cat]

Thanks again for your work and your help—really appreciated it.

[drowning-cat]

@echasnovski

Oh, and [<C-S-j>, <S-C-j>], [<C-M-j>, <M-C-j>] are also messed up.
It's not a big deal, though.

<C-S-j>, <S-C-j>	<C-M-j>, <M-C-j>

[echasnovski]

Thanks! I am still not entirely sure that mapping those key combinations is possible in terminal emulator, but I'll fix it (soon) anyway.

[drowning-cat]

Depends on the terminal. As far as I understand, xterm didn't support it initially, but the Kitty introduced a keys protocol that allows such behavior. It is supported by various terminals out of the box, e.g. kitty, ghostty, wezterm.

See https://sw.kovidgoyal.net/kitty/keyboard-protocol for more information.

These keys even work in tmux with set -g extended-keys on (terminal should support the protocol).

Alacritty supports the Kitty keyboard protocol partially. Such mappings need to be configured manually to send distinct key sequences. While applications can request a mode with extended key support, these key sequences are not sent by default for this terminal.

Kitty output:

[echasnovski]

Thanks! I am still not entirely sure that mapping those key combinations is possible in terminal emulator, but I'll fix it (soon) anyway.

Should now be fixed on latest main.