. should repeat autocomplete actions

[johnfn]

This is a toughie; you need to integrate with HistoryTracker to diff the document and see what text got added, then store that with the action somehow.

[infogulch]

How does this sound as a game plan:

1. clone() the top HistoryStep
2. edit the cloned HistoryStep's (and DocumentChange[]) cursor start positions to be relative to the current position
3. apply the edited HistoryStep to the document, and push it onto the HistoryTracker stack.

Notes:

• This can only work if the last action was an Insert. Find/replace history changes (& others?) will break this.
• If #496 Merge history changes is merged, this will make . very fast.
• I would tread carefully to ensure the different insert types still behave properly (i, a, I, A etc. aka: move the cursor first, then apply the changes).
• Possible refactor: HistoryChange should own the methods for applying/reverting changes it contains. (Right now it's in HistoryTracker.go(Back|Forward)HistoryStep(). changes should probably be private.)

Thoughts?

[johnfn]

Wow, you really did go for the toughest ones first.

I like the idea of using the HistoryStep for . actions, but what bums me out is that it can't be done in a consistent way. For example, if I have |word differentword and I do dw, then HistoryStep will say I deleted 4 characters, but if I hit . I expect to now delete much more than 4 characters. So then we have to special case it just for inserts, and then special case again for inserts that only insert in one place. But then handling things like Visual Block mode become difficult, and multi-cursor actions also become hard.

The way that I currently do . is that I track every action inside of RecordedState. For inserts, every time the user types a letter, I create a new InsertInInsertMode action that tracks the character that was inserted. Then when the user presses ., all the InsertInInsertMode actions are replayed.

The easiest possible way to get autocomplete to work with our current infrastructure would be like this:

1. Detect that tab has been pressed, somehow. I'm not quite sure how to do this now, but I'm sure there are ways/hacks. VSCode is promising some new APIs to detect tab button presses soon, so we could also just hold out for that.
2. When we do historyTracker.addChange, retrieve the diff from HistoryTracker. This was the text that was inserted when the user pressed tab.
3. Tokenize it into characters and create a new InsertInInsertMode for each one, OR, teach InsertInInsertMode to handle multiple characters and just create a single one.

[johnfn]

Re: Making . fast:

I always start by thinking about the worst possible case when looking for improvements to make. In the case of . the worst possible case isn't . at all, it's macros. (. is like a baby macro.) I would like a solution that improves both . and supports a fast future implementation of macros (which I plan to implement almost exactly the same way as . - just by repeating each action the user made).

I like your solution, but since macros can have multiple inserts and multiple overlapping deletes, I don't think it can speed them up. Getting macros to be fast would be a good deal of work. The problem currently is that every action that does an insert/delete immediately does the full action when you call exec(), so they take a while to complete, and VSCode doesn't allow us to batch atomic actions if they overlap. I think the correct way to make . fast would be like this:

1. Refactor every action such that exec() does not cause it to insert/delete text immediately. Instead, it should return an object that looks a lot like a history step - { type: "insert", location: some position, text: "whatever" }
2. In the normal case of inserting/deleting text in the document, transform the document immediately when you see the object returned.
3. In the case of running . or a macro, merge all these objects together. #496 is a good first start at this.

It starts to sound a lot like HistoryTracker, actually... hmm

[rebornix]

This is fixed already.