jEdit

"Invalid" means the expected behaviour is wrong. If the bug can not be
reproduced due to lack of reproduction recipe, it is a "Works For Me"

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

In my case, this bug is much more discretely documented here:
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764901&group_id=588

I'm happy to mark this bug as a duplicate of the one above.

THIS bug report is incomplete.
Please submit a reproducible test case (a file to parse) along with steps
on how to reproduce.
I will mark this as invalid/pending until additional information is
included.

As elsie wrote below, it also happened in CSS files, so it is NOT specific
to HTML and thus I doubt it is the ecmascript parser that causes the
problem.

Another way to check whether it is the buffer that is corrupt, or just the
textarea, is by splitting and unsplitting the current editpane. If after
creating a new editpane, you still have corruption, then it's the buffer,
but if it's the textarea, then everything should be cleared up after the
unsplit.

Ok first of all, does it only happen with HTML files?
In those files, are there embedded javascripts in <script> tags?
If so, I suspect either the ecmascript parser, or the sidekick folding.
I bet that by disabling one or the other, you won't still have this
problem.
First try not using SideKick folding mode and see if you still get this
problem.

I take that back, I just saw it again. Sorry.

That seems to indeed "fix" my problem, I see a relevant bug in the list
that IS this bug, so thanks!!!

I found the option in the Mouse options. I'll let you know if I encounter
the buffer corruption...

Hmm. I looked in Global Options -> Text Area and there is nothing there
about Drag & Drop. Can you tell me where said conf option is to be found?
Also, for note, I experienced the same buffer badness in a CSS file
repeatedly yesterday, so it's not isolated to HTML mode.

Do you have text area drag & drop activated ?
If yes, try to uncheck this option and check if it still happens

See the screenshot:
http://www.commoner.com/lsimon/JEditBufferCorruption.png

I've actually noticed this quite frequently in 4.3.pre7/8/9 - usually in
HTML mode, and I do have the XML plugin loaded. But it's really quite
rough. If the buffer's long enough, I can scroll down, then back up and
"fix" it. Usually happens after Save. It's unfortunately got me on the hunt
for another editor at the moment, but nothing's as good as JEdit in my
book.

I think that some time ago I have seen a similar behaviour which appeared
only when "quick copy" was activated. Unfortunately I can't find the note I
made then. It was caused by some specific mouse movement, IRC. I don't know
if the text was undoable because I usually noticed it only much later, so
undoing would have meant losing everything I'd typed in the meantime. I was
not using SFTP, though.

I've also seen a repaint glitch like the one Marcelo describes. So far I
could not reproduce it deliberately. When it happens, the first 5 columns
(or so) of some lines are overwritten with garbage. White space is
preserved, IRC. It usually goes away after some scrolling.

Do you have any hint to reproduce that ?
In fact it happened sometimes last year but randomly and I was never able
to reproduce that.
It doesn't happens anymore for me.
What I found is that it happened when I paste text from clipboard, the
text was pasted at cursor position but also in the beginning of the buffer.

Actual text was inserted; I noticed the problem after saving the HTML file
and viewing it in a browser.

Hi Slava,

Was it actual text being inserted, or did it look like a painting problem?
I've been seeing things that look like this some times, but saving the
buffer (which seems to cause a repaint of the whole buffer) gets rid of the
garbage. Still annoying though.