On 27/05/11 13:23, Daniel Fishman wrote:
>
> According to the documentation (':he keycodes'), in insert mode a
> key combination '<ctrl-k>[key]' (where '[key]' is a key combination
> described in 'equivalent' column) should insert the string described
> in 'notation' column.
>
> On my machine though those key combinations either don't do anything
> or insert wrong strings. For example, a key labeled 'Backspace' on
> the keyboard emits (according to 'showkey -a') ascii code 127, and a
> key labeled 'Delete' emits a sequence of ascii codes: 27,91,51,126.
> I expected that '<ctrl-k>[key labeled "Backspace"]' will insert a
> string '<Del>' (since it emits ascii code of delete key) and
> '<ctrl-k>[key labeled "Delete"]' won't insert any string representing
> a key name (since ascii codes emitted by this key don't correspond to
> any special key). Instead, I get '<BS>' and'<Del>', respectively.
>
> On the other hand, most other key combinations which emit ascii codes
> corresponding to special keys don't insert the expected strings.
> For example, '<ctrl-k><ctrl-h>' don't insert'<Tab>' (or anything else).
>
> Is it a bug or am I missing something?
T'ain't a bug, it's a feature. You are missing several things:
1. For non-printable keys outside the ASCII or Unicode "universe", how
they are represented is at the mercy of the keyboard driver and terminal.
2. For historical reasons, on many terminals, the backspace key does not
send a backspace code, nor does the delete key send a delete code. See,
among others, :help :fixdel
3. Ctrl-K (in Insert mode) is overloaded: when followed by _two_ ASCII
or Unicode keys, which may be control characters but the latter facility
is rarely used, it ushers in a digraph (q.v.); when followed by one
non-Unicode "special key", it inseers that key's <> notation. Ctrl-K
Ctrl-H is still waiting for the second half of the digraph (we're in the
former case); only then will it look up in its table to see that there
is no defined digraph for that key pair. You could see this by looking
at the bottom right of the screen with 'showcmd' true
4. In gvim, but not in Console Vim, Ctrl-V acts as Ctrl-K when followed
by a non-Unicode key. In other cases (i.e., in gvim when followed by a
printable or control key, and in Console Vim in all cases), it can act
to insert keyscan codes without interpreting them (see ":help i_CTRL-V")
or to insert a character by value (see :help i_CTRL-V_digit).
5. All this means that the sentence "insert the key name by pressing
CTRL-K and then the key you want the name for" is misleading for
printing or control keys, including some of those listed under ":help
keycodes". Just like for any keystroke, the full description of what
Ctrl-K does in Insert mode is at ":help i_CTRL-K" (see ":help
help-context" on the very first page of help). This might, at worst, be
regarded as a documentation bug for ":help keycodes", but I wouldn't go
that far. Bram, what do you think?
>
>
>
> Below is a summery of key combinations representing '[key]', ascii
> codes those combinations emit on my machine, expected inserted string
> and actually inserted string.
>
> +-------------+--------------+------------+----------+
> | key | ascii | expected | actual |
> +-------------+--------------+------------+----------+
> | 'Backspace' | 127 | '<Del>' |'<BS>' |
> | 'Delete' | 27,91,51,126 | - | '<Del>' |
> | ctrl-h | 8 | '<BS>' | '?' |
> | ctrl-i | 9 | '<Tab>' | '?' |
> | ctrl-j | 10 | '<NL>' | '?' |
> | ctrl-l | 12 | '<FF>' | '?' |
> | ctrl-m | 13 | '<CR>' | '?' |
> | ctrl-[ | 27 | '<Esc>' | '' |
> |< | 60 | '<lt>' |'<' |
> | \ | 92 | '<Bslash>' | '\' |
> | | | 124 | '<Bar>' | 'Ś' |
> +-------------+--------------+------------+----------+
>
>
Expected after Ctrl-V where you put question marks are ^H, (skip the
width of a tab), ^@, ^L, ^M; and, for Esc, ^[ (about ^@ see ":help
NL-used-for-NUL").
After Ctrl-K, your Ctrl-H to Ctrl-M give "unfinished sequence": the next
key will trigger digraph interpretation if such strange digraphs have
been defined. Still after Ctrl-K, Esc (or the equivalent Ctrl-[ key) are
"abort" keys, like in most other circumstances in Vim.
The fact that you're seeing Ś where you should see | could be a locale
problem (on Unix, $LANG, $LC_CTYPE or $LC_ALL having a strange value:
each of these overrides the ones to its left), or it could be an
encoding problem with Vim ('encoding' and/or 'termencoding' having
values other than Latin1 and UTF-8; note that when 'termencoding' is
empty, it falls back on 'encoding')
See also, among others:
http://vim.wikia.org/wiki/Working_with_Unicode
:help mbyte.txt
plus those I mentioned above
:help digraph
:help i_CTRL-V
:help i_CTRL-V_digit
:help :fixdel
:help i_CTRL-K
In Console Vim, and in a more limited fashion in gvim, you can see which
terminal codes are defined by means of
:set termcap
Try it in both to see the difference.
HTH,
Tony.
--
hundred-and-one symptoms of being an internet addict:
97. Your mother tells you to remember something, and you look for
a File/Save command.
--
You received this message from the "vim_use" 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
No comments:
Post a Comment