Blockquote line spacing

I am having an issue where my blockquotes when exported as markdown show as separate paragraphs:

Example:
This paragraph 1 and paragraph 2 should be all one block quote.

But this second paragraph shows as a separate blockquote.

When exported that above shows as:

Example: This paragraph 1 and paragraph 2 should be all one block quote.

But this second paragraph shows as a separate blockquote.

I set the compiler to insert “>” before each paragraph but it misses the line in-between. I am not sure how to fix that. I have tried using shift returns (multiple) but then it doesn’t add the new lines, it bunches everything into one sentence.

Certain Markdown flavors treat an “empty line” preceded by an “>” (that’s actually not empty anymore, but let’s keep it simple) as part of the (same) blockquote, others enforce a paragraph break.

What you could try is inserting an invisible character (that is not a “space”) in place of the empty line, something like "ㅤ" U+3164: Hangul Filler (Unicode Character)

Does this fix your problem?

Good thought, but using a special character just makes the compiler think its all one sentence again.

Does it? I just tried this:

Which compiles (Basic MultiMarkdown) to:

hmm… maybe there is a compile option I am missing. I have had scrivener for 2 days so I am still figuring this thing out.

Text format:
I inserted the special character in the editor and it looks like what yours shows (forum wont let me upload images)

Compile settings:
(the forum wont let me upload images)
Compile Format Designer > Styles > Block Quote: treat as raw markup
Paragraph prefix/suffix ‘>’

To insert the special character I just opened up the Windows Character Map and found a blank item:
U+2000: EN Quad and pasted it in before the paragraph like you have.

Wait, is this the Windows version of Scrivener? (We should keep that in mind in case it matters.)

Can you please compile for MultiMarkdown with the “Basic MultiMarkdown” preset? That’s what I used. Without any modifications:

The U+2000 character is not the problem, gave that a try as well.

If I use “Basic Multimarkdown” I see the same behaviour as @November_Sierra (on macOS):

gives me:

Some text.

> I think that tastes, odors, colors, and so on reside in consciousness.
>
> Hence if the living creature were removed, all these qualities would be wiped away and annihilated." --- Galileo Galilei.

More text.

But this uses the [Multimarkdown options] section of the compiler to inject the markup:
Screenshot 2022-09-06 at 08.14.26_SMALL

If I disable that and use the [Styles] panel instead with the same document and compiler format, then I get this:
Screenshot 2022-09-06 at 08.16.47 copy
Screenshot 2022-09-06 at 08.17.01 copy

Some text.

> I think that tastes, odors, colors, and so on reside in consciousness.

> Hence if the living creature were removed, all these qualities would be wiped away and annihilated." --- Galileo Galilei.

More text.

So it seems to depend on whether you use [Styles] or [Options]. This inconsistency seems to be a bug, @AmberV?

BUT the simple solution is to put a space on the blank line (I use two spaces just so you can see, note two-spaces at the end of a line also enforce a linebreak in some markdown engines):

Then I get this using [Styles] to inject the markup:

Some text.

> I think that tastes, odors, colors, and so on reside in consciousness.  
>   
> Hence if the living creature were removed, all these qualities would be wiped away and annihilated." --- Galileo Galilei.  

More text.

By the way, another possible solution is to use forced line breaks \ at the end of a line in the editor and use the normal Prefix/Suffix rather than Paragraph Prefix/Suffix, giving this markup:

Some text.

> I think that tastes, odors, colors, and so on reside in consciousness.  \
Hence if the living creature were removed, all these qualities would be wiped away and annihilated." --- Galileo Galilei.  

More text.

Some text.

I think that tastes, odors, colors, and so on reside in consciousness.
Hence if the living creature were removed, all these qualities would be wiped away and annihilated." — Galileo Galilei.

More text.

You see the blockquote is unitary with a single linebreak. This is good for things like poetry:

So few grains of happiness
measured against all the dark
and still the scales balance. — Jane Hirshfield, “The Weighing”

I assume the styles method is designed to not work like the MMD options and that it parses the blank line as a block-level delineation, meaning that (without using the space you suggested) the compiler never sees the two blocks of text as being one continuous unit. Would that not be desirable from Scrivener’s point of view: to apply one set of rules to the MMD options and a different set to the styles method?

What advantage would there be for a user (or for L&L) for the styles method to offer the same output as the MMD options? If they did the same thing, why would two options exist? (Questions not meant to sound querulous: am trying to understand the advantage of using two ways of achieving identical output. Aren’t they discrete by design?)

TIA.

Both the [MMD Options] & [Styles] panels are doing effectively the same thing: injecting markup based on the associated semantic style. I believe the [MMD|Pandoc Options] panel is there to make it “easier” for users without knowledge of markdown to convert basic styles to markup, without having to know what to use in the Prefix/Suffix; but essentially they serve the same purpose for output as I understand it…

Now it may be that this subtle difference in the way blank lines are handled is a design choice, tiered to the perceived “noobness” of the user for their convenience. But there is an argument for the compiler to apply textual markup consistently, either treating blank lines as “block breaks” [the “official” rule and what [Styles] does], or treating each line within a block as if it is a paragraph even if technically it fails the paragraph rule of markdown [what MMD Options does].

§24.14 of the manual does infer that what [MMD|Pandoc Options] does is deliberate:

Block quotes style: each paragraph or line of text marked with this style will be prefaced by “>”.

[and thus not a bug with the caveat that “line of text” includes blank lines, even if blank lines could be intepreted to contain no actual ‘text’?]

There is a tension between what a Scrivener style may mean by a “block” of something and what markdown defines as a block of something. This subtle difference can obviously cause confusion (hence this thread). @AmberV will be able to inform us either way…

1 Like

Thank you very much for the considered and informative reply. Indebted. Be nice to hear from Ioa.

@nontroppo : Both the [MMD Options] & [Styles] panels are doing effectively the same thing: injecting markup based on the associated semantic style.

While true, I think it there is a very important distinction to be made between these two tools, which explain their differences in output:

  1. Style prefix/suffix markup: crucially, these are not a tool for generating Markdown. Sure, we might use them for that purpose (and it is very valid to do so), but they are equally designed for inserting caption numbering in rich text workflows, valid XML in a plain-text Format designed for such, LaTeX or ReStructuredText for the same reasons, and so forth.
  2. Pandoc|MultiMarkdown Options: on the other hand are hand-coded to create valid CommonMark compliant Markdown for specific types of markup in a controlled environment. We can do things with them that cannot be done with the freeform style system itself (such as stuff like moving caption styled text that falls above or below a table into the correct position and into markings, to be recognised as such).

To address each in order: when considering that the prefix and suffix system is intended for a much broader usage than Markdown alone, there are presumptions made about it that work better for the majority of the cases in how it might be used. One such common case is that most markup systems make heavy use of the container principle—noisier, but better for machine parsing (and just the sort of thing markup systems like Markdown were designed to avoid), such as <p>Line of text</p>. In such systems, we wouldn’t want to ever see:

<p>First paragraph</p>
<p></p>
<p>Second paragraph</p>

While that isn’t actually invalid, it is poor use of syntax—and other uses of this feature might indeed produce invalid syntax, such as:

{
	"p1": "First paragraph",
	"": "",
	"p2": "Second paragraph",
},

That is going to extend to a lot of the kinds of markup we might want to generate with the feature. Markdown is a bit unusual in how we can assert something about a line with a single mark at the beginning or end of a line. Hold that thought for a moment, while taking a look at the next factor.

On distinction (2) we can make strong assumptions about a contiguous text marked with a style should come out like, based on common usages for a specific type of marking. In CommonMark, this is one single block quote comprised of multiple paragraphs:

> First paragraph.
> 
> Second paragraph.

As noted above, if you leave the middle line empty it is actually two block quotes that just so happen to be adjacent. We give the user the power to make the decision of which form to use by whether or not the style usage is truly contiguous. Set the empty line between block quote paragraphs to No Style, and you get two adjacent single-line block quotes. Leave the whole field styled and you get one multi-paragraph block quote.

To me this is a logical and coherent definition of a block, in as much as we can map the concept of invisible formatting to the concept of textual formatting in Markdown. If we apply an invisible format to a line that matches the format of the visible lines around it, it is a declaration of continuity—something we would do with visual markup (the > on an otherwise empty line) in text.

Now returning to where we left off above, you might be asking why we don’t leave that power in place for the style-based approach as well: it has everything to do with common usage producing commonly desired results.

Two adjacent but semantically separate block quotes are a lot more unusual to see than two paragraphs in one quote—there is our commonly desired result. The “sloppy” approach of styling the whole sequence, including the blank line is the most common use, producing the most commonly desired result.

But for prefix/suffix usage it’s actually the other way around! If the style prefix/suffix system were to work like the dedicated Block Quote feature, then the sloppy result (common use) would produce what would be in most cases be the undesirable result! That would then mean a whole lot more fiddling around with style commands to enforce a strict No Style Empty Line doctrine. Bear in mind, we aren’t just talking about block quotes in Markdown here any more—we may be talking about 4,000 word ranges of styled text! Can you imagine having to manually manage invisible markings between several dozen paragraphs and having to laboriously proof the output for bad-practice empty line syntax injection?

We didn’t think anyone would much like having to do that either.

That leads us to the final, and potentially most important factor, and that is that styles are not only injected in the editor (thank goodness). In fact best practices in Scrivener are to avoid bulk style usage in the editor. Let’s go back to our paragraph style usage in HTML/XML. It would be best practices to not apply that style in the editor, but rather to set up your body text Section Layout to style the text for you on output.

And now we are in an impossible position if style prefix/suffix values had an impact on empty lines. That best practice approach would be completely unviable because the compiler is going to create contiguous style ranges between any exceptional use of styles in the editor (actual block quotes, etc.).

I would not say it has much to do with “noobiness” as you put. Each tool has its own merits, and I suppose if anything we could say that “sloppy” style usage is perhaps a bad habit, but again it’s really the only practical way to work for very long ranges meant to be semantically contiguous, and the only effective way to work if we delegate that busy-work to the compiler instead.

2 Likes

OK, this does make sense, although I wonder what the “undesirability” balance is for markup that benefits from the “sloppy” (or more somewhat more generously phrased block-semantics :slight_smile:) like LaTeX and markdown to line-semantics of html and friends?

A nerd may imagine a checkbox option for how each style may behave, selecting either block or line semantics when applying prefix/suffix :nerd_face: — but at least a nerd like me would prioritise other improvements to the style-mapping system in the compiler[1].

Anyway the important point is we have a hack for block-semantic markups like markdown by using spaces to fill the empty line and therefore “stretch” the block over lines. Thanks as always @AmberV for the detailed answer!


[1] I would love the ability to apply attributes for an editor instance to the output markup. I would also very much wish we could nest block styles. Both these originally come from HTML but they are becoming more popular in other markups…

1 Like

so I gave this a try using the Basic MultiMarkdown and all blockquotes came out with no formatting at all, same for Basic Pandoc. I made sure I was just using Blockquotes and tried to set it for both a double paragraph and normal paragraph.

(this is where I would put my screenshots, but it says I cannot import media files (jpg or png) - is there some special privilege’s I need to post them?)

If I copy the MuliMarkdown and look at the MulitMarkdown Settings they have the styles filled in for Blockquote etc., but again I am not getting the same output as you are showing above.

It seems I cannot get blockquotes without using the prefix no matter what, and no matter what I have for MultiMarkdown settings or in the Prefixes, I always have a broken space or my entire blockquote is put together as one paragraph.

@nontroppo : OK, this does make sense, although I wonder what the “undesirability” balance is for markup that benefits from the “sloppy” (or more somewhat more generously phrased block-semantics !:slight_smile: like LaTeX and markdown to line-semantics of html and friends?

I don’t mean “sloppy” in a negative way, more just a reference to whether one is marking only the elements with markup, or the stuff in between as well, technically. Because technically it isn’t so clear-cut even with Markdown whether one should mark between elements of a block. In fact, this issue first came to light in internal alpha testing. I originally pointed out the flaws of assuming empty lines should be marked up when implementing a definition list style, which was being applied at compile-time to items of a certain section type. This is not a valid use of the definition list markup:

Term to define
: First sense of definition.
:
: Second sense of definition.

There are other cases as well—in fact I think block quotes might be unique for having a visible continuation syntax? Most continuation syntax involves indentation of subsequent elements. It’s one of Markdown’s quirks in my opinion—one based off of email conventions more than what is coherent in the overall system. But I digress.

@Rahabib : It seems I cannot get blockquotes without using the prefix no matter what, and no matter what I have for MultiMarkdown settings or in the Prefixes, I always have a broken space or my entire blockquote is put together as one paragraph.

Alas, Windows users do not yet have the effects of the Multimarkdown Options or Pandoc Options compile format pane yet, even though they have the interface for it. I’ve already gone and made sure that major problem is resolved for the next update. I should have mentioned that before.

I understand this leaves you with the workaround, but unless you are producing more than Markdown with this source, I’d consider just formatting these in the editor and eschewing the style-based approach, as the workaround will result in roughly the same amount of typing. If you do need styles because this is not only generating Markdown but something else that shouldn’t have markup in it, then maybe consider putting something in between paragraphs other than a spacer that you can search for and remove with Replacements, as they run after style prefix application.

@nontroppo : …but at least a nerd like me would prioritise other improvements to the style-mapping system in the compiler.

Such as the prior problem!

After a bit of hacking, I managed to get it to work. First, I was experimenting with block quotes with content in italics as well. Using >_ for the prefix and _ for the suffix. No matter how I try to fix the line break between paragraphs, I get single paragraph or if I add extra returns I get the double blockquotes.

The work around, which is ok for now, is to only use > for the prefix and remove the suffix; in other words, I cannot have my blockquote forced to italics.

Next, I have to ensure that that Transformations > Convert to plain text is set to “Paragraph spacing.” This doesn’t break the final display, but the md file has all the spacing removed and VS Code or other editors may complain about it (and its just terrible to read the code this way).

Finally, the thing I was not doing before, was to place TWO spaces on the empty lines. Hidden characters, other characters, or a single space will break the blockquote in to multiple blockquotes. However, with two spaces just before the empty line paragraph, it magically works.

In fact, the double spaces will also work to insert single line breaks. For example, I placed the word Example: on the line above my description in the blockquote with a single return. If I do not have two spaces after the word Example, it will export with the as Example: with my following line as one..., but if I add two spaces after the colon, the compiler can export it with a single return.

It is annoying to have to remember adding two spaces to get blockquotes to display correctly. I am writing a rulebook where all of my examples are put in blockquotes, so I am bound to have instances where I forget to do this; however, its good I at least have a work around. The whole reason I am using Scrivener is because I can write in sections and control the hierarchy for displaying section numbers (eg. 2.1, 2.1.1, etc.) If it were not for this feature, I would probably just prefer to just write in VS Code directly in markdown with an actual markdown editor and previewer. I would love to see a markdown composition mode in the future!

1 Like