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.
