Well, I thought that was pretty specific information to reproduce this bug, actually...
But I'm not going to upload a 254MB file full of private info, so I've snipped this together:
Just do a Find/Replace All to replace the entity "…" with "...". You'll see that only every OTHER of the consecutive entities are found and replaced, and the others on further passes. The filesize clearly makes no difference, it's either not resetting the offset correctly after each find, or the & or semicolon in the search string are throwing it.
I'd also say that in trying to cut that file down, trying to do a mass selection (holding the cursor down as you drag down and below the window to allow it to scroll so you select a very large block of text) in that 250MB file was HIDEOUSLY slow, worryingly so for software that I am sure is otherwise well stripped-down. I have the SysInternals Process Explorer running in the taskbar and while scrolling it fills the activity graph with 100% red rather than the usual 100% green on full CPU utilisation. From the helpfile, if it helps pinpoint the problem:
For comparison, I tried the same 250+MB text file in both WordPad and Hutch's QEditor and the same large block select positively zipped through the file at high speed from start to finish in both. I can only assume that however you're drawing/updating the window is the bottleneck. In fact, it is so slow that while doing the drag and select, you can see the last line at the bottom of the window repeating as you scroll before being overwritten with the new line.
For reference, I'm using a 2.4GHz Northwood P4 with 512MB memory (and a 1GB swapfile) on a mainboard with embedded Intel graphics at the moment, but the fact that the other two word processors aren't affected by those limitations means that the problem is in HiEditor's scroll/screen handling.
Attached File ( Number of downloads: 18 )