New bug in 2.0.10.1010 – 65536 char line limit

Discussion Forums discussion New bug in 2.0.10.1010 – 65536 char line limit

This topic contains 0 voices and has 7 replies.

Viewing 8 posts - 1 through 8 (of 8 total)
Author Posts
Author Posts
July 24, 2009 at 4:00 pm #653

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.

July 27, 2009 at 10:03 am #16678

simon
Key Master

Thanks, what version of Windows is this?

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

July 28, 2009 at 3:37 pm #16679

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.

July 29, 2009 at 9:13 am #16680

simon
Key Master

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

August 6, 2009 at 2:19 am #16681

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.

August 13, 2009 at 8:28 am #16682

simon
Key Master

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

August 17, 2009 at 5:04 pm #16683

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.

August 19, 2009 at 6:46 am #16684

simon
Key Master

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.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.