Minor startup problem with 'lazyredraw' set

[Christian J. Robinson]

Somewhere between patch 7.1.094 and 7.1.100 I found that setting
'lazyredraw' in my .vimrc causes gvim to not fully initialize the
screen on startup until a key is pressed. I can reproduce it doing
this:

echo "set lazyredraw" > vimrc-example
gvim -u vimrc-example -U NONE --noplugin

Notice that the intro message doesn't get displayed until a key is
pressed. If you provide a filename on the command line the buffer
doesn't get displayed initially either.

Forcing a redraw on the VimEnter event helps, but the cursor is still
displayed in the wrong location until a key is pressed:

echo "autocmd VimEnter * redraw" >> vimrc-example
gvim -u vimrc-example -U NONE --noplugin

- Christian

--
Unnamed Law: If it happens, it must be possible.
Christian J. Robinson <infy...@onewest.net> http://infynity.spodzone.com/
PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp

[Ajit Thakkar]

On 9/6/07, Christian J. Robinson <infy...@onewest.net> wrote:
>
>
> Somewhere between patch 7.1.094 and 7.1.100 I found that setting
> 'lazyredraw' in my .vimrc causes gvim to not fully initialize the
> screen on startup until a key is pressed. I can reproduce it doing
> this:
>
> echo "set lazyredraw" > vimrc-example
> gvim -u vimrc-example -U NONE --noplugin
>
> Notice that the intro message doesn't get displayed until a key is
> pressed. If you provide a filename on the command line the buffer
> doesn't get displayed initially either.
>

I have noticed the same problem. Patch 95 is the culprit.

Ajit

[Ron Aaron]

I have the same problem.

[Christian Brabandt]

Hi Blue!

On Fr, 21 Sep 2012, Blue wrote:

> On Sunday, September 9, 2007 5:59:49 AM UTC-7, Ron Aaron wrote:
> > I have the same problem.
>
> I also see this with version 7.3.661. I tried adding redraw! in many
> places, but it doesn't fix the problem.

Considering that you answered to a mail, which is 5 years old, please
give us more context. What exactly is your problem and where did you try
adding :redraw! which did not help?

regards,
Christian

[Blue]

On Saturday, September 22, 2012 4:26:57 AM UTC-7, Christian Brabandt wrote:
> Considering that you answered to a mail, which is 5 years old, please
>
> give us more context. What exactly is your problem and where did you try
>
> adding :redraw! which did not help?

When starting vim using the restore-cursor autocommand tip, about 75% of the time the cursor is displayed on the last column of the statusline, or the statusline isn't drawn and instead the cursor is displayed on the last column of the last displayed line. When I press any key, the cursor is redisplayed at the proper position and the status line gets redrawn, if it wasn't originally drawn. The following is the minimal vimrc that is needed for me to reproduce this.

set nocompatible
set lazyredraw

" :help restore-cursor
autocmd BufReadPost *
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ exe "normal! g`\""
\ endif

If I add a call to `redraw!` after the execute, the problem resolves for this example, but for a more complicated vimrc using a lot of plugins, figuring out where to add the redraw can be very challenging.
Unsetting lazyredraw is my only guaranteed solution now.

Tested with both iterm2 and Apple's Terminal.

vim --version:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 14 2012 08:16:31)
MacOS X (unix) version
Included patches: 1-244, 246-661
Compiled by buil...@gamma.local
Normal version without GUI. Features included (+) or not (-):
-arabic +autocmd -balloon_eval -browse +builtin_terms +byte_offset +cindent
-clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
-conceal +cryptv -cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
+find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape
-mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse
+mouse_xterm -mouse_urxvt -mouse_sgr +multi_byte +multi_lang -mzscheme
+netbeans_intg +path_extra -perl +persistent_undo +postscript +printer -profile
-python -python3 +quickfix +reltime -rightleft -ruby +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
-toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
system vimrc file: "/opt/local/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/opt/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H -I/opt/local/include -DMACOS_X_UNIX -no-cpp-precomp -pipe -O2 -arch x86_64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: /usr/bin/clang -L/opt/local/lib -arch x86_64 -L/usr/local/lib -o vim -lm -lncurses -liconv -lintl -framework Cocoa

[Christian Brabandt]

Hi Blue!

On Sa, 22 Sep 2012, Blue wrote:

> On Saturday, September 22, 2012 4:26:57 AM UTC-7, Christian Brabandt wrote:
> > Considering that you answered to a mail, which is 5 years old, please
> >
> > give us more context. What exactly is your problem and where did you try
> >
> > adding :redraw! which did not help?
>
> When starting vim using the restore-cursor autocommand tip, about 75% of the time the cursor is displayed on the last column of the statusline, or the statusline isn't drawn and instead the cursor is displayed on the last column of the last displayed line. When I press any key, the cursor is redisplayed at the proper position and the status line gets redrawn, if it wasn't originally drawn. The following is the minimal vimrc that is needed for me to reproduce this.
>
>
> set nocompatible
> set lazyredraw
>
> " :help restore-cursor
> autocmd BufReadPost *
> \ if line("'\"") > 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\""
> \ endif
>
>
> If I add a call to `redraw!` after the execute, the problem resolves for this example, but for a more complicated vimrc using a lot of plugins, figuring out where to add the redraw can be very challenging.
> Unsetting lazyredraw is my only guaranteed solution now.
>
> Tested with both iterm2 and Apple's Terminal.

That sounds like a problem with your terminal. Does that also happen
with the gui (whatever it is called on MacOS)?

I have never experienced a problem like this on Linux (using
xterm/xterm-unicode/rxvt/rxvt-unicode terminal emulator or the gtk/motif
guis or on the non-X11 console) or Windows (using the Gui)

regards,
Christian

[Blue]

On Sep 23, 9:28 am, Christian Brabandt <cbli...@256bit.org> wrote:
>
> On Sa, 22 Sep 2012, Blue wrote:
>
> > On Saturday, September 22, 2012 4:26:57 AM UTC-7, Christian Brabandt wrote:
> > > Considering that you answered to a mail, which is 5 years old, please
>
> > > give us more context. What exactly is your problem and where did you try
>
> > > adding :redraw! which did not help?
>
> > When starting vim using the restore-cursor autocommand tip,  about 75% of the time the cursor is displayed on the last column of the statusline, or the statusline isn't drawn and instead the cursor is displayed on the last column of the last displayed line. When I press any key, the cursor is redisplayed at the proper position and the status line gets redrawn, if it wasn't originally drawn. The following is the minimal vimrc that is needed for me to reproduce this.
>
> > set nocompatible
> > set lazyredraw
>
> > " :help restore-cursor
> > autocmd BufReadPost *
> >     \ if line("'\"") > 1 && line("'\"") <= line("$") |
> >     \   exe "normal! g`\""
> >     \ endif
>
> > If I add a call to `redraw!` after the execute, the problem resolves for this example, but for a more complicated vimrc using a lot of plugins, figuring out where to add the redraw can be very challenging.
> > Unsetting lazyredraw is my only guaranteed solution now.
>
> > Tested with both iterm2 and Apple's Terminal.
>
> That sounds like a problem with your terminal. Does that also happen
> with the gui (whatever it is called on MacOS)?

On OS X, iterm2 and Apple Terminal are the two most popular terminal
emulators. It's odd that they would both contain the same bug.

No, this doesn't happen with the gui (MacVim), but there was a similar
bug in the MacVim bugracker last year: https://code.google.com/p/macvim/issues/detail?id=319

I will also file a bug for iterm2 and see if the developer can help
track this down.

[Ben Fritz]

On Sunday, September 23, 2012 8:28:53 AM UTC-5, Christian Brabandt wrote:
>
>
>
> That sounds like a problem with your terminal. Does that also happen
>
> with the gui (whatever it is called on MacOS)?
>

Since the thread is so old (Google Groups shows the first post in 2007), I'll repost this info:

The OP noticed a problem with 'lazyredraw' set, where Vim would not finish drawing the screen at startup, which they claim happened "somewhere between patch 7.1.094 and 7.1.100". A follow-up post narrowed it down exactly to patch 95. The README for Vim 7.1 shows this specific patch was for Focus events, so I'm not sure exactly how it relates.

Here's the google groups discussion link: https://groups.google.com/d/topic/vim_dev/_BDGzoD-zfw/discussion . It looks like the issue was never satisfactorily resolved.

[Christian Brabandt]

Hi Ben!

Thanks for the link. I can't really reproduce neither the original
problem, nor the problem with the last-position-jump mentioned by Blue
on any of my systems I have access to (Windows and Linux using console
or gui built of vim).


regards,
Christian
--

[Ben Fritz]

I also just tried the procedure given by the OP to reproduce the problem, on gvim 7.3.661, Windows XP 64-bit. "Blue" who resurrected this thread claims to have reproduced the issue in 7.3.661, but when I try the given procedure (modified slightly for Windows "echo" behavior):

echo set lazyredraw > vimrc-example
gvim -u vimrc-example -U NONE --noplugin

I get a gvim Window with the intro text displayed right away and no observable drawing issues.

"Blue", if you are following this thread, that's two people unable to reproduce this really old issue using a very simple test case. What is the exact sequence of commands you use to reproduce the issue?

[Blue]

As I mentioned earlier, I only experienced this with the console version of Vim on iterm2 and Apple's default Terminal. I was not able to reproduce with the gui MacVim. I have just checked xterm and rxvt running under X11.app (Apple's X11 server) and there is no issue with them.

So this only seems to affect the two most popular terminal programs on OS X.

Ben, using your example of calling Vim without a file argument, I still observed the redraw issue. The cursor mostly displays for me initially in the lower right corner of the the intro text, instead of at (1,1).

[Ben Fritz]

I apologize, somehow I missed reading your message with a minimal .vimrc. This is pretty much what I was looking for.

I was unable to reproduce any drawing issues in gvim on Windows.

But using your test .vimrc:

set nocompatible
set lazyredraw

" :help restore-cursor
autocmd BufReadPost *
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ exe "normal! g`\""
\ endif

Launching console Vim on Windows XP 64-bit seems to work fine, but then typing : to open a command-line puts the command-line at the top of the screen instead of where it belongs. Removing the lazyredraw from the vimrc does not fix this problem for me.

Finishing the command and quitting Vim actually doesn't work at this point...but that's probably a different issue so I'm not going to go into it here.