Re: `set t_Co=16` in vimrc file has no effect

On 2020-09-29, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > On 2020-09-26, Nikolay Belikov wrote:
> > > Hello all,
> > >
> > > I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> > > variable. This might be a bug, but more probably is just a case of
> > > PEBCAK, so maybe someone could point me towards what I'm doing wrong.
> > >
> > > Background: I want to use my terminal emulator (which is plain old
> > > `xterm`) color scheme across all TUI programs, including Vim. I've
> > > added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> > > itself to 16 base colors (at least this is what all sources on Internet
> > > say to do, which I managed to find). However, it appears that Vim does
> > > not honor my will and resets `t_Co` to 256, unless I manually type `:set
> > > t_Co=16` in command-line mode.
> > >
> > > I reduced my `vimrc` to the bare minimum needed to reproduce the
> > > problem, and now it contains a single line:
> > >
> > > set t_Co=16
> > >
> > > At this point I'm unsure what to do and ask for your assistance. I
> > > attach a log captured by running `vim -V100vim.log` as well as version
> > > info (`vim --version >vim.version`), and I'm willing to provide any
> > > other info that may be of help.
> >
> > Vim may change t_Co when it receives a terminal's termresponse.
> > I noticed the same strange behavior some years ago with Vim setting
> > t_Co to 256 in an xterm. See
> >
> > :help v:termresponse
> > :help t_RV
> > :helpgrep termresponse
> >
> > You can test this by adding this to your vimrc,
> >
> > set t_RV=
> >
> > and seeing if t_Co is still mysteriously reset to 256.
> >
> > You may be able to reset t_Co to 16 with this in your vimrc:
> >
> > autocmd TermResponse * set t_Co=16
> >
> > I say "may" because I've found that not everything works as I would
> > expect it to in the environment of a TermResponse autocommand.
> >
> > See
> >
> > :help TermResponse
>
> Vim has a special mechanism to request the actual termcap codes from
> xterm. This happens after receiving the termresponse. Using the
> TermResponse autocommand may do this too early.
>
> There is actually no way to disable this mechanism without also
> disabling some other stuff. It might be helpful to add an option to
> disable the mechanism. 'termgetcodes', default on?
> The function that sends the requests is req_more_codes_from_term().

I'm too busy at the moment to give this a very thoughtful response,
and it was a while ago that I looked at that code, but it seems that
there were several things done in response to receiving the
termresponse, so I don't know that one option would serve all needs.
In the present case, the only problem seems to be the setting of
t_Co.

The problem I've had is that I want to set various options and
highlights depending on the terminal type, but the type is not
accurately known when vimrc is read, and when the TermResponse event
is triggered, not everything can be set correctly.

I've resorted to having the termresponse queried in my ~/.bashrc,
which sets an environment variable that vimrc can then read. It
works very well for making terminal-dependent settings in my vimrc
and colorscheme files. When vim queries and receives the
termresponse itself, it then makes the additional settings you
mentioned. It would be nice, though, if this could all be done
within Vim.

I think maybe the whole termresponse behavior should be thought
through and made more useful, perhaps by adding a later
TermResponse-like event. I'll try to find some time.

Regards,
Gary

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200929192640.GB31849%40phoenix.