Bug 453762

Summary:	Long lines break C code highlighting
Product:	[Applications] kate	Reporter:	Alexander Wilms <f.alexander.wilms>
Component:	part	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	christoph, loh.tar
Priority:	NOR
Version First Reported In:	22.04.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Initial Code Code after obfuscating it three times Minimal example Screenshot of the minimal example

Description Alexander Wilms 2022-05-13 21:48:05 UTC

Created attachment 148809 [details]
Initial Code

SUMMARY
The code highlighting stops working when a file contains lines longer than 5360 characters


STEPS TO REPRODUCE
1. Open minimal_example.c in Kate
2. Observe the broken code highlighting

or

1. Go to https://picheta.me/obfuscator, select "Generic FizzBuzz" and click "Obfuscate"
2. Copy obfuscated code, paste it into the editor on the left and click "Obfuscate"
3. Copy obfuscated code, paste it into the editor on the left and click "Obfuscate" once more
4. Copy obfuscated code, paste it into Kate and save it as a C file
5. Observe the broken code highlighting

OBSERVED RESULT
In the first few lines after a newline, the hexadecimal integers are highlighted in yellow, afterwards they are no longer highlighted.

EXPECTED RESULT
The highlighting should be consistent.

After saving and opening the file, the following warning message is shown:

"The file generic_fizzbuzz_obfuscated_thrice.c was opened and contained line slonger than the configured Line Length Limit (10,000 characters).
The longest of those lines was 10,313 characters long"

Clicking on "Temporarily raise limit and reload file" does not fix the highlighting. However, adding a newline somewhere in the sum of hex values results in the highlighting being applied properly after the newline.

I know this is a niche case, but maybe the bug report is helpful anyway.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20220427
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION

Comment 1 Alexander Wilms 2022-05-13 21:48:47 UTC

Created attachment 148810 [details]
Code after obfuscating it three times

Comment 2 Alexander Wilms 2022-05-13 21:49:09 UTC

Created attachment 148811 [details]
Minimal example

Comment 3 Alexander Wilms 2022-05-13 21:49:57 UTC

Created attachment 148812 [details]
Screenshot of the minimal example

Comment 4 Lothar 2022-05-21 18:26:41 UTC

IIRC is this not a bug but a feature :-)

It's some kind of "optimization" to speed up things in most cases. Christoph could explain this in detail. But improvements are probably possible, or desirable.

Comment 5 Christoph Cullmann 2022-07-17 18:04:31 UTC

Yes, this is a feature to avoid spending too much time on highlighting.

Naturally, one could start to add a user configurable limit for this, on the other side, I would assume one can agree that such code is not what you want.

Any reasonable style guide will recommend that you do break up lines at some 100-200 columns, not at xxxx.

Therefore I rather consider this intentional and not a bug to fix.

If you want to step up to make this limit user configurable, merge requests are always welcome, but I don't think we shall spend time on this.