It's been 7 months since the last article. I've been busy working on my other project. Since it reached the production channel now. It is time to pick up this mess I've started.

Initially I chose to use the tab character AS IS because it would need more rendering logic if I don't. Each key press already had a bunch of things to check and to loop for. So I was very reluctant to add more because it will slow things down drastically.

But now I've realize it was such a bad idea that this character has variable width and rendered differently across browsers. That was just plain stupid to have a real tab character within the screen buffer.

Yup, I am stupid. ( I've spent total of 7 days to figure out how to deal with this Tab character. Yet I couldn't find out a good solution other than rewriting this entire project. So I toke an ugly approach. )

Rendering tabs using space

There are several positioning variables used globally.
aX - X position within a raw line data
X - X position within a rendering line
aPos - Absolute position relative to the raw content data

Since ACTION uses aPos ( Ideally tabs should only affects variables related on the rendering. ) and aX is calculated using X, and aPos is calculated using aX. They are all jammed together.

I've to admit that this is the main problem ( since  day 1 ) causing all the insanity when dealing the this character. Now I have to *hack* through my own code :'(

Behaviour

Because the Cursor position is handled by cursor itself internally, and INSERT is an ACTION command which has a separate namespace internally. By design the INSERT command should NOT intercept the internal working of what the Cursor does. That's why I said I've to *hack* the code because this change is not appropriate by design.

I've also given up handling variable tab width because I don't actually use tab to align my contents. And I am afraid I will lose all my hair on scratching my head when implementing this feature.

Drawbacks & Optimizations

Click here to see the actual implementations
Converting tabs to space with specific tab-width then rendering it to the screen is an exhaustive task. Mainly due to the X position is differed by ( number of tabs × tab-width from aX ), navigating through the tabs needs much more checking and validations.

In fact, I haven't figure out how to optimize this piece of code yet. Counting the tab occurrence requires substring from the content each time which is inevitably resources intensive. Let's just hope the javascript engine will do the copy on write magic for now.

The only way to have fast string manipulation is to native function as much as possible. Since I've already did that. If I want to get it faster I'd probably need a block caching mechanism. Which, regarding to the primary role of the project is to facilitate light-weight online code sketching.