send alt-x keycodes to vim.fn.chansend()

[rish987]

Problem

I've been tinkering around with nested neovim instances and sending pre-recorded keystrokes to them with vim.fn.feedkeys. In order to allow me to send these keys without having to have the nested sessions open in a terminal as my current window, I've been trying to transition my code to use vim.fn.chansend instead. But it doesn't seem to have the same effect when sending alt-modified keycodes.

Steps to reproduce

Execute the following script, "hello" is not printed as expected:

map = "<A-x>"
job_id = vim.fn.termopen("nvim --cmd 'map " .. map .. " :echo \"hello\"<CR>'")
vim.defer_fn(function()
  vim.fn.chansend(job_id, vim.api.nvim_replace_termcodes(map, true, true, true))
end, 500)

Expected behavior

The mapping in the nested instance should execute and "hello" should be printed, as it does when we use feedkeys:

map = "<A-x>"
vim.fn.termopen("nvim --cmd 'map " .. map .. " :echo \"hello\"<CR>'")
vim.defer_fn(function()
  vim.fn.feedkeys("i" .. vim.api.nvim_replace_termcodes(map, true, true, true))
end, 500)

or when we use a different mapping:

map = "<C-q>"
job_id = vim.fn.termopen("nvim --cmd 'map " .. map .. " :echo \"hello\"<CR>'")
vim.defer_fn(function()
  vim.fn.chansend(job_id, vim.api.nvim_replace_termcodes(map, true, true, true))
end, 500)

Neovim version (nvim -v)

NVIM v0.10.0

Vim (not Nvim) behaves the same?

N/A

Operating system/version

Ubuntu 22.04.3

Terminal name/version

Alacritty 0.13.1

$TERM environment variable

xterm-256color

Installation

build from repo

[rish987]

Actually, considering that the chansend function is probably fairly simple and just sends bytes to the child process, I'm not sure if this is a bug rather than a misuse of vim.api.nvim_replace_termcodes() on my part. Do you know if there is a different function I should be using?

[zeertzjq]

This sounds more like a feature request than a bug report.

[justinmk]

:help nvim_replace_termcodes() mentions:

Replaces terminal codes and |keycodes| in a string with the internal representation.

chansend() expects the "external" input, not the "internal representation". The external form of <A-x> would be ESC x.

[rish987]

Okay, so it seems that what might be lacking here is a vim.api.nvim_replace_termcodes()-like function for getting the external, rather than internal form? Or perhaps one to go from internal to external (which would be more useful in my case as I'm originally getting my keys from recorded macros in registers, where they have an internal representation)?

For the record, I've managed to work around this using an RPC session which calls vim.api.feedkeys() on the side of the nested instance:

map = "<A-x>"
job_id = vim.fn.termopen("nvim --cmd 'map " .. map .. " :echo \"hello\"<CR>' --listen /tmp/exnvimsock")
vim.defer_fn(function()
  local sock = vim.fn.sockconnect("pipe", "/tmp/exnvimsock", {rpc = true})
  vim.fn.rpcrequest(sock, "nvim_exec_lua",
    "vim.fn.feedkeys(vim.api.nvim_replace_termcodes(..., true, true, true))", {map})
end, 500)

But obviously that's not a completely general solution (unless you're willing to always execute your automated terminal sessions through an extra layer of nvim).

[justinmk]

I assume you are using termopen() because you want to see the UI of the nested nvim in a buffer. The :terminal buffer will have :help $NVIM env var set, so the child Nvim can open a channel to the parent, and call a function in the parent which adds the channel to a list. Then from the parent, you can call RPC functions such as nvim_input on the child.

Thus there is no need to send raw bytes via chansend().

Alternatively if you don't need to see the nested Nvim in a :terminal...

• you can start it with nvim --embed, from jobstart(), which will return the RPC channel.
• you can still view the UI by connecting to the headless, nested nvim via --remote-ui