Skip to content

Trim console lines that are longer than limit#2466

Draft
trancexpress wants to merge 1 commit intoeclipse-platform:masterfrom
trancexpress:gh2465
Draft

Trim console lines that are longer than limit#2466
trancexpress wants to merge 1 commit intoeclipse-platform:masterfrom
trancexpress:gh2465

Conversation

@trancexpress
Copy link
Contributor

Fixes: #2465

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR attempts to fix issue #2465, where the console character limit doesn't apply to lines that are longer than the limit. The issue occurs when a single line without newlines exceeds the console's high water mark - the existing trimming logic tries to trim to the start of the line (offset 0), resulting in no content being removed.

Changes:

  • Modified the trim() method in IOConsolePartitioner to handle the case where a single line exceeds the character limit
Comments suppressed due to low confidence (1)

debug/org.eclipse.ui.console/src/org/eclipse/ui/internal/console/IOConsolePartitioner.java:1207

  • This fix lacks test coverage for the specific issue it's attempting to address. The existing testTrim() method only tests trimming with multiple lines (each line is "0123456789\n"). There should be a test that reproduces the scenario from issue #2465: a single very long line (e.g., 100,000 characters without newlines) with the console limit set to a lower value (e.g., 80,000 characters), to verify that the console properly trims the content even when it's all on one line.
						// deal with case of one long line
						cutOffset = Math.max(cutOffset, truncateOffset);
						cutOffset = document.getLineOffset(cutoffLine);

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

debug/org.eclipse.ui.console/src/org/eclipse/ui/internal/console/IOConsolePartitioner.java:1206

  • The comment "deal with case of one long line" is misleading. This logic applies to any line that is longer than the trim threshold, not just when there is only one line in the document. Consider updating the comment to clarify that this handles cases where individual lines exceed the buffer limit, for example: "trim within line if line is longer than buffer limit" or "ensure trimming happens even when line start would keep too much data".
						// deal with case of one long line

debug/org.eclipse.ui.console/src/org/eclipse/ui/internal/console/IOConsolePartitioner.java:1207

  • The fix addresses a specific edge case (very long single lines exceeding the console limit), but there is no test coverage added for this scenario. Consider adding a test similar to testTrim() but with a single very long line (e.g., 100,000 characters without newlines) to verify that trimming works correctly when the high water mark is exceeded. This would prevent regression of the bug described in issue #2465.
						// deal with case of one long line
						cutOffset = Math.max(cutOffset, truncateOffset);

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@trancexpress
Copy link
Contributor Author

Test fails to look into:


org.eclipse.debug.tests.console.IOConsoleTests.testTrim -- Time elapsed: 0.164 s <<< FAILURE!
org.opentest4j.AssertionFailedError: 
Expected string not found in console document. ==> expected: <0123456789> but was: <
012345678>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1156)
	at org.eclipse.debug.tests.console.IOConsoleTestUtil.verifyContentByOffset(IOConsoleTestUtil.java:572)
	at org.eclipse.debug.tests.console.IOConsoleTests.testTrim(IOConsoleTests.java:718)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
 org.eclipse.debug.tests.console.IOConsoleFixedWidthTests.testTrim -- Time elapsed: 0.234 s <<< FAILURE!
org.opentest4j.AssertionFailedError: 
Expected string not found in console document. ==> expected: <0123456789> but was: <
012345678>
	at org.eclipse.debug.tests.console.IOConsoleTestUtil.verifyContentByOffset(IOConsoleTestUtil.java:572)
	at org.eclipse.debug.tests.console.IOConsoleTests.testTrim(IOConsoleTests.java:718)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
 org.eclipse.debug.tests.console.ProcessConsoleManagerTests.testProcessConsoleLifecycle(TestInfo) -- Time elapsed: 0.099 s <<< FAILURE!
java.lang.AssertionError: 
[console has been added] 
Expected size: 1 but was: 3 in:
[org.eclipse.ui.console.IOConsole@128d3d86,
    org.eclipse.ui.console.IOConsole@2ae8a311,
    org.eclipse.debug.internal.ui.views.console.ProcessConsole@1ed3b30]
	at org.eclipse.debug.tests.console.ProcessConsoleManagerTests.testProcessConsoleLifecycle(ProcessConsoleManagerTests.java:88)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

@github-actions
Copy link
Contributor

github-actions bot commented Feb 24, 2026

Test Results

 1 977 files  ±0   1 977 suites  ±0   1h 30m 7s ⏱️ - 5m 36s
 4 743 tests ±0   4 719 ✅ ±0   24 💤 ±0  0 ❌ ±0 
14 229 runs  ±0  14 047 ✅ ±0  182 💤 ±0  0 ❌ ±0 

Results for commit 513a37c. ± Comparison against base commit 418952d.

♻️ This comment has been updated with latest results.

@trancexpress
Copy link
Contributor Author

trancexpress commented Feb 24, 2026

The fail in IOConsoleTests.testTrim is demonstrated by this snippet:

	public static void main(String[] args) {
		String text =
				"""
				first
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				0123456789
				last
				""";
		System.out.println(text.substring(text.length() - 50));
	}

truncateOffset passed to IOConsolePartitioner.trim() is 181 = 231 - 50, 231 being document length and 50 being lowWaterMark. Cutting at this results in:


0123456789
0123456789
0123456789
0123456789
last

(i.e. the output of the snippet above)

While the test expects:

0123456789
0123456789
0123456789
0123456789
0123456789
last

The expectations are due to the code we need to change:

	private void trim(int truncateOffset, boolean truncateToOffsetLineStart) {
		if (document != null) {
			{
				try {
					int length = document.getLength();
					int cutOffset = truncateOffset;
					if (truncateToOffsetLineStart) {
						int cutoffLine = document.getLineOfOffset(truncateOffset);
						cutOffset = document.getLineOffset(cutoffLine);

If truncateToOffsetLineStart is set (and it is in this case), the code will find the line at which truncateOffset is. Then, it will include this entire line in the resulting document. Which is why long lines remain uncut.

IMO the test expectations should be adjusted. @iloveeclipse WDYT?

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

debug/org.eclipse.debug.tests/src/org/eclipse/debug/tests/console/IOConsoleTests.java:719

  • Changing the expected offset to 1 indicates trimming now leaves a leading newline (i.e., trims at an arbitrary offset instead of the start of a line). That seems like a regression from the original “trim to line start” behavior and doesn’t directly validate the long-line limit fix from #2465. Consider keeping the expectation at offset 0 for the normal multi-line case, and add a dedicated assertion/test scenario for a single line longer than the high-water mark (no newline) to ensure the buffer actually shrinks when truncateToOffsetLineStart would otherwise result in cutOffset == 0.
				c.getConsole().setWaterMarks(50, 100);
				c.waitForScheduledJobs();
				c.verifyContentByOffset("0123456789", 1);
				assertTrue(c.getDocument().getNumberOfLines() < 15, "Document not trimmed.");

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Console character limit doesn't apply to long lines

2 participants