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
Created attachment 148810 [details] Code after obfuscating it three times
Created attachment 148811 [details] Minimal example
Created attachment 148812 [details] Screenshot of the minimal example
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.
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.