> - 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
