Closed robertandrews closed 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.
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.
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.
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 😀
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.
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.
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.
Thanks for the testing. I'll close this issue. If you have any suggestions or encounter any bugs, feel free to open another issue.