Posts [ 10 ]

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.

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.

Re: Incremental search bug [ViEmu 2.0.37]

Thanks for your reply and for the coolest VS plugin

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.

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).

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,

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 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.

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!