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

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 -- Bram@Moolenaar.net -- 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 vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202009302050.08UKo8341065768%40masaka.moolenaar.net.