Multiple paragraphs in a single highlight do not have empty lines between them

[cmeeren]

I'm currently evaluating Readwise. I have set up sync from Readwise to Obsidian. It works well, but when I highlight multiple paragraphs in a single highlight in Reader, the highlight as it appears in Obsidian does not have an empty line between the paragraphs. Paragraphs must have an empty line between them in order to appear as paragraphs, and not just a line break in a single paragraph.

[tyler-dot-earth]

@cmeeren (OP) @tuchandra (saw your :+1:)

I think this is intentional. Reasoning + fixes for you below.

Why I think it's intentional: so you can use ^block-ids for each highlight (vs each "paragraph"). I use this export template which adds reliable ^rhwi123456 block IDs to each highlight, so this actually makes a lot of sense to me.

Since I also treat readwise exports as read-only, these two snippets are a great fix for me:

/* Increase <br> in ![[embeds]] */
.internal-embed br {
    margin: 1em 0;
    display: block;
    content: "";
}

/* Increase <br> in reading mode */
.markdown-reading-view p br {
    margin: 1em 0;
    display: block;
    content: "";
}

I hope that helps.

[cmeeren]

Thanks for for providing the context behind the current implementation. I understand the reasoning for using ^block-ids for each highlight and the benefits it offers.

However, I would like to respectfully disagree with the current approach and offer some considerations for maintaining proper paragraph formatting:

1. Readability and formatting: Highlights consisting of multiple paragraphs should maintain proper formatting to preserve readability. In Markdown, paragraphs are separated by an empty line, which ensures they are visually distinct. Without this separation, the text appears as a single, merged paragraph, which can be harder to read and understand. I assume we are in agreement on this point; however:

2. The proposed workarounds does not match the desired behavior: While the proposed CSS snippets can help with visual formatting, they do not cover editing mode (which I am in by default, as I usually edit my notes when I am in Obsidian). Additionally, they also impact <br> outside Readwise highlights, e.g. ruining formatting for poetry, where you want <br> to be just a line break and not have extra space. Ensuring that highlights are correctly formatted by default would reduce the need for such customizations and avoid the side effects and limitations of this approach (which, after all, is just trying to improve the visual formatting of an incorrect markdown source).

3. User expectations: I postulate that users highlighting text in Readwise are by default expecting their highlights to be accurately represented in Obsidian. If a user highlights multiple paragraphs, they expect these to appear as distinct paragraphs in their notes. The current approach leads to confusion and additional manual editing to fix the formatting.

4. Consistency across platforms: While I haven't tried exporting Readwise to other tools, I assume formatting is preserved for those exports, since this issue seems specific to Obsidian. Adjusting this functionality would then make it more consistent with other tools.

5. There are other workarounds to get whole-highlight linking: By placing the highlight in a blockquote, you will achieve the same effect of being able to point to an entire highlight. One could alternatively add a heading above each highlight, to be filled out with a concise summary of the highlight's idea. (I do both.) Additionally, while I haven't tested this, I assume that the export template can be adjusted using filters to remove line breaks, replace bullet lists with bullet characters, etc. All of these are optional and not something forced on users.

6. Sacrificing correctness for one feature: The current behavior places important restrictions on Readwise-to-Obsidian exports to satisfy a single requirement (more easily linking to a whole highlight) with no good workarounds to get the most correct behavior (preserving the source formatting). I would also want to question the implicit assumption of there being significantly more users who want more easily linking to a whole highlight than users who want proper formatting of highlights. Having more-easily-whole-linked highlights is not a more "obviously correct" behavior than keeping the original formatting; as you see, I am strongly arguing for the opposite.

I believe that adjusting the current implementation to include empty lines between paragraphs in a single highlight (as well as keeping proper lists, see #49) would greatly enhance the overall user experience without compromising the benefits of using ^block-ids.

If nothing else, there should be an option in the Readwise export settings called "Collapse highlights to single paragraphs", so that users can choose whether they want correct formatting, or more simple linking to whole highlights without blockquotes or headings. I think this option should be off by default (at least for new integrations), but I would consider this issue solved if the option exists at all (or if the behavior is changed to preserve formatting without there being an option for it).

If such an option or change in behavior is not acceptable, I kindly request you to elaborate on why, in light of each of my arguments for changing the behavior.

Thank you for considering this feedback. I appreciate the effort put into making Readwise and its integrations!

[tyler-dot-earth]

Really strong arguments! Thanks for sharing, @cmeeren.

I wanna start by noting that I'm not a Readwise employee, just a random contributor to the plugin, so my context into their choices is minimal.

That said, I do wonder if there is a solution that could be implemented as an option in the plugin as that is all I'd be able to help with in this repo.

I'd need to do a little research on the data that comes back from the export archive that the plugin receives from the backend — but if there are characters that indicate multiple line breaks, adding an option to the plugin which replace those with actual line breaks may be achievable.

I can run a few tests soon. If the export contains the necessary information, I'm happy to try adding an option that would do that replacement (or at least document how someone could) — it seems pretty simple to add and would only impact users that want and opt into that behavior. If it works, I imagine this solution may also be considered a fix for #49.

If the information needed is not in that export, it's unfortunately not something I'd be able to help with (as it would be a backend issue). In that case, you may also consider submitting a bug report within the app, on their subreddit, via email, on Twitter, etc as I don't believe their team actively monitors issues here.

Let me know your thoughts about this proposition. I'll try to carve out some time for experimentation soon and let you know the results in this thread 🙂

[cmeeren]

Thanks for hearing me out! I agree with your approach.

To clarify, the setting I suggested was indeed intended for the plugin.

My assumption has been that Readwise sends complete or "correct" data and that it is this plugin that changes the formatting. If this is not the case, I am more than happy to report this directly to Readwise. (Unless you know there are people at Readwise contributing to this repo that we can ping directly in this issue? After all, the readme starts by saying that this is an "official plugin maintained by the Readwise team".)