Any updates here, or is it still broken in HEAD? If it's still not fixed,
it would be great to have the offending change reverted while waiting for
the complete solution.
David
On Sat, Aug 16, 2014 at 7:23 AM, Bram Moolenaar b...@moolenaar.net wrote:
Christian Brabandt wrote:
On Do, 14
Hi David!
On Fr, 29 Aug 2014, David Barnett wrote:
Any updates here, or is it still broken in HEAD? If it's still not fixed,
it would be great to have the offending change reverted while waiting for
the complete solution.
Can you still reproduce the issue with the latest patch level? It
Nope, hadn't tried, I was just watching for an update on this thread.
Thanks for taking care of it!
David
On Fri, Aug 29, 2014 at 2:40 PM, Christian Brabandt cbli...@256bit.org
wrote:
Hi David!
On Fr, 29 Aug 2014, David Barnett wrote:
Any updates here, or is it still broken in HEAD? If
On Do, 14 Aug 2014, Bram Moolenaar wrote:
Christian Brabandt wrote:
But anyway, this raises the question again, why matchaddpos()
accepts a list of positions (but only 8 items), while all other
functions usually only accept 1 position.
It's used for the matchparen plugin. The
Christian Brabandt wrote:
But anyway, this raises the question again, why matchaddpos()
accepts a list of positions (but only 8 items), while all other
functions usually only accept 1 position.
It's used for the matchparen plugin. The idea is that it's useful for
other plugins as
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number
of
bytes
in the (last) character the highlight continues
Hi Bram!
On Mi, 13 Aug 2014, Bram Moolenaar wrote:
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the
number of
Christian Brabandt wrote:
Hi Bram!
On Mi, 13 Aug 2014, Bram Moolenaar wrote:
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length
Am 2014-08-14 01:30, schrieb Bram Moolenaar:
Christian Brabandt wrote:
Hi Bram!
On Mi, 13 Aug 2014, Bram Moolenaar wrote:
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:
On Monday, August 11, 2014 5:27:58 PM UTC+12, Dominique Pelle wrote:
I can now reproduce the slow rendering you
describe with:
$ cd vim/src
$ vim -u NONE option.c \
-c 'syntax on' +471 \
-c hi def link RightMargin Error|exec ('match RightMargin
/\%42v.\%41v/')
Then I press
Hi Bram!
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last) character the highlight continues until the end of
the line.
Solution:
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last) character the highlight continues until the end of
On Mo, 11 Aug 2014, Bram Moolenaar wrote:
Christian Brabandt wrote:
On Sa, 09 Aug 2014, Bram Moolenaar wrote:
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last)
You're not asking for the output of getmatches(), are you? Or are you
talking about debugging in gdb? I haven't found any way to query match
positions from within vim.
The repro case I'm using now is
vim -c highlight def link RightMargin Error | exec ('match RightMargin
/\%42v.\%41v/') SOMEFILE
David Barnett wrote:
You're not asking for the output of getmatches(), are you? Or are you
talking about debugging in gdb? I haven't found any way to query match
positions from within vim.
The repro case I'm using now is
vim -c highlight def link RightMargin Error | exec ('match
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last) character the highlight continues until the end of
the line.
Solution: Change condition from equal to larger-or-equal.
Files:
Yep, it's still slow with -u NONE -N. It seems to vary quite a bit from
file to file. The way I reproduce is to just hold down PgDn for a few
seconds. It's fine for unaffected versions, but stutters for about half a
second in 362. For some reason most vim files aren't too bad for it.
src/options.c
David Barnett wrote:
Yep, it's still slow with -u NONE -N. It seems to vary quite a bit from
file to file. The way I reproduce is to just hold down PgDn for a few
seconds. It's fine for unaffected versions, but stutters for about half a
second in 362. For some reason most vim files aren't too
On Sunday, August 10, 2014 10:27:58 PM UTC-7, Dominique Pelle wrote:
When I find time, I'll compare profiling
results before after vim-7.4.389 (allegedly the patch
that introduces the slow down).
Slight correction: 389 was the patch where I first noticed the problem, but
then I bisected it
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last) character the highlight continues until the end of
the line.
Solution: Change condition from equal to larger-or-equal.
Files: src/screen.c
It's a very small
David Barnett wrote:
Looks like it's patch 7.4.362:
Problem:When matchaddpos() uses a length smaller than the number of
bytes
in the (last) character the highlight continues until the end of
the line.
Solution: Change condition from equal to larger-or-equal.
Files:
It looks like some change between 7.4.316 and 7.4.389 has made vim extremely
sluggish when just scrolling around in files if the vim-indent-guides plugin is
installed: https://github.com/nathanaelkane/vim-indent-guides/issues/75. This
plugin does custom syntax highlighting, which may be a
22 matches
Mail list logo
