Synchronize with file instead of with editor?

[allefeld]

Proposed feature: Instead of synchronizing with a running editor, synchronize with a file, including edits made to that file in some editor. Optimally it should be possible to associate a specific textarea / webpage with a specific path.

Background: I often have to edit HTML in tiny textareas on different parts of the same website. To deal with that, I create files in a folder which I edit with VS Code, but I have to constantly copy and paste between the local file and the textarea. Moreover, the site tends to meddle with the code, so I keep the file as a backup.

[fregante]

This is kinda interesting but handling this in the extension would mean adding complexity I don't have time to deal with.

However this would be "super simple" to set up as a node "editor" that accepts connections from GhostText:

1. Start server
2. On incoming connection, ask file path
3. Save changes into the file as they flow in

[allefeld]

Okay, that does sounds simple – but it would still be quite clumsy because the user would still each time have to specify the file name.

A downgraded proposal: Could the client send to the server some kind of persistent id for the textarea, e.g. URL + DOM path? This way the "editor" could remember the association between id and file. For example, that id could be sent with the initial GET request instead of /.

[fregante]

The browser already sends the URL, I don't know if it's just the hostname or the whole URL

[allefeld]

The documentation says "The host of the document's url".

But that's not sufficient for remembering the file association, it would need to be something that identifies the specific page (URL) and the specific textarea in the page.

[fregante]

Could the client send to the server some kind of persistent id for the textarea

I'm not against extending the protocol, see PROTOCOL.md, but generating a truly persistent ID is basically unfeasible, at most you can hope to have an id attribute or something similar

[allefeld]

This SO thread has multiple approaches to generate a DOM path for an element, including in plain JS. The id could be the hash of the DOM path string.

How persistent it is will depend on how dynamic the site is, but it would be better than nothing.

[fregante]

Good luck with that! One extra element and it's off, that's why I said basically unfeasible. I don't even want to get into discussing it, I'm pretty familiar with the limitations and infinite tweaks required to get something that works half the time, and the remaining half is actively worse than not using it.