If a new function is involved then :3match would have explicitly different behaviour than other :match commands whereas currently it is not prohibited to use :3match for purposes besides matchparen (though it is not recommended in docs). It means that backward compatibility will be broken. This patch tries to guess if :3match was called by matchparen and do not break expected behaviour when :3match was called for other purposes. But i agree that regexp heuristics looks ugly and is not so fast. Probably using a new dedicated command instead :3match will be the best solution: the new command would be implemented by the matchaddpos() function.
2014-05-28 14:19 GMT+04:00 Bram Moolenaar <[email protected]>: > > Alexey Radkov wrote: > > > Hi all. > > > > My home computer is > > > > Linux 3.14.4-200.fc20.x86_64 x86_64 x86_64 x86_64 GNU/Linux > > > > running on > > > > AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ > > > > Relatively old. And matchparen (I use matchparen++ but they do not > > differ a lot) may perform extremely slow in some cases. I found that > > most slow call in the plugin is 3match and tried to increase its > > performance in the attached patch. > > > > The idea of the patch: > > > > Functions match_add() and match_delete() redraw whole screen passing > > flag SOME_VALID to redraw_later(). However matchparen does not require > > that all screen must be redrawn: the positions of matching pairs are > > well known and they are passed in the pattern regexp like > > \(\%24l\%31c\)\|\(\%28l\%36c\), so they can be easily retrieved in the > > match_add()/_delete(). Another fact that hints that we are dealing > > with matchparen is id 3 (:3match is mostly solely used for matchparen > > as the vim doc says). Now we can calculate boundaries for redrawing > > area, set wp->w_buffer->b_mod_set and corresponding top and bottom > > lines numbers and finally pass VALID to redraw_later() and it should > > redraw only between the top and the bottom lines. > > > > The patch works best for specific cases: > > > > when matching pairs are located on the same line or close lines and > > terminal area is big enough (this shows best difference due to small > > redraw area to the whole terminal area large relation value). > > > > I am not sure if this patch is clean (especially when using > > wp->w_buffer->b_mod... variables). > > > > I also attached video that shows how vim compiled with this patch > > (vim.fast) faster than original vim (vim.slow) (there are two sessions > > on the video: the first is slow, the second is fast(er)). > > In my opinion this is too tricky. It depends on the matchparen plugin > to set exactly the pattern that the code will recognize. > > Instead of this, it would be much better to add a kind of match that > doesn't work with a pattern but with the line number and column. > Perhaps also the number of characters. That's much simpler and also > more efficient. > > Could be done by adding a matchaddpos() function, similar to matchadd() > but using a position instead of a pattern. > > Whether the match position is adjusted for inserted and deleted lines > remains to be decided. Probably needs to be an option. > > -- > hundred-and-one symptoms of being an internet addict: > 215. Your mouse-clicking forearm rivals Popeye's. > > /// 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.
