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. -- All true wisdom is found on T-shirts. /// 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.
