kaiiiz / obsidian-raindrop-highlights-plugin

An Obsidian.md plugin that syncs highlights from Raindrop.
MIT License
220 stars 12 forks source link

Resync after highlight colour change duplicates highlight #1

Closed robertandrews closed 2 years ago

robertandrews commented 2 years ago
kaiiiz commented 2 years ago

Hi, thanks for the feedback.

This is an expected behavior, as it's hard to keep track of evey highlight in Obsidian. Besides, in my opinion, directly modifying the content of a file is a dangerous operation, and it's something I trying to prevent. (In the current implementation, the new content is appended to the end of the file after rendering.)

The current behavior of updating existing posts is to sync the latest update highlights and append them to the existing posts. As far as I know, the latest update includes:

In your case, you first sync the highlights into the vault. Then, you changed the color of the highlight in Raindrop, which is also treated as a type of update, so the plugin append them into the end of the file.

I think this is something that needs to be documented in the README.

robertandrews commented 2 years ago

Besides, in my opinion, directly modifying the content of a file is a dangerous operation, and it's something I try to prevent.

That's why I assumed, upon sync, you would do a full replace of the whole file content, top to bottom, rather than appending.

The current behavior of updating existing posts is to sync the latest update highlights and append them to the existing posts.

Doesn't appending, rather than replacing, actually leave it possible for the user to modify the preceding doc content, as you warn about above... ?

I'm on the fence about what's optimum there, as I'm still wrestling with what the PKM people define as a literature note etc. But, basically, I see some scope here to use Raindrop and this plugin to serve a combined capture-and-lit/source/ref-note step...

In lieu of Raindrop's Annotation feature (Pro), a user could manually write his own thoughts and interpretations between anx above highlights in to the Obsidian doc. Maybe it would be better to retain the integrity of the Raindrop-side data and mirror it, rather than diverge from it, but I know PKM practice all but demands that you add your own insights to contextualise and interpret what you captured.

kaiiiz commented 2 years ago

You're right, in my use case, it's more important to summarize the idea and link it to the existing knowledge than always keep the same local and remote highlight stats. Thus, the highlight import feature implemented in this plugin is only used to ease the pain of repeating the copy-and-paste procedure from Raindrop to Obsidian.

To be honest, I think always maintaining the same highlight stats (full replace of the whole file content as you mentioned above) is no different than building a local version of Raindrop. Though you may still be able to link the imported article as a reference, you lose the flexibility to summarize and add your insight in the pulled file.

Considering other implementations than full replacement of the whole file content, the plugin should be able to recognize each highlight's id, the corresponding position in the file, and keep track of the update status of the given highlight. Due to the high flexibility to let users fully-controlled the file content, it's hard to "update" the corresponding highlight section without issues.

dredhorse commented 2 years ago

one "workaround" other sync plugins use is that the user can delete the note in obsidian, which forces a resync.

My process doesn't really care if the document would be overwritten all the time as long as that would happen after # But other people would have issue with a destructive overwrite.

I'm treating my notes from external sources that I sync into obsidian as reference material, from them I distil the information into my own notes, linking back to the original or copy it. My biggest "issue" with my workflow is that if I finish my "extraction" work I need to mark my original synced note and the "source" with a status of processed. But... processes are out of scope of this 😀

kaiiiz commented 2 years ago

My biggest "issue" with my workflow is that if I finish my "extraction" work I need to mark my original synced note and the "source" with a status of processed. But... processes are out of scope of this 😀

Yes, I think keeping the edibility of the file is crucial to many workflows in Obsidian, including changing the metadata status, "extraction" directly in the synced post... etc, so a destructive overwrite is not a preferred method as I've mentioned above.

kaiiiz commented 2 years ago

Hi all, I've implemented the new feature called Append Mode in v0.0.12. This option is on by default. Turning this option off can keep your file always in the latest state, but this will lose the flexibility to add/modify the content for the synced files since the file content will be replaced by the newest rendered content during the syncing process.

Please check it out if this option meets your requirements.

robertandrews commented 2 years ago

Hi all, I've implemented the new feature called Append Mode in v0.0.12. This option is on by default. Turning this option off can keep your file always in the latest state, but this will lose the flexibility to add/modify the content for the synced files since the file content will be replaced by the newest rendered content in the syncing process.

Please check it out if this option meets your requirements.

Tested a couple of times and seems to work so far.

First time, changed a highlight (first highlight in the bookmark), and it was appended to bottom. Then I switched off the mode, changed the colour of the same highlight to a third colour, and that became the colour of the first highlight, removing the appended highlight.

I haven't tried writing between bookmarks.

kaiiiz commented 2 years ago

Thanks for the testing. I'll close this issue. If you have any suggestions or encounter any bugs, feel free to open another issue.