Add source to TextDocumentChangeEvent

[jrieken]

It sometimes useful to know how a text change was triggered esp for the . feature in VIM. See #1431 for more on this.

[jrieken]

@rebornix I believe I have not yet understood what the . feature is about and why it needs additional API. If replaying the last VIM command is the goal it could be done from within the extension, correct? Replaying arbitrary other commands doesn't make sense since they are unstructured and not always about text or the editor (like previewHtml for instance). Similar is the document change event which can happen for many reasons, typing, formatting, search&replace etc.

Can you write some pseudo code that consumes the API you wish for?

[rebornix]

@jrieken maybe it's because I didn't describe it perfectly. Vim's . is used to repeat last change. Speaking of last change, it consists of two scenarios

1. Last change made in Normal mode. For example, if you run dw to delete current work, when you run ., Vim will help run dw again. So while we implementing . in Vim extension, we just need to record last user keystroke combination, which is d + w in this case and repeat these two keys if user types .
2. Last change in Insert Mode. For example, user types i to enter Insert mode, type abc then type esc to switch to Normal Mode. So if user types ., Vim will insert abc at current cursor position. So while we implement it, we record users last input, which is abc in this case. Then if user types ., we insert abc to the editor.

Firstly, we are not repeating Code's commands. Previously when I and johnfn described this feature, the command we are referring to is Vim's command, which is just keystroke combination. Since it's not intuitive and confusing, let's just forget it. Vim has no idea about Code's commands, so we just need to focus the content change.

Speaking of content change, if the change is caused by Code's built-in commands instead of Vim's key combinations, I think it's Okay that . can not repeat this change. Vim's . should only repeat the content change caused by Vim's key combinations.

Hope above describes . well.

[rebornix]

As I said above, it's Okay that . can not repeat content change made by Code command. But sometimes, a content change may be made by both Vim keystrokes and Code.

A good example is: enter Insert Mode, type ab<Tab>, click <Esc> to enter Normal Mode. Then run . to repeat last change.

If there is no autocomplete, everything is good. We record ab<Tab> then when users type ., we just need to insert ab<Tab> again. But when autocomplete is turned on, the text we record (ab<Tab> in this case) is not the real content change sometimes (In JavaScript, the real content change is abstract). Our way of repeating last change will definitely fail.

The reason we need to record keystrokes in Vim extension is we can't access Code's change history. When we type ab<Tab> then run ctrl-z, Code will revert the inserted abstract. Apparently Code knows last change is abstract, not ab<Tab>.If we can read Code's history, then we can directly know what's to repeat instead of guessing ourselves.

[drew-wallace]

This would be helpful so I can choose not to do an edit if the source of the trigger event was from a remote user: #11418

[drew-wallace]

It would be helpful for the source to be really specific. A few examples:
Typed something: typed
Typed something in a peek window: peek.typed
Pasted something: clipboard
Used Extension_A: extension.Extension_A
Used Command_A: command.Command_A
Actually, allowing the source to be user defined would be fine too.

Here's my use case:
I'm working on a remote pair programming extension and when a remote user makes an edit, the local user receives the edit, but the local user's onDidChangeTextDocument picks up on it and triggers the same edit on the remote user, which causes an infinite loop.

Having the source say that the edit was made from my extension would allow me to filter edits and not cause an infinite loop between the local user and remote user.

[drew-wallace]

@jrieken Any update on this issue for my use case?

[jrieken]

No, we actually don't have the information internally in the editor. It is a larger effort to which are aren't fully committed yet

[solvingj]

I vote for somehow enabling the functionality @drew-wallace is trying to create, although it's a bummer that it's not easy.

As a competitive matter, here is a list of editors that have managed to add in support for this feature to be built, and where Floobits has added it:

https://floobits.com/help/plugins

[jrieken]

Closing because this issue is without actionable information.