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).