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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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

Best regards,
NB

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200926110852.GC3828%40void.

vim.tar.gz (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tony Mechelynck


On Tuesday, September 29, 2020 at 12:32:24 AM UTC+2, 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.

Best regards,
NB

I wouldn't expect Vim to overide that setting, but maybe some script (for instance some "system vimrc" installed by your sysadmin or your software distributor) does it behind your back.

The command
        :verbose set t_Co?
should tell you both the current value and where it was set.

If that still doesn't help you, you might try to replace your "set t_Co=16" statement by

        if has('autocmd') && !has('gui_running')
                au VimEnter set t_Co=16 | syntax enable
        endif

(which would set that setting at the very end of startup, except in gvim which uses 16777216 colours no matter what you set t_Co to) and see if it changes anything.

Best regards,
Tony.
Tony.

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6bdaaf85-1ca1-420e-8ed3-b02b8fc6498eo%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

Gary Johnson-4
In reply to this post by Nikolay Belikov
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

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200929150547.GA31849%40phoenix.
Reply | Threaded
Open this post in threaded view
|

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

Bram Moolenaar

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

--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
    site address in print or on TV, even though you've never had heart
    problems before.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202009291834.08TIYxSX757996%40masaka.moolenaar.net.
Reply | Threaded
Open this post in threaded view
|

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

Gary Johnson-4
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200929192640.GB31849%40phoenix.
Reply | Threaded
Open this post in threaded view
|

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

Christian Brabandt

On Di, 29 Sep 2020, Gary Johnson wrote:

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

I think this was suggested before. Also the todo file contains a couple
of statements regarding termresponse, e.g.

,----
| Add another autocommand like TermResponse that is fired for the other terminal
| responses, such as bg and fg.  Use "bg", "fg", "blink", etc. for the name.
`----

I think Bram also suggested to add additional TermResponse<Event> for
the various term events before.

BTW: Why wouldn't the VimEnter autocommand work? Is that, because
changing terminal options would then require some more initialization or
is that triggered too early?

Best,
Christian
--
Nie in die ferne Zeit verliere dich! Den Augenblick ergreife! Der ist dein.
                -- Friedrich Schiller

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200930082632.GD1002%40256bit.org.
Reply | Threaded
Open this post in threaded view
|

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

Gary Johnson-4
On 2020-09-30, Christian Brabandt wrote:

> On Di, 29 Sep 2020, Gary Johnson wrote:
>
> > 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.
>
> I think this was suggested before. Also the todo file contains a couple
> of statements regarding termresponse, e.g.
>
> ,----
> | Add another autocommand like TermResponse that is fired for the other terminal
> | responses, such as bg and fg.  Use "bg", "fg", "blink", etc. for the name.
> `----
>
> I think Bram also suggested to add additional TermResponse<Event> for
> the various term events before.
>
> BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> changing terminal options would then require some more initialization or
> is that triggered too early?

Thanks for the pointers.

I had been thinking of having a single TermResponsePost event, but
having multiple events might be better, especially if each of the
other responses is sent separately.

As I recall, VimEnter is too early.

I often work remotely, with a terminal on my desktop at home or in
an office and the host on which Vim is running many miles away,
often through a relatively slow network.  For a while, after either
my xterm changed or Vim changed so that t_Co was reset after
receiving the termresponse, my vim screen would flash at startup
because it would first be drawn using t_Co=16 as set in my vimrc,
then be redrawn a moment later at t_Co=256 when the termresponse was
received.

I am currently working from home and all my Vim sessions are local
or within my home network, so I don't have the delay problem.  I'll
have to determine which of the VimEnter and TermResponse events
occurs first, but a general solution should assume that TermResponse
occurs later.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200930172356.GC31849%40phoenix.
Reply | Threaded
Open this post in threaded view
|

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

Bram Moolenaar

Gary Johnson wrote:

> On 2020-09-30, Christian Brabandt wrote:
> > On Di, 29 Sep 2020, Gary Johnson wrote:
> >
> > > 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.
> >
> > I think this was suggested before. Also the todo file contains a couple
> > of statements regarding termresponse, e.g.
> >
> > ,----
> > | Add another autocommand like TermResponse that is fired for the other terminal
> > | responses, such as bg and fg.  Use "bg", "fg", "blink", etc. for the name.
> > `----
> >
> > I think Bram also suggested to add additional TermResponse<Event> for
> > the various term events before.
> >
> > BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> > changing terminal options would then require some more initialization or
> > is that triggered too early?
>
> Thanks for the pointers.
>
> I had been thinking of having a single TermResponsePost event, but
> having multiple events might be better, especially if each of the
> other responses is sent separately.
>
> As I recall, VimEnter is too early.

Talking back and forth with xterm can take some time.  I have thought of
another mechanism that would exchange a hash code of all the codes.  If
Vim recognizes it (cashed response) it's done quickly.  If not then Vim
would request the termcap/terminfo settings from the terminal.  This way
you have a delay only once and accurate codes all the time. But no work
has been done for it, and it would require talking to xterm clones and
other program authors to get it widely accepted.

> I often work remotely, with a terminal on my desktop at home or in
> an office and the host on which Vim is running many miles away,
> often through a relatively slow network.  For a while, after either
> my xterm changed or Vim changed so that t_Co was reset after
> receiving the termresponse, my vim screen would flash at startup
> because it would first be drawn using t_Co=16 as set in my vimrc,
> then be redrawn a moment later at t_Co=256 when the termresponse was
> received.

That's why I was thinking of disabling the mechanism, to avoid the
flicker.  Of course you then need to manually set the value.
 
> I am currently working from home and all my Vim sessions are local
> or within my home network, so I don't have the delay problem.  I'll
> have to determine which of the VimEnter and TermResponse events
> occurs first, but a general solution should assume that TermResponse
> occurs later.

It's possible, but the flicker would still happen.

--
Q: What is the difference between open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
   number and they will tell you it might be solved in a future version.
   For open-source software there isn't a phone number to call, but you
   get the solution within a day.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202009302050.08UKo8341065768%40masaka.moolenaar.net.
Reply | Threaded
Open this post in threaded view
|

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

Christian Brabandt

On Mi, 30 Sep 2020, Bram Moolenaar wrote:

> > As I recall, VimEnter is too early.

Would a timer work?

> > I often work remotely, with a terminal on my desktop at home or in
> > an office and the host on which Vim is running many miles away,
> > often through a relatively slow network.  For a while, after either
> > my xterm changed or Vim changed so that t_Co was reset after
> > receiving the termresponse, my vim screen would flash at startup
> > because it would first be drawn using t_Co=16 as set in my vimrc,
> > then be redrawn a moment later at t_Co=256 when the termresponse was
> > received.
>
> That's why I was thinking of disabling the mechanism, to avoid the
> flicker.  Of course you then need to manually set the value.

Do you mean, if the option is set manually in vimrc, disable the
termresponse? That would be a good compromise, I think.


Mit freundlichen Grüßen
Christian
--
Man kann alle Leute einige Zeit zum Narren halten und einige Leute allezeit,
aber alle Leute allezeit zum Narren halten kann man nicht.
                -- Abraham Lincoln

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201001064824.GE1002%40256bit.org.
Reply | Threaded
Open this post in threaded view
|

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

Gary Johnson-4
On 2020-10-01, Christian Brabandt wrote:
> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?

Perhaps.  And it might be better than nothing.  But timers carry the
risk that you wait too long on fast systems/connections and not long
enough on slow systems/connections.

> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network.  For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker.  Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.

The problem is, in my case, that I use a variety of terminals
running in a variety of operating systems to access vim on a variety
of hosts.  Sometimes I run vim locally while at other times I run it
over an ssh connection.  TERM is unreliable--almost every terminal
claims it's an xterm.  The termresponse has been for me an excellent
means of determining the terminal type.  It's just a little slow.
Disabling it would leave me as if back in pre-termresponse days with
terminal-dependent settings that weren't optimum and colors that
were often unreadable.

What I would like to be able to do--although I haven't tried this so
I might not like it after all--is to send t_RV at the start of my
vimrc, wait for the response (with a timeout), let Vim do what it
normally does upon receiving a termresponse, then continue with
the processing of the rest of my vimrc.  The termresponse exchange
normally happens in a fraction of a second, before I can type my
first keystroke anyway, and in less time than it takes to start Vim
on Windows, and the delay would prevent the flickering of a second
display refresh.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201001080636.GD31849%40phoenix.
Reply | Threaded
Open this post in threaded view
|

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

Bram Moolenaar
In reply to this post by Christian Brabandt

Christian wrote:

> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?
>
> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network.  For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker.  Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.

Not the termresponse, it is used for several other things, but disabling
the mechanism to fetch the values from xterm, which is what causes t_Co
to change later, at an unpredictable time.

--
Don't Panic!
                -- The Hitchhiker's Guide to the Galaxy

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202010011437.091EbrpN1272303%40masaka.moolenaar.net.