Add hard wrap limit option to console

[iloveeclipse]

Coming from #2283 & #2466.

While we can prevent UI freezes if console output limit is set, we don't see reliable way yet to prevent it with unlimited output. At least on Linux we run into underlined system libary limits with very long lines.

The proposal is to add hard line wrapping limit option to console (for both limited/unlimited output mode), which would forcibly split very long lines by injecting new line characters into output. This option should be disabled by default.

@trancexpress : please investigate whether it is possible and if yes, provide a PR.

[merks]

Just glancing at this I think "be careful not to split unicode surrogate pairs when adding a line-break" and "consider that line breaks might be (are) different on windows".

[laeubi]

I would say there should be a limit that simply truncates the line!

The reason is that in almost all cases where such long lines appear it is more by accident than by intend and become unusable. The same also happens with the text editor by the way if one unluckily opens e.g a js file that is minifed to one consecutive line what freezes whole eclipse!

[trancexpress]

See https://gitlab.gnome.org/GNOME/pango/-/issues/884 for the actual problem.

Note that if this is the only problem, we might somehow workaround it instead.

[iloveeclipse]

The reason is that in almost all cases where such long lines appear it is more by accident than by intend

Not sure where you get this insights. In our case it is intentional output generated by test execution, where engineers are dumping chip test results into console for data logging / inspection. This is a recurring problem across different customers, so it is not accidental.

[laeubi]

The reason is that in almost all cases where such long lines appear it is more by accident than by intend

Not sure where you get this insights. In our case it is intentional output generated by test execution, where engineers are dumping chip test results into console for data logging / inspection. This is a recurring problem across different customers, so it is not accidental.

Not sure why your case is always the common case... Yes there could be cases but from my experience in many different projects and companies it is not the common case and eclipse is used in many other context where it simply is not that "engineers are dumping chip test results into console for data logging / inspection" (but rather in such case redirect ti to a file for example).

So I can just say that a sensible default (!) would be to cut of the line as no one literally is reading a 1.000.000 character long line and it is bad UX and shortening such long text is good practice. This does not mean one can't have an option to

• not shorten it at all and not wrap (current)
• maybe have enable autowrap behavior like e.g gedit has

So simply instead of having one "boolean" choice adding e.g. three options would be much more generic and cover more use cases.

[iloveeclipse]

So simply instead of having one "boolean" choice

Not sure where did you get that, this was never proposed. Obviously if a hard wrapping is technically possible, there must be the line limit given at which the hard wrapping should happen, and that must be a preference.

maybe have enable autowrap behavior

It is already there.

[laeubi]

Not sure where did you get that, this was never proposed. Obviously if a hard wrapping is technically possible, there must be the line limit given at which the hard wrapping should happen, and that must be a preference.

Full ack! But what I have proposed is that given we have this "hard limit" I found that it would be often usful (also missing feature in gedit for me) to not wrap but cut of the line with ellipsis.

So the "hard limit" should not only apply to line wrap:

1. limit set but line wrap disabled -> cut of the line
2. limit set but line wrap enabled -> force wrap it at that limit

so regardless of what mode is used have an option to limit the length (e.g. because its getting ultra slow otherwise or even messed up under windows). And then I think its fine to even set this to a reasonable value by default (e.g 10_000).

[trancexpress]

I've opened: #2494

There are some problems though.

1. Limits seem to be set in parallel to console showing output, the way its currently done for the console character limit:

"Worker-1: Creating console for /usr/lib/jvm/java-21-openjdk/bin/java (Mar 1, 2026, 2:01:45 PM) [pid: 119882]" #73 [117501] prio=5 os_prio=0 cpu=1355.15ms elapsed=201.08s tid=0x00007f1a251ca240 nid=117501 at breakpoint [0x00007f1964ffe000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.ui.internal.console.IOConsolePartitioner.setLimitLineLength(IOConsolePartitioner.java:302)
        at org.eclipse.ui.console.IOConsole.setLimitLineLength(IOConsole.java:266)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.init(ProcessConsole.java:692)
        at org.eclipse.ui.console.AbstractConsole.initialize(AbstractConsole.java:242)
        at org.eclipse.ui.console.AbstractConsole$Lifecycle.consolesAdded(AbstractConsole.java:64)
        at org.eclipse.ui.internal.console.ConsoleManager$ConsoleNotifier.run(ConsoleManager.java:151)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
        at org.eclipse.ui.internal.console.ConsoleManager$ConsoleNotifier.notify(ConsoleManager.java:172)
        at org.eclipse.ui.internal.console.ConsoleManager.fireUpdate(ConsoleManager.java:248)
        at org.eclipse.ui.internal.console.ConsoleManager.addConsoles(ConsoleManager.java:215)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager$ConsoleCreation.run(ProcessConsoleManager.java:78)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

"main" #1 [114186] prio=6 os_prio=0 cpu=11496.25ms elapsed=210.92s tid=0x00007f1a2401bad0 nid=114186 at breakpoint [0x00007f1a2bffd000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.ui.internal.console.IOConsolePartitioner$QueueProcessingJob.processPendingPartitions(IOConsolePartitioner.java:832)
        at org.eclipse.ui.internal.console.IOConsolePartitioner$QueueProcessingJob.runInUIThread(IOConsolePartitioner.java:799)
        at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:148)
        at org.eclipse.ui.progress.UIJob$$Lambda/0x00007f19acb24d60.run(Unknown Source)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
        - locked <0x000000072b000990> (a org.eclipse.swt.widgets.RunnableLock)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5035)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4500)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1051)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
        at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:684)
        at org.eclipse.ui.internal.Workbench$$Lambda/0x00007f19ac1eb5c8.run(Unknown Source)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:583)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:185)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:219)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:149)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:115)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:467)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:298)
        at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base@21.0.10/DirectMethodHandle$Holder)
        at java.lang.invoke.LambdaForm$MH/0x00007f19ac016800.invoke(java.base@21.0.10/LambdaForm$MH)
        at java.lang.invoke.LambdaForm$MH/0x00007f19ac016c00.invokeExact_MT(java.base@21.0.10/LambdaForm$MH)
        at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@21.0.10/DirectMethodHandleAccessor.java:155)
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@21.0.10/DirectMethodHandleAccessor.java:103)
        at java.lang.reflect.Method.invoke(java.base@21.0.10/Method.java:580)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:615)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1415)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1387)

So testing needs to be done with a small delay, until we solve this problem (however we want to do that):

package test;
public class TestConsoleHang {
    public static void main(String[] args) throws Throwable {
        Thread.sleep(1_000);
        int N = 10_000;
        int M = 2;
        byte[] b = new byte[N];
        for (int i = 0; i < N; ++i) {
            b[i] = (byte) (49 + (i % 9));
        }
        String s = new String(b);
        for (int i = 0; i < M; ++i) {
            System.out.println(s);
        }
    }
}

2. Problem mentioned here is also introduced by this PR: Trim console lines that are longer than limit #2466 (comment)

3. Writing the code was surprisingly finicky, I don't have high confidence in it. We have a continuous stream of output we must deal with, which IMO makes the requested limit complicated to implement.

4. We have console word wrap, how exactly do we explain to the user why we have also a preference that does the same, but is elsewhere?...

Overall IMO we should look for a better solution than what is suggested here. E.g. some way to workaround the slow Pango code. If users run into the problem but we have no fix, they should:
a) not dump MBs of data in the console, since that is never good for performance (and allegedly the users mentioned by Andrey care about performance), instead they should use file I/O
b) apply the console character limit

I.e. after giving this a shot, I wouldn't continue in this direction.