Deleting sessions with fzf-lua

[shushtain]

Thanks for adding support for fzf-lua! I've switched from Telescope only yesterday and can't make delete_session work.

Is there a default mapping? If so, is it tied to default fzf-lua actions/keymaps? Because I don't have explicit <C-x> set to any action there besides default, scoped keymaps that fzf-lua creates on its own.

If I want to manually add a mapping, will it work with fzf-lua? And what do I put in {modes}? fzf-lua puts me in terminal mode when invoking vim.ui.select(), so is it t or still i in this context?

What is meant by delete highlighted? Do I need to select it with <Tab>, or highlighted is just the current line, like it used to work in Telescope?

Thanks in advance!

[cameronr]

ctrl-d is the default delete session keymap

Can you send a screenshot of what it looks like for you? It should show the keymaps by the input field like this:

But if it can't load fzf for some reason, it'll fall back to vim.ui.select and I'm wondering if that's what's happening. I'll add some checking to that code in a bit.

For fzf, it doesn't use the mode field at all so you can just put "i". The session fzf picker has multi-select disabled, so you should just be able to have the session highlighted and press the delete keymap and it should delete the session.

[cameronr]

Hmm, interesting. With only those keymaps in a config, these are the only maps reported by map

n  A           * A4<Esc>
n  a           * A1<Esc>
n  <M-C-S-A>   * A16<Esc>
n  <M-C-A>     * A14<Esc>
n  <C-S-A>     * A12<Esc>
n  <C-A>       * A10<Esc>
n  <M-A>       * A8<Esc>
n  <M-a>       * A5<Esc>

So 1,2,5,8,10,12,14,16 are the only possible values to be displayed.

In wezterm, I can't ever get A12 or A14. I even downloaded alacritty and still can't get A12 but maybe there's a config that enables it in some way?

On shift taking priority, the last keymap will win so what happens if you reverse the order:

vim.keymap.set("n", "<S-A>", "A4<Esc>")
vim.keymap.set("n", "<S-a>", "A3<Esc>")
vim.keymap.set("n", "A", "A2<Esc>")
vim.keymap.set("n", "a", "A1<Esc>")

vim.keymap.set("n", "<M-S-A>", "A8<Esc>")
vim.keymap.set("n", "<M-S-a>", "A7<Esc>")
vim.keymap.set("n", "<M-A>", "A6<Esc>")
vim.keymap.set("n", "<M-a>", "A5<Esc>")

vim.keymap.set("n", "<C-S-A>", "A12<Esc>")
vim.keymap.set("n", "<C-S-a>", "A11<Esc>")
vim.keymap.set("n", "<C-A>", "A10<Esc>")
vim.keymap.set("n", "<C-a>", "A9<Esc>")

vim.keymap.set("n", "<C-M-S-A>", "A16<Esc>")
vim.keymap.set("n", "<C-M-S-a>", "A15<Esc>")
vim.keymap.set("n", "<C-M-A>", "A14<Esc>")
vim.keymap.set("n", "<C-M-a>", "A13<Esc>")

That turns into these maps:

n  A           * A2<Esc>
n  a           * A1<Esc>
n  <M-C-A>     * A13<Esc>
n  <M-C-S-A>   * A15<Esc>
n  <C-A>       * A9<Esc>
n  <C-S-A>     * A11<Esc>
n  <M-a>       * A5<Esc>
n  <M-A>       * A6<Esc>

With those, I'm not able to get A15 or A11. Do you see something different?

[shushtain]

M-C-S is actually a good order to memorize them by priority. I should start using it.

I have no idea why support for <C-S-A> is different but its code in the terminal prompt is the same for <C-a>. And yet, most terminals DO know the difference for some characters. I mean, there are: Ctrl+V, Ctrl+Shift+V, Ctrl+C, Ctrl+Shift+C - and (for Alacritty) also: Ctrl+Shift+Space (Vi mode), Ctrl+Shift+O (regex hints), Ctrl+Shift+F (search).

So there is definitely some adjustment to what Neovim recognizes. I'm on stable build, btw. While fresh Alacritty install prevents key blocking issues by tmux and stuff, there are still global OS keymaps, Wayland?, Arch package build quirks, untracked default bindings from plugins, later overrides of some sort (increment number and such), etc.

While I think it's user's responsibility to choose tools that provide desired capabilities, what I'm mainly concerned about, is that a person new to this notation could be confused by sensitive D and <M-D> but insensitive <C-D>.

I knew about <S- and I still made mistakes with omitting it for <C-. So I would personally still use lowercase where what user types is lowercase, and vice versa. To my eye, <C-S> for <C-s> looks even less intuitive than <C-S-s> (latter is saved by the fact that uppercase could [by choice] be reserved for special keys only).

<M-d>; <M-D>; <C-D> (but actually <C-d>) is harder to scan in sequence. While the way of writing where Ctrl+V != Ctrl+Shift+V is true for many programs, that notation is generally more intuitive. And the whole thing with each modifier acting differently puts that responsibility on us, I think.

But ultimately it's up to you. People will learn eventually, just as I did, over these few hours :)

[shushtain]

About Shift taking priority, I get the same thing. Just to be clear, I did not mean to say that a keymap with <S-a> is always prioritized over A in my client. It's just runtime flow, I think. What I meant is that modifiers treat letters differently, but explicit Shift always wins over Ctrl, while Ctrl wins over Alt, and Alt is pass-through (all in terms of modifying the casing of the final letter within the same keymap).

[cameronr]

The terminal program can recognize shift because it's reading the keyboard. The problem is that there isn't a standard way to send shift for control codes:

https://www.reddit.com/r/linuxquestions/comments/3ciful/eli5_how_does_a_terminal_emulator_work/

This is a surprisingly good AI summary of how it works:

Terminal emulators can send Ctrl+Shift+A to a shell, but it's more complex than simple key combinations due to how terminal communication works.

The Challenge: Traditional terminal protocols (like the basic ASCII control codes) don't have standard representations for modified keys like Ctrl+Shift+A. The original TTY system only defined control characters for Ctrl+letter combinations (like Ctrl+A = ASCII 1).

How Modern Terminal Emulators Handle It:

Escape Sequences: Most modern terminal emulators use escape sequences to encode complex key combinations. For example, they might send something like:

\e[1;6;65~

Where the numbers encode the modifiers (Shift, Ctrl) and the key code.
Extended Protocols: Some terminals support extended protocols like:
    CSI u encoding: A more systematic way to encode any key with modifiers
    Kitty keyboard protocol: An even more comprehensive system
    iTerm2's proprietary sequences

What the Shell Sees: The shell receives these escape sequences as strings and must interpret them. However, many shells (like bash) don't have built-in handling for arbitrary modified keys by default - they primarily recognize the traditional control characters and some common escape sequences.

Since neovim supports S mappings, it seems like it must do some extra processing (probably recognizing the escape sequences).

On format, I see the case for making them lowercase. I'll think about it.

[shushtain]

While I know for sure that Alacritty didn't implement all escape sequences from kitty, both WezTerm and Alacritty seem to implement the part about comprehensive keyboard handling.

:h tui-input says it will advertise handling of modifyOtherKeys (xTerm) and CSI u, but Alacritty planned to implement kitty's protocol instead of xTerm's.

It also states that Neovim will read terminfo based on $TERM, so maybe it helps that the first terminal my system was built on is kitty (if I even have .terminfo sowewhere), or that my current $TERM is alacritty.

At the end of the day, it's good to know that Ctrl+Shift+... are not safe to choose for plugin defaults. I didn't know that before, and will keep in mind.