Community
Participate
Working Groups
See bug #23305. I am debugging an application that has XML text. This results in very large strings or files with no line seperators. For example, one of my files has a line with 27,000 characters. Such large unbroken lines cause eclipse problems in a number of areas. 1) The editor simply cannot handle such a large line and ends up throwing an exception warning. The line is a mess of characters. It looks line the line is overwriting itself.
It's a StyledText bug. StyledText seems to wrap around if a line contains more than ~12530 bytes. This seems to be the case for linux-gtk as well. Here's the test case: ---8<--- package bugs; import org.eclipse.swt.SWT; import org.eclipse.swt.custom.StyledText; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class LongLinesBug { private static String createLongLine() { StringBuffer buffer= new StringBuffer(); for (int i= 0; i < 1253; ++i) { String string= "" + (i * 10); buffer.append(string); for (int j= string.length(); j != 10; ++j) buffer.append(' '); } return buffer.toString(); } public static void main(String[] args) { Display display= new Display(); Shell shell= new Shell(); StyledText text= new StyledText(shell, SWT.NONE); text.setText(createLongLine()); shell.setLayout(new FillLayout()); shell.pack(); shell.open(); while (!shell.isDisposed()) if (!display.readAndDispatch()) display.sleep(); display.dispose(); } }
Bug in Windows. We can't work around this because it depends on the display driver and we can't determine the limit programatically. Funny that the GTK display driver seems to have the same bug.
*** Bug 182413 has been marked as a duplicate of this bug. ***
*** Bug 189050 has been marked as a duplicate of this bug. ***
*** Bug 49867 has been marked as a duplicate of this bug. ***
*** Bug 199991 has been marked as a duplicate of this bug. ***
*** Bug 201851 has been marked as a duplicate of this bug. ***
So does someone have a recommendation for addressing this particular bug? If it's a GTK issue on Linux, has it been reported? If not, can someone who understands the problem help by reporting it? If you haven't figured out, I would really like to see this resolved. :)
*** Bug 68116 has been marked as a duplicate of this bug. ***
*** Bug 247834 has been marked as a duplicate of this bug. ***
*** Bug 353197 has been marked as a duplicate of this bug. ***
*** Bug 371522 has been marked as a duplicate of this bug. ***
*** Bug 157312 has been marked as a duplicate of this bug. ***
*** Bug 256160 has been marked as a duplicate of this bug. ***
*** Bug 371547 has been marked as a duplicate of this bug. ***
*** Bug 372241 has been marked as a duplicate of this bug. ***
*** Bug 375202 has been marked as a duplicate of this bug. ***
*** Bug 388708 has been marked as a duplicate of this bug. ***
(In reply to Steve Northover from comment #2) > we can't determine the limit programatically. Yes we can, at least well enough to know when it starts to get fishy. When I add the following in TextLayout#shape(long, StyleItem) line 3501 right after "OS.ScriptPlace(..., abc);", then I get a horizontal scroll bar and see logging output as soon as the line goes empty: if (chars.length > 100 && abc[1] == 0) { abc[1]= 10 * chars.length; System.out.println("bug, setting abc[1] to " + abc[1]); } We can use a more conservative limit, but you get the point. I know a run can contain 101+ zero-width characters, but it's perfectly OK to make that case more expensive. This bug has too many dups for a WONTFIX. Reopening. The right solution would be to render runs in smaller chunks when the OS is incapable to comply. A maybe less complex solution would be to just render as many characters as possible and then draw something like ###OS_GRAPHICS_LIMIT_REACHED### or write the problem to System.err.
*** Bug 443433 has been marked as a duplicate of this bug. ***
Created attachment 247084 [details] Snippet to find the limits Note that the Windows bug is not bound by the character count but depends on the actual line contents! The attached snippet finds the upper limit for the pattern from comment 1. If you use the commented pattern construction method // String string = "x" + (i * 10); // works! , then it works with lines that are millions of characters long.
Hi Markus, are you working on a fix for Mars ?
(In reply to Niraj Modi from comment #22) > Hi Markus, are you working on a fix for Mars ? No, I had not planned to, but I would support a fix in RC1.
*** Bug 492066 has been marked as a duplicate of this bug. ***
This can be worked around with Word wrap (Alt+Shift+Y), at least with PDT.
*** Bug 517812 has been marked as a duplicate of this bug. ***
*** Bug 453288 has been marked as a duplicate of this bug. ***
*** Bug 533293 has been marked as a duplicate of this bug. ***
*** Bug 537659 has been marked as a duplicate of this bug. ***
Before I start working on this, is there someone else trying to fix it at the moment?
The issue turned out to be quite complicated, with multiple different limits in it. Problem 1: 'ScriptShape' WINAPI fails with E_FAIL for OpenType fonts when the length of the string is over 32000 (0x7d00) characters -------------------------------- Notes: a) 32000 is hardcoded in 'gdi32full!GenericEngineGetGlyphs' Windows function. So it's not exactly a bug, just lack of documentation. b) 'gdi32full!GenericEngineGetGlyphs' is called with this stack: gdi32full!GenericEngineGetGlyphs gdi32full!ShapingGetGlyphs gdi32full!ShlShapeOT gdi32full!ScriptShape c) 32000 explains why attached snippet fails beginning with 3201 (it creates 10 characters per every 'ten'). d) Setting 'SCRIPT_ANALYSIS.fNoGlyphIndex' to 'TRUE' causes 'gdi32full!ScriptShape' to call 'gdi32full!GDIShape' instead, which does not have this limit. e) Using non-OpenType font causes causes 'gdi32full!ScriptShape' to call 'gdi32full!NumShape' instead, which does not have this limit. Problem 2: 'ScriptShape' WINAPI fails with E_INVALIDARG when "maximum glyphs" parameter is over 65535 (0xffff) characters -------------------------------- Notes: a) "maximim glyphs" of 65535 means no more then 43679 characters. b) 'SCRIPT_ANALYSIS.fNoGlyphIndex' does not help here. c) Non-OpenType font does not help here. d) I didn't research if there are other workarounds. Problem 3: 'ScriptPlace' WINAPI fails with E_FAIL when the length of the string is over 32000 (0x7d00) characters -------------------------------- Notes: a) 'SCRIPT_ANALYSIS.fNoGlyphIndex' still helps. b) Non-OpenType font does not help here. Problem 4: 'ScriptTextOut' WINAPI fails with E_FAIL when drawn area exceeds 32767 (0x7ffff) pixels -------------------------------- a) Limiting number of characters depends on font size. b) 'SCRIPT_ANALYSIS.fNoGlyphIndex' does not help here. c) Non-OpenType font still helps. d) I didn't test for precise number here. Maybe it's 32768 instead. Overall -------------------------------- Of these problems, for #2 I don't have known workarounds. This probably means that splitting text into smaller runs is unavoidable.
Created attachment 276390 [details] Native snippet to demonstrate various limits
Moving out of 4.10. Please re-target as required.
even if this is not fixable in the short term, maybe its possible to show a warning/error box when opening an editor that has such long lines. the current behavior, just to let the editor run into these display bugs is really unacceptable b/c i never would have expected that such issues would still exist these days. but then again, windows also still has a limit of 250 chars in a normal path -- so i guess i should have known and not get so puzzled over not seeing all of my long un-pretty json string in the editor. :sigh:
Using word wrap is not an option here?
(In reply to Andrey Loskutov from comment #35) > Using word wrap is not an option here? Not really. In CDT we are indeed preventing word wrap in some cases because of Bug 168557
*** Bug 541104 has been marked as a duplicate of this bug. ***
*** Bug 446862 has been marked as a duplicate of this bug. ***
Hello, I also have a customer with a problem similar to 492066 (duplicate of this one): - using the base Eclipse 4.6.3 - have a file with 10008 long lines (only 3) and the character on column 175 is invisible unless the length is reduce to 4854. OR, if they remove the character (such as N or O) from the line and then use "Undo", the character on column 175 is displayed in the text editor. This is specially more visible when you compare 2 files (with the same length) where the only difference is the character in column 175. The compare works but it cannot display the character in column 175. I will attach the 2 sample files that you can test with the text editor.
Created attachment 280390 [details] column 175 character invisible in text editor
Hello, just encountered this bug. I've spent 4 hours of debugging why information is missing after exporting 3D scene from Autodesk Maya to Collada format until I realized, that it's Eclipse simply not displaying the text. The exported file is in xml format containing a lot of text beetween opening and closing tags (<p> lots of text here </p>). Eclipse was just showing "<p> </p>" and it was very hard to guess that text was hidden by editor. I think this bug definitely should be fixed ASAP, nobody expects that editor hides information. There is no such problem when opening same file in Windows Notepad or FAR editor.
*** Bug 390576 has been marked as a duplicate of this bug. ***
(In reply to Alexandr Miloslavskiy from comment #31) > Overall > -------------------------------- > Of these problems, for #2 I don't have known workarounds. > This probably means that splitting text into smaller runs is unavoidable. Hi Alexandr - I am coming back to this bug again and the native example you gave was very useful to understand the problem. Did you ever propose a solution or come up with anything to split the text into smaller runs?
Not really. Shortly after posting the summary I switched to other tasks and never really came back to this one.
Alexandr in comment #31 identified a number of failure conditions in the win32 API that could cause this visible bug. I think I have a fix for at least some of the issues, including adding some of the missing error handling. Stay tuned for a gerrit or two in the coming days.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187688
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187690
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187689
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187687
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187689 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=11c342414827ca0a23538505a0e5af6d682a53b7
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187690 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f3a61da4d5bb69065236e4c4b966416d979d0fe8
Thanks Jonah for the bug fix and Alexandr for the review/test. Resolving now.
Verified using 100k+ characters in single line on Win10 using Build id: I20220106-0000
Thanks Niraj for verifying this. The fix works for me too on current releases on Windows. However it still can fail on older versions. I have access now to a Windows Server 2016 (which goes mainstream EOL tomorrow) and it still demonstrates this problem on shorter lines. AFAICT it shows Problem 4 from Comment 31. I suspect this will be fixed by a full implementation of https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187695 (Bug 577238)
Thank you Jonah Should this then be reopened? Could someone at least indicate which Windows versions would qualify as "current"?
I'm of two minds on reopening. This bug is fixed on supported platforms (afaik). As for what is supported, that is defined in https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_23.xml target environments.
Thank you Jonah. But I am afraid that only defines which environments are methodically tested. So other environments may or may not be supported. Unfortunately, I am not aware of an actual description of what platforms are supported. In any case, it would be good if we could determine which minimum Windows version(s) are needed for the fix to apply.
(In reply to Philippe Cloutier from comment #57) > In any case, it would be good if we could determine which minimum Windows > version(s) are needed for the fix to apply. :-) Please provide any such details. Windows 10 (i.e. the target platform from the plan) is supported. I have sporadic access to a Windows Server 2016 to test against. I don't have access to Windows 7, 8 or any other old version.
wow, this took almost 20 years. gratz for staying that long alive as a viable IDE
@Jonah unfortunately this caused regression, see Bug 579335
