Painting issue when editing with collapsed folds

[paul-griffith]

Happens fairly consistently in a custom application. I can get it to happen in RText off latest release. Specifically using Python folding, but I'm pretty sure that shouldn't matter.

I'm hoping to take a look and see if I can fix this, but want to report in case it's something familiar or you have an idea of a possible fix.

[paul-griffith]

Also reproduced in RTextAreaDemo app with the Python sample. Seems to be a race of some kind within folding updating. Pretty consistent replication as follows in RTextAreaDemoApp:

1. Load the Python sample
2. Collapse all folds
3. On line 4 or thereabouts, paste this function:

def something():
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	pass

Whitespace is definitely significant - seems like it happens when a new block gets parsed and added, but overflows the y position of the current last fold in the document. If you use a 'shorter' block of text, you can paste it a few times (and observe more and more of what should be hidden in the fold starting to show) until it overflows, at which point the repeating behavior will occur.

[paul-griffith]

@bobbylight this seems to be related to the hiddenLineCount in SyntaxView#paint (there's a matching problem with the line numbers in LineNumberList). When the document changes (but the folds haven't yet updated) the lines to hide/display end up in an invalid state. I'm not sure what to do to fix that; since folding is debounced (as an expensive operation). I noticed that the hiddenLineCount actually becomes negative when this happens; I tried changing the break in the loop here:

				// Skip to next line to paint, taking extra care for lines with
				// block ends and begins together, e.g. "} else {"
				do {
					int hiddenLineCount = fold.getLineCount();
					if (hiddenLineCount==0) {
						// Fold parser identified a zero-line fold region.
						// This is really a bug, but we'll be graceful here
						// and avoid an infinite loop.
						break;
					}
					line += hiddenLineCount;
					fold = fm.getFoldForLine(line);
				} while (fold!=null && fold.isCollapsed());

But the naive change (if (hiddenLineCount<=0) break;) doesn't seem to fix the issue. But maybe the negative hiddenLineCount can still be a useful indicator? I'm not as familiar with the internals as you are.