Possible `redraw` bug in MacVim

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible `redraw` bug in MacVim

Aziz Light
I use a plugin that is supposed to blink the search result when pressing `n` or `N`. The plugin uses `redraw` to achieve the desired effect.

When I press `n` or `N`, instead of moving to the next search result directly, the cursor first moves to the first character of the next line (or the gutter if it's visible).

This issue happens in MacVim, but not in the terminal Vim shipped with MacVim (only the GUI version).

For more info on this issue, you can take a look at that Github issue: https://github.com/ivyl/vim-bling/issues/3

And to see what I mean (or if you can't be asked reading), I created a video showcasing the issue: http://youtu.be/miz_Ut8T4jk

I tried to remove all the plugins that I use and also downloaded the latest MacVim snapshot, and the issue still appears.

By the way, my regular MacVim (not the snapshot) is installed via Homebrew.

Is this a MacVim bug or an issue with my vimrc (maybe a conflict with some vimscript snippet I have) or even a bug in the plugin?

--
--
You received this message from the "vim_mac" 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_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Possible `redraw` bug in MacVim

Aziz Light
On Monday, October 14, 2013 7:05:16 PM UTC+2, Aziz Light wrote:

> I use a plugin that is supposed to blink the search result when pressing `n` or `N`. The plugin uses `redraw` to achieve the desired effect.
>
> When I press `n` or `N`, instead of moving to the next search result directly, the cursor first moves to the first character of the next line (or the gutter if it's visible).
>
> This issue happens in MacVim, but not in the terminal Vim shipped with MacVim (only the GUI version).
>
> For more info on this issue, you can take a look at that Github issue: https://github.com/ivyl/vim-bling/issues/3
>
> And to see what I mean (or if you can't be asked reading), I created a video showcasing the issue: http://youtu.be/miz_Ut8T4jk
>
> I tried to remove all the plugins that I use and also downloaded the latest MacVim snapshot, and the issue still appears.
>
> By the way, my regular MacVim (not the snapshot) is installed via Homebrew.
>
> Is this a MacVim bug or an issue with my vimrc (maybe a conflict with some vimscript snippet I have) or even a bug in the plugin?

MacVim bug confirmed. However, it is fixed in HEAD. The solution?

`brew install macvim --HEAD`

--
--
You received this message from the "vim_mac" 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_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Possible `redraw` bug in MacVim

Aziz Light
On Thursday, October 17, 2013 2:38:11 PM UTC+2, Aziz Light wrote:

> On Monday, October 14, 2013 7:05:16 PM UTC+2, Aziz Light wrote:
> > I use a plugin that is supposed to blink the search result when pressing `n` or `N`. The plugin uses `redraw` to achieve the desired effect.
> >
> > When I press `n` or `N`, instead of moving to the next search result directly, the cursor first moves to the first character of the next line (or the gutter if it's visible).
> >
> > This issue happens in MacVim, but not in the terminal Vim shipped with MacVim (only the GUI version).
> >
> > For more info on this issue, you can take a look at that Github issue: https://github.com/ivyl/vim-bling/issues/3
> >
> > And to see what I mean (or if you can't be asked reading), I created a video showcasing the issue: http://youtu.be/miz_Ut8T4jk
> >
> > I tried to remove all the plugins that I use and also downloaded the latest MacVim snapshot, and the issue still appears.
> >
> > By the way, my regular MacVim (not the snapshot) is installed via Homebrew.
> >
> > Is this a MacVim bug or an issue with my vimrc (maybe a conflict with some vimscript snippet I have) or even a bug in the plugin?
>
> MacVim bug confirmed. However, it is fixed in HEAD. The solution?
>
> `brew install macvim --HEAD`

Actually, the MacVim bug is not solved. I just confirmed with Raimondi from IRC that it is an actual bug. Here are the details:

The bug seems to be with the `redraw` function in files that don't fit in one screen. To reproduce, open a "long" file (as in, one with enough lines so that it doesn't fit on one screen) with the following command:

    mvim -N -u NONE -U NONE file

Then source the vim-bling plugin (because this plugin will force the bug to appear):

    :so vim-bling/plugin/bling.vim

The plugin can be found here: https://github.com/ivyl/vim-bling

Alternatively, put the following code in a file (say blink.vim), and source it:

    highlight WhiteOnRed guibg=red
    function! HLNext (blinktime)
        let [bufnum, lnum, col, off] = getpos('.')
        let matchlen = strlen(matchstr(strpart(getline('.'),col-1),@/))
        let target_pat = '\c\%#'.@/
        let ring = matchadd('WhiteOnRed', target_pat, 101)
        redraw
        exec 'sleep ' . float2nr(a:blinktime * 1000) . 'm'
        call matchdelete(ring)
        redraw
    endfunction
    nnoremap <silent> n   n:call HLNext(0.4)<cr>
    nnoremap <silent> N   N:call HLNext(0.4)<cr>

This code also forces the error to appear.

Then search for a word (or even a character) and press `n` or `N`.

Normally, you will see the caret jump at the end of the line before going back to the next search result.

Note that I installed MacVim with Homebrew on OS X 10.8.5, but I built the code from master/HEAD with the following command:

    brew install macvim --HEAD

Here is the output of `mvim --version`:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 17 2013 14:49:06)
MacOS X (unix) version
Included patches: 1-52
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_binary
+arabic          +find_in_path    -mouse_sysmouse  +tag_old_static
+autocmd         +float           +mouse_urxvt     -tag_any_white
+balloon_eval    +folding         +mouse_xterm     +tcl
+browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     +fullscreen      -mzscheme        +textobjects
+cindent         -gettext         +netbeans_intg   +title
+clientserver    -hangul_input    +odbeditor       +toolbar
+clipboard       +iconv           +path_extra      +transparency
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
+farsi           +mouse_netterm   +syntax          
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1  
Linking: cc   -L.   -L.    -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lncurses -liconv -framework Cocoa   -fstack-protector -L/usr/local/lib  -L/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -framework Python  -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -framework Ruby  

Also, the bug does NOT appear in terminal Vim (even the one that comes with MacVim).

--
--
You received this message from the "vim_mac" 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_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: Possible `redraw` bug in MacVim

Björn Winckler
On Thu, Oct 17, 2013 at 4:30 PM, Aziz Light <[hidden email]> wrote:

> On Thursday, October 17, 2013 2:38:11 PM UTC+2, Aziz Light wrote:
>> On Monday, October 14, 2013 7:05:16 PM UTC+2, Aziz Light wrote:
>> > I use a plugin that is supposed to blink the search result when pressing `n` or `N`. The plugin uses `redraw` to achieve the desired effect.
>> >
>> > When I press `n` or `N`, instead of moving to the next search result directly, the cursor first moves to the first character of the next line (or the gutter if it's visible).
>> >
>> > This issue happens in MacVim, but not in the terminal Vim shipped with MacVim (only the GUI version).
>> >
>> > For more info on this issue, you can take a look at that Github issue: https://github.com/ivyl/vim-bling/issues/3
>> >
>> > And to see what I mean (or if you can't be asked reading), I created a video showcasing the issue: http://youtu.be/miz_Ut8T4jk
>> >
>> > I tried to remove all the plugins that I use and also downloaded the latest MacVim snapshot, and the issue still appears.
>> >
>> > By the way, my regular MacVim (not the snapshot) is installed via Homebrew.
>> >
>> > Is this a MacVim bug or an issue with my vimrc (maybe a conflict with some vimscript snippet I have) or even a bug in the plugin?
>>
>> MacVim bug confirmed. However, it is fixed in HEAD. The solution?
>>
>> `brew install macvim --HEAD`
>
> Actually, the MacVim bug is not solved. I just confirmed with Raimondi from IRC that it is an actual bug. Here are the details:
>
> The bug seems to be with the `redraw` function in files that don't fit in one screen. To reproduce, open a "long" file (as in, one with enough lines so that it doesn't fit on one screen) with the following command:
>
>     mvim -N -u NONE -U NONE file
>
> Then source the vim-bling plugin (because this plugin will force the bug to appear):
>
>     :so vim-bling/plugin/bling.vim
>
> The plugin can be found here: https://github.com/ivyl/vim-bling
>
> Alternatively, put the following code in a file (say blink.vim), and source it:
>
>     highlight WhiteOnRed guibg=red
>     function! HLNext (blinktime)
>         let [bufnum, lnum, col, off] = getpos('.')
>         let matchlen = strlen(matchstr(strpart(getline('.'),col-1),@/))
>         let target_pat = '\c\%#'.@/
>         let ring = matchadd('WhiteOnRed', target_pat, 101)
>         redraw
>         exec 'sleep ' . float2nr(a:blinktime * 1000) . 'm'
>         call matchdelete(ring)
>         redraw
>     endfunction
>     nnoremap <silent> n   n:call HLNext(0.4)<cr>
>     nnoremap <silent> N   N:call HLNext(0.4)<cr>
>
> This code also forces the error to appear.
>
> Then search for a word (or even a character) and press `n` or `N`.
>
> Normally, you will see the caret jump at the end of the line before going back to the next search result.
>
> Note that I installed MacVim with Homebrew on OS X 10.8.5, but I built the code from master/HEAD with the following command:
>
>     brew install macvim --HEAD
>
> Here is the output of `mvim --version`:
>
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 17 2013 14:49:06)
> MacOS X (unix) version
> Included patches: 1-52
> Compiled by Homebrew
> Huge version with MacVim GUI.  Features included (+) or not (-):
> +acl             +file_in_path    +mouse_sgr       +tag_binary
> +arabic          +find_in_path    -mouse_sysmouse  +tag_old_static
> +autocmd         +float           +mouse_urxvt     -tag_any_white
> +balloon_eval    +folding         +mouse_xterm     +tcl
> +browse          -footer          +multi_byte      +terminfo
> ++builtin_terms  +fork()          +multi_lang      +termresponse
> +byte_offset     +fullscreen      -mzscheme        +textobjects
> +cindent         -gettext         +netbeans_intg   +title
> +clientserver    -hangul_input    +odbeditor       +toolbar
> +clipboard       +iconv           +path_extra      +transparency
> +cmdline_compl   +insert_expand   +perl            +user_commands
> +cmdline_hist    +jumplist        +persistent_undo +vertsplit
> +cmdline_info    +keymap          +postscript      +virtualedit
> +comments        +langmap         +printer         +visual
> +conceal         +libcall         +profile         +visualextra
> +cryptv          +linebreak       +python          +viminfo
> +cscope          +lispindent      -python3         +vreplace
> +cursorbind      +listcmds        +quickfix        +wildignore
> +cursorshape     +localmap        +reltime         +wildmenu
> +dialog_con_gui  -lua             +rightleft       +windows
> +diff            +menu            +ruby            +writebackup
> +digraphs        +mksession       +scrollbind      -X11
> +dnd             +modify_fname    +signs           -xfontset
> -ebcdic          +mouse           +smartindent     +xim
> +emacs_tags      +mouseshape      -sniff           -xsmp
> +eval            +mouse_dec       +startuptime     -xterm_clipboard
> +ex_extra        -mouse_gpm       +statusline      -xterm_save
> +extra_search    -mouse_jsbterm   -sun_workshop    -xpm
> +farsi           +mouse_netterm   +syntax
>    system vimrc file: "$VIM/vimrc"
>      user vimrc file: "$HOME/.vimrc"
>  2nd user vimrc file: "~/.vim/vimrc"
>       user exrc file: "$HOME/.exrc"
>   system gvimrc file: "$VIM/gvimrc"
>     user gvimrc file: "$HOME/.gvimrc"
> 2nd user gvimrc file: "~/.vim/gvimrc"
>     system menu file: "$VIMRUNTIME/menu.vim"
>   fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
> Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1
> Linking: cc   -L.   -L.    -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lncurses -liconv -framework Cocoa   -fstack-protector -L/usr/local/lib  -L/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -framework Python  -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -framework Ruby
>
> Also, the bug does NOT appear in terminal Vim (even the one that comes with MacVim).

Thanks for the detailed report.  I haven't had time to confirm myself,
but I suspect this has something to do with the fact that MacVim
batches drawing commands instead of handling them immediately as they
happen.  This is due to the fact that drawing commands have to cross a
process boundary.

I will take a look when I get the time, but it will be a while.  Feel
free to open an issue on the Google code page as well to reduce the
risk that I forget about this, but that is up to you.

Thanks,
Björn

--
--
You received this message from the "vim_mac" 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_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.