Author Topic: SE2016 RC1 display issue  (Read 2324 times)

rajkej

  • Senior Community Member
  • Posts: 336
  • Hero Points: 14
SE2016 RC1 display issue
« on: September 13, 2016, 02:55:55 PM »
I have a .h file (C/C++ mode) that has two lines that are very very long (as in >600,000 characters). The line is a string of hex characters. SE displays lines like this ok when I first paste them into an "untitled" and unsaved document or if I don't add any extension to the document (Document is Plain text mode). But once they are in a .h file (Document is C/C++ mode), SE breaks up the display at very weird locations as you can hopefully see in the attachment. I just noticed this with SE 2015 and SE2016 has the same issue. I haven't been able to find any setting to get SE to not break the lines up. When I change SE to display using "View->Soft wrap" then it gets a little better but still breaks the lines up on weird boundaries as in the second attachment.

I have adaptive formatting turned off. I've tried C/C++ settings such as Special Characters on/off, comment wrap on/off and a few other random ones.

Any suggestions on what settings to try changing or if this is a bug? I attached an example file.

I have seen SE2015 display line numbers with negative signs when I have this issue also but I haven't been able to reproduce that issue in SE2016 RC1.


Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: SE2016 RC1 display issue
« Reply #1 on: September 13, 2016, 03:33:18 PM »
I order to avoid absolutely horrible performance, SlickEdit will break long lines up multiple lines of about 4k each (Tools>Options>File Options>Load> Wrap line length). I wouldn't recommend making this much large since the display performance will degrade quickly. The color coding doesn't support correctly color coding this kind of multi-line string yet.

The code for chosing where to break the line is very tricky. I'll see if there's a way to make the lines break in more even chunks for this case.

When I really need to view long lines without them being broken up, I give SlickEdit the sunny day scenario. I make the file a .txt file (no color coding), turn of softwrap, make sure I'm using a fixed font, and if necessary open the file as SBCS/DBCS (definitely needed for Mac and Linux to override default Utf-8 encoding). Seems like we could use an automated way to open a file in the sunny day scenario. This won't work if the file contains Unicode characters.

rajkej

  • Senior Community Member
  • Posts: 336
  • Hero Points: 14
Re: SE2016 RC1 display issue
« Reply #2 on: September 13, 2016, 03:47:05 PM »
Wrapping the line length at some boundary makes a lot of sense other than the randomness I seem to see with the current settings. I've seen the performance go to crap a few times with the 600K columns. It would be nice to have the soft wrap or the file options->load->wrap line length be applied consistently.

I find it interesting that "Plain text" mode doesn't wrap the lines as well. Is that expected?

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: SE2016 RC1 display issue
« Reply #3 on: September 13, 2016, 04:42:53 PM »
SlickEdit only splits up the lines if there will be a performance problem. The sunny day scenario can handle really long lines.

The code for splitting lines up is complex. It has to try many heuristics so that color coding looks right. I think the fact that there are no spaces is giving it grief.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: SE2016 RC1 display issue
« Reply #4 on: September 14, 2016, 02:20:03 PM »
I wasn't able to come up with an algorithm to split this long line better. The crux of the problem is that once this line which was entirely string color is split, it ends up being multiple tokens of junk. The split code attempts to split on a token color change. That logic has to remain.

If this code color coded the entire line first, there wouldn't be a problem. However, this is a bad idea because SlickEdit could run out of memory trying to color code a huge line (I think the memory required is about ~3x line length). The current algorithm requires very little memory.

rajkej

  • Senior Community Member
  • Posts: 336
  • Hero Points: 14
Re: SE2016 RC1 display issue
« Reply #5 on: September 14, 2016, 02:51:25 PM »
Well bummer. Thanks for trying. Luckily I don't need to edit those types of lines very often. Maybe I'll make a macro to break the line up in the source file instead.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: SE2016 RC1 display issue
« Reply #6 on: September 14, 2016, 03:15:55 PM »
I'm guessing this code was auto generated. If you have control over that, a byte table with hex values in it would be better. It wouldn't be hard to add this as multiple lines but even if you didn't, SlickEdit would break this up much better.

Code: [Select]
const char p[] = {(char)0x34, (char)0xff, (char)0x00};