CDT Editor split screen problem

[jarsudsco]

I have a problem when editing source code files in the CDT editor. I often use split-screen mode and recently noticed that one window I was using as a reference would suddenly jump to the same position (or close to) the part of the file I was actually typing into in the other window.

This was actually on 2024-03 and I hadn't noticed the usual quarterly update hadn't happened. So did an update, now I have 2024-06. The issue persists but is NOT consistent (as before) - it does not happen every time. It also sometimes happens when clicking save.

Steps required to reproduce (unpredictably) are:

• Edit source file
• Menu->Window->Editor->Toggle Split Editor (Horizontal)
• Scroll one or both windows to different parts of the file
• Type in one window - the other will jump to the roughly the same position (I think it puts the insertion point on the second line of the "hijacked" window.)

This happens roughly 50% of the time I'd say.

Setup: Windows 10 version 22H2, openjdk 22.0.1 2024-04-16, Eclipse Version: 2024-06 (4.32.0) Build id: 20240606-1231

I'm not sure it's relevant but I've also noticed when using "refactor" as soon as I change the symbol I want to rename that line jumps to the bottom of the window. It seems like a similar positioning error and for refactoring is new behaviour I think.

Not sure what else to include, but happy to supply any other info that might help.

Cheers,

Suds

[jarsudsco]

Have I created this issue in the wrong place? It's still happening and it's pretty frustrating.

[merks]

I tried this in the Java editor and the Generic Text Editor and neither behaves this way. Using Open With on the files context menu you can open different editors.

Does this problem only happen with CDT's editor? In that case, you'd need to open the issue here:

https://github.com/eclipse-cdt/cdt/issues

[jarsudsco]

Hi Ed, thanks for getting back to me. I hadn't considered the different editors available, so checked further. I hadn't created a Java project since my last Eclipse workspace problem. So I grabbed a simple Java example from the web, created a project and edited the code with the Java editor. The problem does still occur, but as I mentioned it's unpredictable and doesn't happen on every edit, but once I've found a situation where it does happen it seems to be repeatable. I grabbed two images which I'll try and include here, a horizontal split screen: the "before" image has the top window at the top of the file (lines 1-11) and the bottom window is at the bottom of the file (lines 16-26), the "after" image shows the insertion point on line 8 in the top window where I have typed a single space. The bottom window has jumped to show the edited line, showing lines 8-18.

So this doesn't seem to be restricted to the CDT editor.

Cheers,

Suds

[merks]

It's really weird. Whatever makes it unpredictable, and then it happens consistently after that, just never seems to kick in for me because no amount of editing anywhere causes any scrolling of the other view. I'm also on Windows 10. The inability to reproduce the problem doesn't help. I'm not sure what to say. I don't have a lot of time to spend on such a thing...

[jarsudsco]

I appreciate you will have more significant and well defined issues to look at. Unfortunately I haven't spotted any pattern or set of circumstances that cause it to happen. I'll keep looking. If you do think of anything from my side that might help pin it down just let me know.

[jarsudsco]

I've done some testing and I can add a little more detail on when this occurs.

The inactive window "jumps" if the line number of the line being edited in the active window is less then the line number at the top of the inactive window. I've not seen it happen if the edited line number is greater than those shown in the inactive window. - so a window starting at line 1 never jumps as they only jump to lower line numbers.

This seems to happen consistently using the windows either way round and in both the CDT and Java editors (oh, and the PyDev editor). It also happens in vertical split mode.

[ghernadi]

Hello, I'm facing the same issue, (running on ArchLinux, Gnome ... not sure how much this is relevant though...) .

@merks, may I ask you to try to reproduce it again, but this time with a few enabled code mining settings?

My current settings:

The jumping only occurs once the "Show references" -> "Methods" is active. Without that being active, I do not see this issue happening.

Hope this help

Edit: I could reproduce this issue with a newly initialized workspace with a freshly downloaded Eclipse Java 2024-09-R-linux-gtk-x86_64

[merks]

@tobiasmelcher

Since the issue described here appears to be related to enabling some behavior related to code mining, perhaps you have time to take a look. I really don't have time...

[tobiasmelcher]

Hi colleagues,

I was able to reproduce the problem scenario in windows with the Java editor by enabling all code mining settings in the Java editor (preference page: Java->Editor->Code Minings).

Problem is making the logic inside method org.eclipse.swt.custom.StyledText#handleTextChanged(TextChangedEvent event) which is marked in the following code block with the "-->" sequence. Problem disappears after commenting out this code block.

void handleTextChanged(TextChangedEvent event) {
	int offset = ime.getCompositionOffset();
	if (offset != -1 && lastTextChangeStart < offset) {
		// updating the compositionOffset of the ongoing IME if last IMEs text is deleted meanwhile
		// for example 1.insert IME text 2.open IME menu 3. ctrl+backspace => 4. commit IME would result in IllegalArgumentException
		int compositionOffset = ime.getCaretOffset() + lastTextChangeNewCharCount - lastTextChangeReplaceCharCount;
		// workaround: while ongoing IME non-ime text is deleted it may result in too big compositionOffset
		// for example 1.insert IME text 2.insert space 3.open IME menu 4. ctrl+backspace twice => 5. commit IME would result in IllegalArgumentException
		compositionOffset= Math.min(compositionOffset, getCharCount());
		ime.setCompositionOffset(compositionOffset);
	}
	int firstLine = content.getLineAtOffset(lastTextChangeStart);
	resetCache(firstLine, 0);
	if (!isFixedLineHeight() && topIndex > firstLine) {           
-->		topIndex = firstLine;                                                
-->		if (topIndex < 0) {                                                    
-->			// TODO: This logging is in place to determine why topIndex is getting set to negative values.  
-->			// It should be deleted once we fix the root cause of this issue. See bug 487254 for details.
-->			System.err.println("StyledText: topIndex was " + topIndex    
-->					+ ", lastTextChangeStart = " + lastTextChangeStart 
-->					+ ", content.getClass() = " + content.getClass()   
-->					);    
-->			topIndex = 0;  
-->		}  
-->		topIndexY = 0;  
-->		super.redraw();  
	} else {

Expression !isFixedLineHeight() is only true when code minings are enabled. Without code minings the else branch is executed which does not modify the variable "topIndex". "topIndex" specifies the first visible line in the text editor. It is not clear to me why the value of topIndex (=the first visible line in the editor) is modified in the method handleTextChanged. I would not expect that the text editor is scrolled in a handle... method.
Sorry, I don't understand the intent of the method and cannot really help here.
The experts now need to take over.

With best regards,
Tobias

[jarsudsco]

I'm kind of relieved that someone else has seen this problem. But I'd like to remind everyone it is not limited to the Java editor. I originally described the fault as unpredictable - at that time I had not seen any pattern. But as I pointed out in a follow up post (August 19th) I did identify conditions under which the effect happens consistently - in every code editor I tried (Java, CDT and Python) and with both horizontal and vertical splits. If the edited line is lower numbered than the top line of the inactive window, the inactive window will scroll to the edited line. I can also add that I don't believe I have ever changed any code mining settings - so I presume I have the defaults.

Cheers,

Suds

[mickaelistria]

It looks like the code pointed above is to ensure that the first modified line is always visible on an edit if there are lines of different height. This is not what we want in general for a text editor.
We may want to change the visible position if user has entered (typed, paste...) text, and we want to make it visible in the widget being used. But her,e for split editors, we can have text changing as a reaction of a change in another widget and we shouldn't have this widget reacting.
I remember we have more recently improved the StyledText so that the topIndex and so on are supposed to be better maintained while applying the style change for higher lines, so maybe this story now has a better fix already in place.
So I suggest that you submit a PR just removing this condition alltogether as you tried; and we can consider merging it as soon as 4.35 development start to get more time to get feedback and react.