Re: Vim 256 colors in Windows console

[Tony Mechelynck]

On 30/06/12 20:24, Maximus ConEmu wrote:
> Hi.
>
> Not sure, if community is interested in subj, but...
> I'm developer of ConEmu (Windows Console Emulator) wich supports xterm 256 color extension of ANSI X3.64.
> http://code.google.com/p/conemu-maximus5/wiki/Screenshots#ANSI_X3.64_and_xterm_256_colors_in_ConEmu
>
> Vim "from the box" does not supports ansi codes, so small patch was created.
> I'm not using Vim and have only superficial knowledge about it. So, this patch may be not perfect or not complete.
>
> Any comments? Are here windows developers, interested in this feature?
>

I think Vim supports ansi codes out of the box if you can arrange to
have 'term' set to "ansi". This may require a Vim build with
+builtin_terms compiled-in when running on a system with no "ansi"
termcap or equivalent.

Try the following (in your vimrc)

if !has('gui_running')
echomsg "Found: Terminal" &term "with" &t_Co "colors"
if has('builtin_terms')
\ && ((&term == "pcterm") || (&term == "win32"))
echomsg "Trying to set ANSI 256-color terminal"
set term=ansi t_Co=256
echomsg "Result: Terminal" &term "with" &t_Co "colors"
endif
endif

then restart Vim.
- Does it display the messages?
(Check with :messages shortly after startup)
- Can you use 256 colours in the terminal?

If it works, you can comment away the :echomsg lines by prefixing each
of them with a double quote.


Best regards,
Tony.
--
Without ice cream life and fame are meaningless.

[Maximus ConEmu]

Thanks for clarification.
Yes, message appears, 256 colors works.
However, CR/LF looks weird. Checking my code now...

One more question.

set t_AB=^[[48;5;%dm
set t_AF=^[[38;5;%dm

does not works for me. I have to change "^[" to real \x1B (Esc) symbol. Is this correct?

[Maximus ConEmu]

Whell, One problem/incomprehensibility is revealed.

Vim drops all flags for g_hConOut, because of "(tmode == TMODE_RAW)"
os_win32.c: 2952
cmodeout &= ~(ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT);

I'm hunging up. Dropping "ENABLE_PROCESSED_OUTPUT" means that must NOT examined for ASCII control sequences (Backspace, tab, bell, carriage return, and linefeed). So, they will not cause correct actions and must be written direct to screen. So, I get on the screen corresponding symbols ("CR/LF") instead of . carriage return, and linefeed.

I'm not sure, what will be correct.

Thanks, in advance.

[Tony Mechelynck]

On 01/07/12 00:52, Maximus ConEmu wrote:
> Thanks for clarification.
> Yes, message appears, 256 colors works.
> However, CR/LF looks weird. Checking my code now...

see
:help 'ff'
:help 'ffs'
:help ++ff
:help file-formats
:help file-read

>
> One more question.
>
> set t_AB=^[[48;5;%dm
> set t_AF=^[[38;5;%dm
>
> does not works for me. I have to change "^[" to real \x1B (Esc) symbol. Is this correct?
>

Yes, it is. To Vim, the following are equivalent and (I think) cannot be
told apart:

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

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.


Best regards,
Tony.
--
Love and scandal are the best sweeteners of tea.

[ZyX]

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

[Tony Mechelynck]

On 15/01/13 20:26, ZyX wrote:
[Tony Mechelynck wrote]

>> 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?�). [...]

Yes, see ":help expr-quote" (without the quotes). All the double-quoted
strings below (and a few others) have the same meaning (IIUC, the
disclaimers about 'encoding' on that help page don't apply to the Escape
character except in EBCDIC):

"\e"
"\<Esc>"
"\033"
"\x1b"
"\u001B"


Best regards,
Tony.
--
There is no right or wrong, there is only your personal opinion.
(Bram Moolenaar)