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). The closest we have to redraw while preserving messages is redraw_after_callback(). Perhaps it can be used after changing the color scheme? -- Would you care for a drink? I mean, if it were, like, disabled and you had to look after it? /// Bram Moolenaar -- [email protected] -- 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_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.
