This is starting to look awesome > w<!!

Still, the most important command I used frequently > and VISUAL LINE is yet to be implement. Way to go!

Command bar

The commands I could found that uses command bar is / and :. Because / is basically :/, thus the command bar is mostly about the :. It toke me about 2 days to finalize the idea. And half a day to make it work.

Observing the command bar behavior

The tricky part is the command bar history, of which you could do some basic back searching by typing some prefixes then pressing Up and Down.

I was trying to decipher what the Up/Down command actually does and what I expected it to do. It looks like I could use the Recorder used for UNDO / REDO commands. But actually it is not. Let's have a look on some examples:


Now when I type :b, and the press Up. The command bar should bring me to the entry :bbb. What if I press Up again now? It should bring to the next matches of original searching of :b which I typed earlier. i.e. :bbaaa.

Initially I stated with saving a stack of input string directly and navigate through the history stack. But then I realize that some characters such as Tab, Line break are actually represented by 2 or more characters. This makes the alignment of the strings in the history stack does not match up. Which leads to more complex implementation that require parsing the history string.

After some struggling I figured an easier way to do it is to treat the input stack as a stack itself. Which means that I should store the keys as a separate element in an array. That solves the alignment issue and does not need the string parsing, yay!

Find - The RegEx transition

Because I could later relate this to the REPLACE command. The first thing I made was the FIND command. The RegEx pattern used in Vim is different from the one in JavaScript. I need to somehow merge between the two RegEx definitions.

I've also made some modifications as well. Normally in coding I would like to escape the ( character instead of using the \( to indicate a regex group. In Vim this was super annoying so I am going to reverse this behavior to convenient myself.

There was also no \0 in JavaScript's RegEx. The solution was to sacrifice the \9 and wrap the input pattern as group \1. Problem solved.

Later I discovered some patterns such as ^, ^.?will throw JavaScript into an infinite loop. But they treated as normal matches in Vim. After some careless ( yes ) inspection. Since patterns like ^, .* are not practical ( and bad ). I've decided to just create a loop guard to stop the infinite loop and tell user the error. ( These patterns are valid in REPLACE )

Replace - impact on moving the cursor

The REPLACE action is actually based on the FIND action. In Vim the replace seems to be done after an actual FIND, which mean the FIND is done once, then replace, then find again.

Doing this in JavaScript is however tedious because FIND moves the cursor - moving the cursor have performance costs. It involves tons of calculation to find out where should the cursor be at the screen, which is one of the drawbacks by using this approach. So to optimize this out the cursor movement should be minimal and need to be done within a single action.

The replace action should not move the cursor at all.

But doing this separates the history between FIND and REPLACE. Although it is not hard to share the history, but I am too lazy to do that. Will implement if I use it frequent enough.

Other commands

Commands such as :w, :q, :registers, :ls, :version were implemented easily because by design it should.

Next

I still need to finalize the argument schema for the input key. I was thinking about keeping a limited stream of key buffers to determine the arguments user typed. This is to handle the range & count input. I still couldn't figure out how to do that currently:\

After the is the VISUAL LINE and >. Visual line is trick because you could literally switch between VISUAL and VISUAL LINE and keeping the previous selection before switching.( try typing v then V and vice versa. )

For the > commands I need to finalize the key schema first. This is related to the SyntaxAnalyzer, which determines how much indentation this line should be.