Yet another patch update: properly initialize buffer b_mod_xlines = 0 when
setting b_mod_set in match_add() and match_delete().
2014-06-27 21:23 GMT+04:00 Alexey Radkov <[email protected]>:
> Update, Forgot parens in the patch.
>
>
> 2014-06-27 21:22 GMT+04:00 Alexey Radkov <[email protected]>:
>
> Update, Forgot parens in the patch.
>>
>>
>> 2014-06-27 19:31 GMT+04:00 Alexey Radkov <[email protected]>:
>>
>> 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 Sat Jun 28 12:22:43 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
)))))
{
diff -r dd88acaa1a57 src/window.c
--- a/src/window.c Thu Jun 26 22:33:51 2014 +0200
+++ b/src/window.c Sat Jun 28 12:22:43 2014 +0400
@@ -6904,12 +6904,13 @@
}
else
{
+ wp->w_buffer->b_mod_set = TRUE;
wp->w_buffer->b_mod_top = toplnum;
wp->w_buffer->b_mod_bot = botlnum;
+ wp->w_buffer->b_mod_xlines = 0;
}
m->pos.toplnum = toplnum;
m->pos.botlnum = botlnum;
- wp->w_buffer->b_mod_set = TRUE;
rtype = VALID;
}
}
@@ -6986,10 +6987,11 @@
}
else
{
+ wp->w_buffer->b_mod_set = TRUE;
wp->w_buffer->b_mod_top = cur->pos.toplnum;
wp->w_buffer->b_mod_bot = cur->pos.botlnum;
+ wp->w_buffer->b_mod_xlines = 0;
}
- wp->w_buffer->b_mod_set = TRUE;
rtype = VALID;
}
vim_free(cur);
