pnotepad.org forums

Programmer's Notepad Forums

1. 

   LockeZ
   Member

   I have here a text file, 2415 lines long. I am attempting to find-and-replace the line breaks with the string '" OR "' (without the single-quotes). This results in one very long line - 66984 characters long to be exact.

   After performing the find-and-replace, everything past character 65536 is garbled. The info bar at the bottom of the screen tells me that the cursor is currently at cursor 66984 (the end of the document) but the screen view is at character 65536 despite being "scrolled all the way to the right" on the horizontal scroll bar. Scrolling further right shows garbled text as in this screenshot:

   http://burger.sandwich.net/temp/pn_bugreport.png

   You can see my cursor at char 65535 there, one character before it starts being garbled.

   Deleting any of the text before char 65536 or typing any new text before that point causes it to still be garbled starting at char 65536.

   In the prior stable version of Programmer's Notepad, there was not a limit on line length and this odd behavior did not occur.

   Posted 2 years ago #
2. 

   simon
   PN Developer

   Thanks, what version of Windows is this?

   Also: That is one of the best domain names I've ever seen!

   Posted 2 years ago #
3. 

   LockeZ
   Member

   This computer is running Windows XP Media Center Edition, service pack 3.

   Also, I mentioned that the stable version doesn't have this problem. I would like to add that the previous test build also did not have this problem. I was prompted to upgrade to 2.0.10.1010 when I opened the program last week, and after upgrading this problem appeared.

   Posted 2 years ago #
4. 

   simon
   PN Developer

   Thanks, I don't suppose you know which testing build you were using before? I'm looking into this issue.

   Posted 2 years ago #
5. 

   LockeZ
   Member

   Since I use the program several times a week, and it prompted me to upgrade from my previous version to 2.0.10.1010 when I opened the program that day, it is safe to say that I was using whatever test build was available on the website immediately prior to 2.0.10.1010.

   Posted 2 years ago #
6. 

   simon
   PN Developer

   Thanks. Could you please check whether you have the option to check for testing/unstable upgrades turned on? This would make a big difference as to what the previous version was - 1010 is the first signalled stable update.

   Also, if it's not too much hassle, I'd like you to give the older testing build a try just to see if it shows the problem for you:

   http://pnotepad.googlecode.com/files/pn209970.exe

   Posted 2 years ago #
7. 

   LockeZ
   Member

   I do not have the option checked for testing upgrades.

   I confirmed that the bug happens exactly the same in 2.0.9.970.

   Um, apparently I also confirmed that the bug also happens exactly the same in 2.0.8.718. Maybe I somehow just never noticed this behavior before? Kind of embarrassing...

   I also noticed some abnormalities, though, that conflict with my original report. The line length limit does not always seem to be 65536. Which strikes me as rather odd.

   I have a longer text file, several hundred lines longer, which when I remove all the line breaks is 75816 characters long. This very long line errors starting at character 66116. Some other files errored starting at different points, though most files did error starting at character 65536.

   Some brief testing indicated to me that there must be a "cutoff" after which point it starts erroring at a later character than 65536, but this cutoff point seemed to be based on something other than line length. I have a 90000 character line here that errors starting at character 65536.

   Yeah, so basically, I have no idea what's going on any more.

   Posted 2 years ago #
8. 

   simon
   PN Developer

   Thanks for the update, it's good to know it's not a recent breakage but it would be good to improve on this. Scintilla (the editing component PN uses) has had some issues in this area in the past. The general workaround is to turn on word-wrap which should allow the full text to draw.

   The limitation is based around how Windows measures the text to display on the line. If the line has syntax highlighting then the text is broken into individually measured runs and it's much harder to hit this problem. With plain text a single huge run of text tends to cause this to show up quickly.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.