Why do text editors have problems with long lines?

Question

If you copy the text I provided in the link below and paste it into a text editor (I tried several ones: gedit, notepad, phpstorm, but also command-line editors like nano) you will experience difficulties.

http://pastebin.com/5dqT7mFm

Here are a few I noticed during my tests:

• very strange text rendering effects
• text selection is not possible anymore
• heavy CPU consumption
• editors stop responding (sometimes they even crash)

I also noticed, that those problems will not occur, if I enable the text-wrap functionality in the respective text editor.

What I would like to know is, why text editors have this kind of problems with long lines? Is there a reasonable explanation for this behavior?

Answer 1

What I would like to know is, why text editors have this kind of problems with long lines? Is there a reasonable explanation for this behavior?

I'm the author of the Zeus IDE so I'll give my take on why this is the case.

One major reason is the existence of the tab character. Let me explain.

Because the text editor must assume the line might contain tab characters, the only way it can properly handle those tabs is to parse the line from left to right, always starting at the first character of the line.

To understand why, consider these two lines of code where ^ represents the tab character:

This is line one with no tables
This line has a ^ tab character

If the tab size is 8 this will need to be drawn like this:

This is line one with no tables
This line has a          tab character

If the tab size is 4 it will drawn like this:

This is line one with no tables
This line has a     tab character

But the length of both those lines is exactly the same at 31 characters.

So to draw the line correctly the editor had to parse the line left to right, always starting at the first character of the line.

Naturally for long lines this drawing can be slow.

Now consider this second case where the | character represents the cursor:

This is line one with no |tables
This line has a          tab character

In the case above the cursor is at index position 25 in the line, which also represents cursor position 25 on the screen (as the line contains no tabs).

Now let’s assume the user moves the cursor down one line as shown below:

This is line one with no tables
This line has a          |tab character

Now the cursor is still at cursor screen position 25 but because of the 8 character tab that represents the index 18 location for that line.

To figure this out the editor needed to run a calculation on the line checking for tabs along the way and once again for long lines this takes time.

These are just two examples of the index to cursor, cursor to index mappings that need to be done by the editor.

Those same calculations will also be needed for keyboard events, mouse clicks, text marking, text cut/copy and paste etc etc.

I also noticed, that those problems will not occur, if I enable the text-wrap functionality in the respective text editor.

When you turn on text-wrap you have effectively taken one long line and made it into many shorter lines and that in turn speeds up the tab calculations mentioned earlier.

PS: Zeus did handle your 286,721 character line, but like most editors it does not respond well to a file with that length of line.