On 2018-10-01, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > > > Summary: Vim does not handle well the situation where the color
> > > > scheme cannot be set until after the termresponse is received.
> > > > I'd like to open a discussion of possible solutions.
> > > >
> > > > I use a wide variety of terminals and X environments to run vim,
> > > > locally and remotely over ssh. Each has its peculiar color
> > > > characteristics. Most terminals these days identify themselves as
> > > > xterms, so the most reliable way to distinguish among these
> > > > terminals is to use their termresponse strings.
> > > >
> > > > Vim doesn't see the termresponse string until after it has sent the
> > > > termresponse request (t_RV) and the terminal has responded, at which
> > > > time the TermResponse autocommand is triggered. The termresponse
> > > > request is not even sent until after the vimrc has been processed
> > > > and the response is not received until after much or all of Vim's
> > > > initialization has been performed, including sourcing filetype
> > > > plugins.
> > > >
> > > > There is currently a problem with using the TermResponse autocommand
> > > > event and the v:termresponse string to set a color scheme: the
> > > > screen is not updated after the :colorscheme command is executed.
> > > > That leaves the old colors on the screen until the use presses
> > > > a key, at which time the screen is refreshed and the proper colors
> > > > appear.
> > > >
> > > > The obvious solution to this is to execute the :redraw command right
> > > > after :colorscheme. But this erases any messages that had been
> > > > displayed in the status line. For example, opening a vimball
> > > > normally displays this message in the status line:
> > > >
> > > > ***vimball*** Source this file to extract it! (:so %)
> > > >
> > > > A :redraw command erases this message. By now I don't need to be
> > > > reminded how to extract a vimball, but the :redraw could erase other
> > > > warning messages as well.
> > > >
> > > > One solution to this would be to have Vim apply the :colorscheme
> > > > colors to the current display, including any messages in the status
> > > > line, at the end of the :colorscheme command execution.
> > > >
> > > > Another solution would be to have a :redraw command that redraws the
> > > > screen with everything that Vim knows is on it, including messages
> > > > in the status line.
> > > >
> > > > Still another solution would be to have Vim pause its initialization
> > > > after sending the termresponse request and until the termresponse
> > > > response is received or a timeout occurs.
> > > >
> > > > My current workaround is to include code in my ~/.bashrc to have the
> > > > shell obtain the termresponse and put it in a TERMRESPONSE
> > > > environment variable which can then be processed by my ~/.vimrc. It
> > > > works well, but it shouldn't be necessary to do all that. Further,
> > > > there are some things done by Vim upon receiving the termresponse
> > > > that can't be triggered by the user. There is also the issue of
> > > > handling the t_RB and t_RF requests. Vim ought to be able to handle
> > > > all this cleanly by itself.
> > > >
> > > > Can we discuss a solution for this?
> > >
> > > I'm not aware of a good solution. The same problem happens if the
> > > terminal has a different number of colors than expected, thus the t_Co
> > > option value changes. This often makes the intro screen disappear.
> > >
> > > Waiting for the termresponse, and possibly a new t_Co value works when
> > > using Vim interactive and with a local terminal emulator, as the
> > > response should come quickly. It doesn't work so well when using ssh
> > > (slow) or we actually don't care about the response (batch script).
> >
> > I almost always use vim over an ssh connection and I don't
> > experience any noticeable slowness. I would think that if the time
> > to receive the terminal's termresponse during startup was
> > noticeable, vim's response to keystrokes would be so slow as to be
> > unusable.
>
> Well, perhaps you know that, but Vim can't possibly know. Adding
> 100msec to Vim startup is quite a lot. I know quite a few people tune
> their startup time (I do that when it seems slow).
>
> Another problem is that the termresponse may not come at all. So we
> would need to set a timeout. We actually already have a flush and peek
> in place, which should work when using a terminal emulator. That is in
> may_req_termresponse(). You can add a short delay there to see what
> happens.
>
> > IIUC, vim knows when running script not to display anything, so it
> > would know not to send a termresponse request, either.
>
> Not reliably...
>
> > > The closest we have to redraw while preserving messages is
> > > redraw_after_callback(). Perhaps it can be used after changing the
> > > color scheme?
> >
> > I don't know a lot about Vim internals. I did try inserting a call
> > to redraw_after_callback() at the very end of ex_colorscheme(), but
> > it didn't cause the screen to be redrawn after executing
> > :colorscheme in a TermResponse autocommand.
> >
> > I'll play around with it some more and see what I can figure out.
>
> Probably requires using a debugger to find out what happens exactly.
> Perhaps the mode is different in a TermResponse autocommand.
> Or add some ch_log() statements in the C code, to avoid changing the
> timing too much.
Thank you for the explanations and the pointers.
There doesn't seem to be a way to apply a new color scheme to the
screen without erasing the contents of the status line. And if vim
can't or won't wait until the termresponse has been received and the
TermResponse autocommand has been executed to run scripts that can
echo to the status line, then there is no way to use TermResponse to
change the color scheme without undesirable side effects.
So at this point I think the best solution for me is to query the
termresponse string from the terminal in my ~/.bashrc as I have
been, and use that string to help my color scheme script decide
which highlight definitions to use. Then the color scheme will be
set before anything writes to the screen. I may enhance my
~/.bashrc and color scheme script to use t_RF and t_RB as well.
I may revisit this later if I have the time and some inspiration.
Incidentally, in my experimenting I discovered a behavior of t_RV
that seems to contradict the documentation under ":help 'ttymouse'".
There it says,
If you do not want 'ttymouse' to be set to "xterm2" or "sgr"
automatically, set t_RV to an empty string:
:set t_RV=
If I include the line
:set t_RV=
in my ~/.vimrc, then later query value of t_RV, I see this:
:verbose set t_RV?
t_RV=^[[>c
Last set from ~/.vimrc line 42
So first of all, setting t_RV to an empty string seems to have no
effect; v:termresponse is acquired anyway. Secondly, :verbose does
not correctly report where it was last set and/or the value it was
set to.
Regards,
Gary
--
--
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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
