Rastislav Barlik wrote:
> On Tuesday, May 23, 2017 at 9:52:32 AM UTC+1, Bram Moolenaar wrote:
> > Rastislav Barlik wrote:
> >
> > > I'm seeing some UI glitches when using vimwiki plugin when I start it
> > > with 'vim -c :VimwikiIndex'. Please look at the attached screenshots.
> > > One screenshot was taken after the startup, the second one was taken
> > > after hitting Ctrl-L to refresh the screen.
> > >
> > > This has started to happen after my last upgrade of Vim. I've tracked
> > > the behaviour using git bisect and I've found the problematic patch
> > > nr. 8.0.0567. This patch moved the call for requesting color and
> > > ambiwidth a couple of block down.
> > >
> > > For me the problematic code is the call of
> > > may_req_ambiguous_char_width() (src/main.c:800), which I believe
> > > wasn't triggered before because it was being called right after
> > > setting 'starting = NO_BUFFERS'. Now, the function has been moved a
> > > couple of lines below, after a line setting variable 'starting' to
> > > zero. I believe that function is now messing with my terminal.
> > >
> > > I've tested the behaviour, and in fact if I move the function above
> > > the line that sets 'starting = 0', effectively disabling the function,
> > > the glitch disappears.
> > >
> > > I don't understand how to test the may_req_ambiguous_char_width()
> > > function. Could anybody please shed some light on this function or
> > > give me a hint how to test it?
> >
> > I looked into the order of these "request info from terminal" calls
> > again, and I believe the order is good now. The main thing we try to
> > avoid here is that when someone does:
> > vim file -c DoSometing -c quit
> > We don't want the terminal response for the requests to appear in the
> > shell that Vim was started from. You would get escape sequences at the
> > prompt, that is quite annoying.
> >
> > Checking for "quit" is not feasible, exiting Vim can happen in may other
> > ways, also from the DoSomething command itself.
> >
> > So the only way would be to figure out why you get these side effects
> > and try to solve them. First of all, if you set t_u7 to empty, does the
> > problem go away?
> >
> > I suspect that something may cause an early redraw and when we send t_u7
> > screen updating already happened. We can force another update in that
> > case. Try this patch:
> >
> > --- a/src/term.c 2017-04-20 19:44:05.409983042 +0200
> > +++ b/src/term.c 2017-05-23 10:48:44.818443303 +0200
> > @@ -3335,6 +3335,7 @@
> > out_flush();
> > term_windgoto(1, 0);
> > out_str((char_u *)" ");
> > + redraw_all_later(NOT_VALID);
> > term_windgoto(0, 0);
> > /* check for the characters now, otherwise they might be eaten by
> > * get_keystroke() */
>
> Thanks for the reply,
>
> setting t_u7 to empty does indeed make the problem go away.
>
> I've tried your patch and although it didn't help straight away, when
> I've changed it to redraw_all_later(CLEAR) instead of
> redraw_all_later(NOT_VALID), it now works.
Thanks for trying this. Using CLEAR may cause flickering, there should
be a way to only redraw the second screen line. Possibly by changing
ScreenLines[].
--
CART DRIVER: Bring out your dead!
LARGE MAN: Here's one!
CART DRIVER: Ninepence.
BODY: I'm not dead!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
