1

Re: Incremental search bug [ViEmu 2.0.37]

Hello,

It seems to be a bug when searching for '/'
In normal mode, I type '/' then '/' again and <CR>
The text is not found but when I go back and navigate with hjkl, the CPU goes to 100% (50% on a HT Pentium 4) and the cursor moves slow.

After searching for something else (match or no match) everything goes back to normal.

2

Re: Incremental search bug [ViEmu 2.0.37]

If you disable hlsearch the problem goes away. I've read a previous post and I think they are related.

3

Re: Incremental search bug [ViEmu 2.0.37]

Hi,

I think I fixed this back in one of the latest maintenance builds. Right now, you catch me switching to a new computer (I have to migrate the SVN repository and everything else), so I can't properly verify it, but I've tested it in VS.NET 2003 on my laptop (using ViEmu/VS 2.0.44 with C++ source code) and it seems to work fine.

You can find the link to the latest build (2.0.46) here:

  http://forums.ngedit.com/viewtopic.php?id=121

Please let me know whether that fixes it. If not, the details about the VS version, source language and file size would be useful.

Best regards,

  Jon

4

Re: Incremental search bug [ViEmu 2.0.37]

Thanks for your reply and for the coolest VS plugin smile

I've installed the latest ViEmu on my home PC and all seems to work fine. I was using VS 2005 at work, with a few KB file (I do not consider it big).
I guess the issue is solved in the latest build ; if the problem still persists at work (I doubt it ...), I'll try to give you more details about the software/hardware configuration.

5

Re: Incremental search bug [ViEmu 2.0.37]

Thanks for the praises and for getting back to me, please be sure to let me know if it's not fixed in order to look into it in detail.

Best regards,

  Jon

6

Re: Incremental search bug [ViEmu 2.0.37]

I've installed ViEmu 2.0.46 and the problem didn't go away on my work computer.
I've tested this with an aspx file (size ~10KB and ~200 lines of code) and with a smaller one (20 lines).
It seems that with the smaller file there are no problems, so I guess my home test was wrong (it's the file size that made the difference).
Also, I did some test on C# source code; the same thing as aspx(html).

It seems that the regex '/' eats a lot of CPU and you can reproduce the problem using larger files (at least a few hundred lines of code).

7

Re: Incremental search bug [ViEmu 2.0.37]

Ok, I'll try to reproduce it in aspx or C# (it might make a difference). There is one thing I don't understand about the reproduction steps: I undertand you trigger it by typing //<cr> in normal mode, and moving around is slow after that. What I don't understand is the point that the search doesn't succeed - // should match at every single position. When I try it, pressing 'n' advances one character each time. There may be a problem that a zero-width highlighting mark is being inserted at every character, which may cause the slowdown.

I'll let you know what I find out. Thanks for the feedback and best regards,

  Jon

8

Re: Incremental search bug [ViEmu 2.0.37]

I've included a fix for this in 2.0.47, it should prevent the slowdown:

  http://forums.ngedit.com/viewtopic.php?id=127

Let me know if something doesn't work fine.

Best regards,

  Jon

9

Re: Incremental search bug [ViEmu 2.0.37]

Hello,

Thanks for your reply. The issue is gone for the '/' search. But the problem still exists sad
Sorry, but I should have performed this test from the begining and show my results.
If you search for '.' (/.<CR>) you'll run into the same thing (slowdown when navigating).
All chars in the .cpp are highlighted, so I guess this may be a hard thing to solve since I have more than 15.000 matches for this regular expression.

The test was performed on a 15Kb file with 600 lines of C code.
I've also tried the same thing with scite (http://www.scintilla.org/SciTE.html) and with gvim (Win32) and everything went ok.

10

Re: Incremental search bug [ViEmu 2.0.37]

I think that's a limitation of the underlying Visual Studio custom-text-markers support. There is not much more I can do about it, as I have to use that support to highlight the text. SciTE and vim probably use a more efficient system to store and manage markers.

The reason I don't think it is a severe problem is that searching for things which match in many places is rarely useful, so it's unlikely to cause a serious problem. But I will listen if you have a real-world case where it's a stumbling block!

Thanks for the feedback,

  Jon