I am trying to understand how the insert paragraph in the context menu of markdown editing, works?
If I have 2 lines of text and I do an insert paragraph between them shouldn’t I get a blank line when the markdown is rendered?
A screen capture in side-by-side mode would be helpful.
I guess I am asking how to use insert paragraph from the context menu.
If I put in 1 blank line and do not use insert paragraph I get a blank line when rendering the markdown even though I did not use insert paragraph.
So in what context is insert paragraph useful?
Thanks
Any help?
Maybe it’s just there in markdown documents for symmetry?
Thanks but not sure what you mean.
If I use it in the markdown document then in the source it will create a new line but when rendered it does not.
Here is a screen snapshot before the insert of the paragraph break.
Then I inserted a paragraph break using the contextual menu before the last sentence beginning “In the end”
As you can see it had no effect in how the markdown was rendered.
You need two line breaks if you want to see one line break in rendered view (or add two spaces at the end of a line).
The contextual menu is not only used for Markdown records. If you use the menu in a RTF record all items are available. In Markdown records the “Image” item is disabled, which means the devs did disable items that can not be used in Markdown.
Not sure whether the single line break that’s inserted in Markdown records is intentional, though.
Thanks for the clear explanation.
What I am left with is that the insert paragraph break of the contextual menu needs clarification.
Sorry for the tardy reply. Busy days.
I can’t clarify this much for you. It’s definitely something that’s been around for some time now.
Also, in the Markdown document you need two spaces before a return to start a new paragraph, so the command could be used but it wouldn’t start a new paragraph without those.
And yes, you can use two returns / linefeeds without the doublespace at the end of the final sentence of paragaph 1.
PS: We are making a potential modification to this behavior regarding new paragraphs.
1 Like
You’re welcome.
PS: We are making a potential modification to this behavior regarding new paragraphs.
Jim,
Will that include the current Services ‘Create New Markdown Document’ process?
(Sorry if this is too long for this thread. Happy for it to be a separate one if that’s better…)
At the moment, this creates a markdown document from selected text in a Safari page, but it uses ‘two spaces’ as the the paragraph delimiter. This creates an enormous block of text in the source, which renders perfectly well, of course. But it makes it hard to see the paragraphing in the source (as plain text documents can’t use the ‘first line indent’ method).
If I want to work with the text, I usually end up having to do a search and replace on almost every document (and also take out the unnecessary escaped \(. )
The clipping service, on the other hand, converts to ‘2 returns’ in the expected way, but I prefer the service method because it renders Safari’s Reader page more accurately — the clipper seems to ignore Reader and do its own conversion and introduces unwanted images, which isn’t always what I want.
As an example: take this screenshot of a Safari Reader page (‘He is phenomenal’: Dawid Malan marvels at England captain Joe Root | England v India 2021 | The Guardian)
This produces the following results: (left to right: Reader + services, Reader + Clipper Clutter Free, and Reader + Not Clutter Free’).
As you can see:
- The services conversion is much harder to read (depending on page width, it’s difficult to tell paragraphs apart)
- The two clipper conversions are identical and both include an image and a bulleted list which aren’t in the Reader view.
I’m not that bothered about the second issue (I only mention it for completeness), but it would be nice if the first could be addressed.
Or am I missing something and the differences are meant for a specific purpose?
As an aside, it’s also a problem in all the RTF clippings: the default style for the conversion is scrunched together with no paragraph spacing, making for too dense text. I have to do some post-import conversion to make it readable. Unlike the markdown conversions, this is a problem with both Services and Clipper. Is there any chance of changing the default style import to improve that as well?
Thanks,
David.
PS: One final very minor point: you have three services which function in exactly the same way: Take Plain Note, Take Rich Note, and Create Markdown Document. I missed the third for ages because I assumed it did something different from the other two… Would it be worth tidying the naming up at some point so it’s more obviously an equivalent?
2 Likes
The next release will support this (and optionally copy the images to the database too).
3 Likes