> - Ctrl-@ and Nul (0x00). But since a null byte is not permissible inside > a line of edited text in Vim memory (in C, null bytes are string > terminators), nulls in the text are internally replaced by newline > characters (which would not be present because they signal a line > break), hence: also Ctrl-J and Nul (Ctrl-J is normally Linefeed, 0x0A).
In C strings are nothing more then pointers to an address of an allocated memory. Null terminators are just the most common convention, used and supported by a big number of libraries, nothing can prevent you from having {size_t str_len; char *string} structure in new software instead with whatever bytes you want in “char *” string part. > - Ctrl-H and Backspace (Ox08) > - Ctrl-I and Tab (0x09) > - Ctrl-M and Enter (0x0D) > - Ctrl-[ and Esc (0x1B) > - Ctrl-? and Del (0x7F) > > > All this because they have in each case the same representation in the > ASCII code, which used to be a 7-bit papertape code long before personal > computers had even been imagined, unless maybe by science fiction > writers. The Ctrl key used to be a hardware trick to disable the higher > two of the 7 paper-punch bits, so that keyboards could afford to have > fewer keys. Similarly Shift would disable the 2nd bit from top, so that > a (0x61) became A (0x41) etc. > > > The ^[ in those two termcap entries is not a caret followed by a square > bracket, it is a control-bracket (a single byte) which is one of several > notations for the Esc character. I think you could use > backslash-specials with :let, as follows: > > > :let &t_AB = "\e[48;5;%dm" > :let &t_AF = "\e[38;5;%dm" > > > (see :help expr-quote) (DISCLAIMER: untested) This should work. But I guess history of the subject is not necessary for terminal emulator writer: he already understood the issue correctly (“I have to change "^[" to real \x1B (Esc) symbol. Is this correct?”). Outside of vim it is much less natural to write `^[` in place of “real” escape: for example, zsh bindkey understands `^[` (two symbols, *not* real escape) as escape. Bash understands `\e` inside prompt variables, readline does this as well in `.inputrc`: there just no need in raw escapes. Only vim has the most known and standard :set syntax that is completely incapable of this job. And vim users used to write using :set …={real_escape} in place of using :let or :execute and then explaining WTF does ^[ here mean, while :let/:execute require no explanation. > or, you could input the ^[ escape by Ctrl-V prefixing but that's tricky > business: you would perhaps need a different number of Ctrl-V characters > when typing the ex-command at the keyboard or when writing the line in > your vimrc, and I'm not sure how to make sure you got the right number. > It also would be much less legible than the \e notation in double quotes. -- 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