[Feature Request] Allow mappings in insert mode

[IroncladDev]

It would be nice if you could add mappings to the search input for insert mode, similarly to how telescope does it

                mappings = {
                    i = {
                        ["<A-BS>"] = function()
                            vim.api.nvim_input("<C-w>")
                        end
                    }
                },

In my case, I would like to remap <A-BS> (alt-backspace) to input <C-w>

[zbyju]

I would also really like this feature; on Mac when I do Cmd+j / Cmd+k I would type ∆ / ˚ which I then map to moving up and down. The issue is that with fff I can't use that keybind because it starts searching for ∆ or ˚ instead of moving up or down.

[gustav-fff]

[triage-bot] FEATURE REQUEST: acknowledged.

Current config exposes named-action keymaps only (`lua/fff/conf.lua:240`), no arbitrary user-defined callbacks per mode like telescope's `mappings.i`. Plumbing this would touch `picker_ui.lua:1100` keymap registration to merge user-supplied `{ i = { [lhs] = fn } }` table on top of built-ins.

Scope decision left to @dmtrKovalenko. Not implementing speculatively.

Workaround for @zbyju: remap at OS / terminal level so `Cmd+j` sends `` directly instead of `∆`; fff already binds `` to move_down.

Honk-Honk 🪿

[IroncladDev]

thank you gustav you're the goat

[IroncladDev]

*goose, sorry

[dmtrKovalenko]

@gustav-fff the scope should be fairly small, prototype the change with the exact API from the issue and push

[gustav-fff]

[triage-bot] DIRECTED: nothing to push — you already landed it yourself.

mappings = { i = ..., n = ... } with the exact API from the issue is on main as of 896e11c (#814, merged 2026-08-24T16:01:35Z). My branch triage-bot/issue-78 is identical to origin/main, so a PR would be empty noise.

Implementation:

• lua/fff/conf.lua:330 — mappings = {} default, lua/fff/conf.lua:48 alias, sanitized at lua/fff/conf.lua:498.
• lua/fff/picker_ui/ui_creator.lua:467 — applied after built-ins on input_opts, so user lhs wins.

Verified end-to-end on nvim 0.12.4, release build of 896e11c, picker actually open:

KEYMAP_REGISTERED=true lhs=<M-BS>     # <A-BS> normalizes to <M-BS>
CALLBACK_HITS=1                        # user fn runs
LINE_AFTER_CW=[🪿 foo ]                # built-in <C-w> the fn feeds deletes prev word: "foo bar" -> "foo "
MULTIBYTE_LHS_REGISTERED=˚,∆ HITS=11   # @zbyju case works without OS-level remap

So @zbyju — drop my earlier terminal-remap workaround, just do mappings = { i = { ['∆'] = require('fff.picker_ui.picker_ui').move_down } }.

Gap: zero regression test coverage for this. One spec asserting the lhs lands on S.input_buf and overrides a built-in would stop a future keymap refactor from silently dropping it. Say the word and I push it.

Honk-Honk 🪿