Hello,
I don't have the time nor the knowledge to add support for vscode myself. However I can provide help if someone works on that.
I think the easier would be to integrate with an existing LSP server for LaTeX, see #36

Hi, I wrote a simple extension: https://marketplace.visualstudio.com/items?itemName=DominikPeters.texpresso-basic / https://github.com/DominikPeters/texpresso-vscode The technically difficult part was translating character offset into byte offsets.

Thank you, that looks very nice. I am not a vscode user myself so I cannot test however.
Do you mind if I put a link to your extension in the README? Or I can wait if you prefer.

Yes, putting a link sounds good.

I see that you are using a rope data structure for mapping the logical coordinates to byte coordinates, that's a good idea.

I don't know if you have seen, but the protocol also has support for line-indexed changes. That is useful for neovim which have broken byte indices. Would that help with VSCode?
I don't want to discourage you for using rope though, that's totally fine.

Hi, I wrote a simple extension: https://marketplace.visualstudio.com/items?itemName=DominikPeters.texpresso-basic / https://github.com/DominikPeters/texpresso-vscode The technically difficult part was translating character offset into byte offsets.

Thank you so much for your contribution! I will check it out.

Thanks, I tried the lines protocol but couldn't get it to work. VSCode informs the extension about changes by giving a list of changes, each of which is specified by (character offset, character length, replacement text). But if it tells me about several changes in a row, there is no way for me to access the file content in between the changes. However I need that to figure out how many lines are involved by character length and to extend the replacement text to capture the full lines. So I'd still need to keep a copy of the content in a data structure that supports efficient edits and line (instead of byte) lookups. So I went for bytes because my guess was that the overhead for that is lower on the texpresso side.

Now that texpresso-vscode is referenced in the README, I think that this issue could be closed.