[vim/vim] Alt-. returns ® character in vim terminal (Issue #12191)

16 views
Skip to first unread message

Jason Gomez

unread,
Mar 23, 2023, 3:59:30 AM3/23/23
to vim/vim, Subscribed

I use the Alt+. shortcut in bash a lot and with clink it works in cmd.exe on Windows too.

But in vim for Windows and gvim for Windows, Alt+. returns ® (registered trademark symbol).

I thought it might have something to do with Clink, but the Clink develop doesn't think it hasn't anything to do with it.

I thought it may have something to do with me having a Russian keyboard setting enabled (explained in the link above), but now I have finally reinstalled Windows and the problem still persists.

This does happen in cmd.exe (with clink) in the terminal outside of vim, but it does happen in the vim for Window and gvim for Windows terminals.


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191@github.com>

D. Ben Knoble

unread,
Mar 23, 2023, 10:37:17 AM3/23/23
to vim/vim, Subscribed

What do you expect Alt-. to do? I'm not aware of any default binding on <M-.>, and checking :help supports that.

Maybe you're relying on a bit of a terminal hack that Alt-. is basically Esc then . to a terminal?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481312112@github.com>

Jason Gomez

unread,
Mar 23, 2023, 12:56:09 PM3/23/23
to vim/vim, Subscribed

It does the same as in bash (ie. pastes the last argument from the previous command) with Clink. Clink gives readline abilities to cmd.exe.

I am talking about the vim/gvim terminal, on Windows, running the cmd.exe shell with Clink.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481545306@github.com>

D. Ben Knoble

unread,
Mar 23, 2023, 1:16:47 PM3/23/23
to vim/vim, Subscribed

Ah, for some reason that [you were using Alt-. in a :terminal] wasn't clear to me from the original post; sorry for the confusion.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481578540@github.com>

Jason Gomez

unread,
Mar 23, 2023, 1:59:54 PM3/23/23
to vim/vim, Subscribed

I'm confused now, as I think I do mean the :terminal terminal, as that is how I start the vim/gvim terminal which I am talking about.😵


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481647067@github.com>

Chris Antos

unread,
Mar 23, 2023, 2:43:44 PM3/23/23
to vim/vim, Subscribed

Console input records are not being forwarded accurately to the embedded terminal window, in some cases.

Using clink echo shows the input that reaches Clink.
Using clink echo --verbose would be even better, because it will show the low level console input record(s) that reach Clink.

The console input records that reach Clink are different for Alt-. in a terminal embedded inside vim, versus in a terminal outside of vim. There's nothing Clink can do about that -- it's receiving console input records via the OS console input APIs. If the records are inaccurate, that is due to something upstream. Presumably it's due to something that happens while vim is translating and forwarding keyboard input to the embedded terminal.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481717414@github.com>

Christian Brabandt

unread,
Mar 23, 2023, 5:57:01 PM3/23/23
to vim/vim, Subscribed

I found this in :h terminal.txt:

Special keys ~
							*terminal-special-keys*
Since the terminal emulator simulates an xterm, only escape sequences that
both Vim and xterm recognize will be available in the terminal window.  If you
want to pass on other escape sequences to the job running in the terminal you
need to set up forwarding.  Example: >
	tmap <expr> <Esc>]b SendToTerm("\<Esc>]b")
	func SendToTerm(what)
	  call term_sendkeys('', a:what)
	  return ''
	endfunc

And I think I could make it work by using:

tmap <expr> ® SendToTerm("\<esc>.")

This now seems to work in a bash terminal (all on windows).

Where the ® is obtained by pressing Alt-.. I am actually surprised, that in normal gvim mode (on Windows), this character appears, even after pressing Ctrl-V. But oh well, may be this is expected on windows


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1481965905@github.com>

D. Ben Knoble

unread,
Mar 23, 2023, 7:42:58 PM3/23/23
to vim/vim, Subscribed

Similar issues appear on macOS in MacVim IIRC where the default input settings make (for example) Option-e start the composing sequence for an acute accent rather than send Meta-e.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1482053176@github.com>

Jason Gomez

unread,
Mar 23, 2023, 10:41:36 PM3/23/23
to vim/vim, Subscribed

I thought that this was probably a known issue and I would be told of a fix/workaround. It sounds like it's more of a deficiency/bug. I should have labelled it as such when I started this issue.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1482171945@github.com>

Christian Brabandt

unread,
Mar 24, 2023, 5:42:56 AM3/24/23
to vim/vim, Subscribed

I thought that this was probably a known issue and I would be told of a fix/workaround. It sounds like it's more of a deficiency/bug. I should have labelled it as such when I started this issue.

I have linked exactly the documentation for it. A different workaround that seems to work, slightly easier:

    :tmap ® <esc>.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1482517010@github.com>

Bram Moolenaar

unread,
Mar 24, 2023, 12:25:33 PM3/24/23
to vim/vim, Subscribed

As @chrisbra mentioned, the :terminal command creates a terminal window, which emulates a certain terminal (similar to xterm). It will be different from a Windows console window. That is not a bug, just the way it works.
Some workarounds have been suggested, thus I don't consider this a Vim issue.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1483079484@github.com>

Bram Moolenaar

unread,
Mar 24, 2023, 12:25:33 PM3/24/23
to vim/vim, Subscribed

Closed #12191 as not planned.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/12191/issue_event/8840670451@github.com>

Yee Cheng Chin

unread,
Mar 25, 2023, 12:46:29 PM3/25/23
to vim/vim, Subscribed

Similar issues appear on macOS in MacVim IIRC where the default input settings make (for example) Option-e start the composing sequence for an acute accent rather than send Meta-e.

FWIW (I know the issue is closed already) I'm quite unhappy with this because it's confusing and it forces users to set "treat Option as Meta" in MacVim, all macOS terminals, other Neovim GUIs, etc. I would much rather that hitting would result in the standard ´ accent dead key, but it will still be able to be mapped as <M-e> in mapping. Similar issues happen for non-dead-keys as well (e.g. hitting shows "ø", and so you can't map it to in Vim).

The issue is fixable in a GUI (something I'm investigating) because we can kind of directly talk to Vim itself but there is no existing terminal key input API for this (I don't think CSI or modifyOtherKeys can do this). By "this" I mean the ability to send a key input that says "raw key = o, meta on, display string 'ø'", because the raw key and display strings are the same in terminal I think.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1483867285@github.com>

Bram Moolenaar

unread,
Mar 27, 2023, 4:34:50 PM3/27/23
to vim/vim, Subscribed


> > Similar issues appear on macOS in MacVim IIRC where the default
> > input settings make (for example) Option-e start the composing
> > sequence for an acute accent rather than send Meta-e.
>
> FWIW (I know the issue is closed already) I'm quite unhappy with this
> because it's confusing and it forces users to set "treat Option as Meta"
> in MacVim, all macOS terminals, other Neovim GUIs, etc. I would much
> rather that hitting <Option-E> would result in the standard ´ accent

> dead key, but it will still be able to be mapped as `<M-e>` in mapping.
> Similar issues happen for non-dead-keys as well (e.g. hitting <Option-o>
> shows "ø", and so you can't map it to <M-o> in Vim).

>
> The issue is fixable in a GUI (something I'm investigating) because we
> can kind of directly talk to Vim itself but there is no existing
> terminal key input API for this (I don't think CSI or modifyOtherKeys
> can do this). By "this" I mean the ability to send a key input that says
> "raw key = o, meta on, display string 'ø'", because the raw key and
> display strings are the same in terminal I think.

I actually changed the library used (libvterm) to support both
modifyOtherKeys and the Kitty keyboard protocol. Mainly so that I can
debug key encoding issues, but you should also be able to use this. You
probably have to set $TERM to something and set the 'keyprotocol' option
to match it and select "mok2" or "kitty". On Unix this often works
automatically, for me $TERM is "xterm-color" and if I start Vim in a
terminal window "verbose map" shows that modifyOtherKeys is active.

Obviously this requires Vim to recognize the key combination at first,
thus it must work in Vim itself before it can work in a terminal window.

--
DEAD PERSON: I'm getting better!
CUSTOMER: No, you're not -- you'll be stone dead in a moment.
MORTICIAN: Oh, I can't take him like that -- it's against regulations.
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1485827186@github.com>

Jason Gomez

unread,
Oct 10, 2023, 8:38:10 AM10/10/23
to vim/vim, Subscribed

tmap <expr> ® SendToTerm("\<Esc>.")
func SendToTerm(what)
  call term_sendkeys('', a:what)
  return ''
endfunc

It has been a lot better since this was added. I was wondering if I could also add some other readline shortcuts?

tmap <expr> æ SendToTerm("\<M-f>")
tmap <expr> â SendToTerm("\<M-b>")
tmap <expr> ä SendToTerm("\<M-d>")

These don't work, but I think it's clear what I intended them to do. While these shortcuts don't mean anything to cmd.exe, clink adds these readline keys.

ctrl-u, ctrl-k work fine, but ctrl-w doesn't. As ctrl-w is used to move between windows, is it possible to remap it only in insert mode in the terminal window? Something like...

tnoremap SendToTerm("<C-w>")

...?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1755321674@github.com>

Christian Brabandt

unread,
Oct 10, 2023, 8:56:24 AM10/10/23
to vim/vim, Subscribed

These don't work, but I think it's clear what I intended them to do.

Not sure why those would not work. What should those do?

but ctrl-w doesn't. As ctrl-w is used to move between windows, is it possible to remap it only in insert mode in the terminal window? Something like..

You may need to set 'winaltkey' to a different character then.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1755373301@github.com>

Jason Gomez

unread,
Oct 10, 2023, 2:29:24 PM10/10/23
to vim/vim, Subscribed

Not sure why those would not work. What should those do?

They are the characters that appear when I type those key combinations, which are standard readline keys (emacs mode) for word forward, word backward and forward word delete.

You may need to set 'winaltkey' to a different character then.

This issue regards vim and gvim on Windows only, but I only use winaltkey on gvim to remove the menu and make the keys work as in terminal vim. I don't understand the connection. Ctrl-w is he readline shortcut to delete word backwards.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/12191/1755999615@github.com>

Christian Brabandt

unread,
Oct 10, 2023, 3:06:50 PM10/10/23
to vim...@googlegroups.com, vim/vim, Mention
I meant termwinkey option. 

Am 10.10.2023 um 20:28 schrieb Jason Gomez <notifi...@github.com>:


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/12191/1755999615%40github.com.
Reply all
Reply to author
Forward
0 new messages