BUG: Renaming when using alternative keyboard layout transliterates the name of the file into the layout about neo-tree.nvim

[gerazov]

Hey guys - sorry for the silence - I haven't had the time to read through your discussion till today.

Yes the issue was that the filenames was transliterated to the keymap setting and you've fixed it - I've updated to MunifTanjim/nui.nvim@fbb139c and it works!

🙏 thanks a million!

[MunifTanjim]

Hello... This could be something that nui.nvim never handled, because nobody reported it... or could be an upstream neovim issue. We need to be able to reproduce it for being sure where the issue is.

[MunifTanjim]

Ah man 🤣 damn! I completely forgot about that. Thanks so much for bringing that up. I'll do some more testing before merging this.

It should also have unit tests... last time I tried to add unit test for this, I failed. I'll try to do that again.

[pysan3]

If I'm not mistaken, this should be a nui issue (an underlying library we rely on).

Could you give us your insights @MunifTanjim ?

I am terribly sorry for pinging you if I was wrong.

[pysan3]

@gerazov Unfortunately I'm not able to reproduce your problem (since I don't know Cyrilics...).

Could you copy your setup into the following code and see if the problem is reproducable?

Save this code into any file (like repro.lua) and then :source repro.lua inside neovim. You should see an input popup near your cursor.

If this code doesn't reproduce the issue, could you still send me list of options you set that might be affecting the issue? (I'm using manjaro as well, so no need to reproduce it on other OS.)

local Input = require("nui.input")

--   ─────────────────────────────── Change lmap ───────────────────────────────
-- Please set your iminsert, langmap, keymap etc settings that might be relevant.
vim.cmd([[
" set iminsert=0
" set iminsert=1
" set langmap=zy,yz,ZY,YZ
]])
-- or using lua
-- vim.opt...

-- please paste some default input value that will be affected.
local default_value = "zyZY"
--   ─────────────────────────────── Change lmap ───────────────────────────────

local popup_options = {
  relative = "cursor",
  position = {
    row = 1,
    col = 0,
  },
  size = 20,
  border = {
    style = "rounded",
    text = {
      top = "[Input]",
      top_align = "left",
    },
  },
  win_options = {
    winhighlight = "Normal:Normal",
  },
}

local input = Input(popup_options, {
  prompt = "> ",
  default_value = default_value,
  on_close = function()
    print("Input closed!")
  end,
  on_submit = function(value)
    print("Value submitted: ", value)
  end,
  on_change = function(value)
    print("Value changed: ", value)
  end,
})

input:mount()

[MunifTanjim]

When you set vim.opt.iminsert = 1, it sets that option globally. So when you open a new float/split, that float/split will also have iminsert=1. This is how neovim behaves.

If you only want to set iminsert = 1 locally for a specific buffer, do vim.opt_local.iminsert = 1 or :setlocal iminsert=1.

[MunifTanjim]

I'm not sure if nui.nvim can have a patch for this. It might make sense for a file tree plugin to always have iminsert=0 for its popup... but different behavior can be desired in a different use-case.

If neo-tree decides it should always be iminsert=0, it can use the buf_options to do that: https://github.com/MunifTanjim/nui.nvim/blob/main/lua/nui/popup/README.md#buf_options

[pysan3]

@MunifTanjim I think this is caused because you pass "t" as the second argument to nvim_feedkeys here.

https://github.com/MunifTanjim/nui.nvim/blob/b81333d12f824dbed5eb231c8a4409a290fdd848/lua/nui/input/init.lua#L97

I'm not actually sure what quirks will happen but I think you can temporary set iminsert to 0 before feeding the keys and then setting it back to the old value right after that.

If I understand correctly, this should type the default_value as-is into the buffer, and swtich back to user's input method layout right after that.

[MunifTanjim]

Oh, I didn't realize it's happening for default_value. I thought we're talking about when user is typing.

If the suggested fix solves the issue, it should definitely be merged into nui.nvim.

I still can't reproduce it myself. So I can't really verify if the solution works.

[pysan3]

Oh, I thought OP was talking about the default value being translated to cyrilics letters. And I couldn't reproduce it as well: #1370 (comment).

Did you type the new name yourself @gerazov , and requesting neo-tree to default to english keyboard in input fields?

[MunifTanjim]

Nevermind, I reproduced it.

• Do :set keymap=greek_utf-8
• Open neo-tree
• Open rename popup

@pysan3 can you verify that MunifTanjim/nui.nvim#347 solves it?

[pysan3]

I'm currently not on my PC so please wait a day or so

I remember "t" was chosen to solve this issue. MunifTanjim/nui.nvim#257

Does your change not bring this issue again?

[MunifTanjim]

So, MunifTanjim/nui.nvim#257 was caused because of "n", false. MunifTanjim/nui.nvim#258 changed it to "t", true.

And this issue is caused because of "t".

Looks like

vim.api.nvim_feedkeys(self._.default_value, "n", true)

solves both issues.

[pysan3]

Glad to hear that.

TBH I don't know how nvim_feedkeys works and cannot understand the difference between those options :kekw:.

I've tested your PR branch (and also was able to reproduce the issue with the main branch) and can confirm that your fix does solve the issue.

Thanks a lot on working on it!

[pysan3]

Problem will be dealt upstream.

Closing on our end.
Please ping me again if this fix does not solve the problem @gerazov .
I hope I can hear from you again as it was difficult to iron out the problem without your interaction.

• MunifTanjim/nui.nvim#347