Here is a better patch:
matchaddpos() is unable to adjust highlights just like matchadd(), so the
previous patch will bring the issue with Syntastic back. But we can check
if buffer was changed and only in this case update window to the bottom.
This will still make it possible to navigate with matchparen fast.
2014-06-27 15:42 GMT+04:00 Alexey Radkov <[email protected]>:
> I found the reason of this: patch 7.3.1203:
>
> набор изм-й: 4916:ba328b4a990e
> метка: v7-3-1203
> автор: Bram Moolenaar <[email protected]>
> дата: Sat Jun 15 23:00:30 2013 +0200
> файлы: src/screen.c src/version.c
> описание:
> updated for version 7.3.1203
> Problem: Matches from matchadd() might be highlighted incorrectly when
> they
> are at a fixed position and inserting lines. (John Szakmeister)
> Solution: Redraw all lines below a change if there are highlighted
> matches.
> (idea by Christian Brabandt)
>
> This was due to Syntastic used matchaddpos() with static positions (what
> matchaddpos() was designed to implement). See
> https://groups.google.com/forum/#!topic/vim_dev/FuSXVJXySD8 for details.
> Removing this patch increases speed of redrawing matching parens
> dramatically! Syntastic developers may be encouraged to use new
> matchaddpos() for static highlights: this will help whole vim to work
> faster. I have a video that shows how faster it gets, but to show delays in
> details i had to chose 60fps and this made the video size 24Mb: i am not
> sure if it is ok to post such a big attachment here.
>
> The patch that removes 7.3.1203 is attached.
>
> UPDATE: Here is the video on in 30fps: http://vimeo.com/99325753, it does
> not show delays very well, but they are still visible. The cases shown:
>
> 1. Slow vim. Heavy loaded by parens line on the top: slow.
> 2. Slow vim. Same line on the bottom: fast.
> 3. Fast vim. Same line on the top: fast exactly as in case 2 and 4.
> 4. Fast vim. Same line on the bottom: fast.
>
> Cheers, Alexey.
>
>
>
> 2014-06-26 21:55 GMT+04:00 Alexey Radkov <[email protected]>:
>
> Meanwhile i found an obvious reproducible effect: horizontal navigation
>> (e.g. to the left and to the right) along a heavily loaded by parentheses
>> line differs in speed which depends on whether this line at the top of the
>> window (the slowest), mid of the window (faster) and bottom of the window
>> (fastest). I suspected that this was due to redrawing area lasted from the
>> top-parenthesis line to the bottom window line, though the bottom line of
>> redrawing area should be N + 1. I checked if b_mod_top and b_mod_bot is N
>> and N + 1 respectively when the line is being drawn in win_line(): it
>> appeared true. This means that something else forces screen to redraw to
>> the bottom line, but i cannot still find what. I tried also to set rtype in
>> match_add() and match_delete() to SOME_VALID: this should make redrawing
>> line slowest at any window position: indeed this worked as i expected: the
>> line began to redraw at the slowest speed and this should prove that the
>> effect is really due to wrong/unexpected redrawing area (i.e. its bottom
>> line lasts to the bottom of the window/screen).
>>
>> Cheers, Alexey.
>>
>>
>>
>> 2014-06-25 13:08 GMT+04:00 Alexey Radkov <[email protected]>:
>>
>> Ok, I'll do this during this or the next week.
>>>
>>> Cheers, Alexey.
>>>
>>>
>>> 2014-06-23 23:11 GMT+04:00 Bram Moolenaar <[email protected]>:
>>>
>>>
>>>> Alexey Radkov wrote:
>>>>
>>>> > Here is some small improvements for the patch:
>>>> >
>>>> > src/window.c, match_add():
>>>> > - removed unnecessary (after alloc() to alloc_clear() transformation)
>>>> > zero-initializations of m->pos fields,
>>>> > - checking that li == NULL was moved inside for-loop body
>>>> > - decrement i when the pos_list element is a number and has value 0
>>>> to be
>>>> > symmetric with sublist counterpart
>>>> >
>>>> > src/screen.c:
>>>> > - simple code alignment
>>>> >
>>>> > runtime/doc/eval.txt, matchaddpos():
>>>> > this is a bit more important: actually column number and match length
>>>> must
>>>> > correspond to bytes as col() returns, not screen columns as virtcol()
>>>> > returns! It does matter for Unicode texts like Cyrillics, i changed
>>>> doc to
>>>> > reflect this.
>>>>
>>>> Thanks.
>>>>
>>>> Now that we have one working test, perhaps you can add a few more tests?
>>>> Would be good if we cover the alternatives in the code.
>>>>
>>>>
>>>> --
>>>> Proverb: A nightingale that forgets the lyrics is a hummingbird.
>>>>
>>>> /// 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.
>>>>
>>>
>>>
>>
>
--
--
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.
diff -r dd88acaa1a57 src/screen.c
--- a/src/screen.c Thu Jun 26 22:33:51 2014 +0200
+++ b/src/screen.c Fri Jun 27 19:24:30 2014 +0400
@@ -1770,7 +1770,8 @@
#endif
#ifdef FEAT_SEARCH_EXTRA
/* match in fixed position might need redraw */
- || wp->w_match_head != NULL
+ || wp->w_match_head != NULL
+ && buf->b_mod_xlines != 0
#endif
)))))
{
