-
Notifications
You must be signed in to change notification settings - Fork 20
Description
The Problem
In markup, we may deliberately use spaces to give texts semantics. However, on the other hand, we may occasionally insert redundant spaces and want to tidy them up. To preserve or collapse or trim, that's the question.
Here is a tiny example to show how we treat spaces currently:
leading spaces are trimmed
= In Heading
- In list item
+ In enum item
/ spaces in terms : are trimmed
spaces between words are preserved without `--collapse-space`
Spaces can turn to line breaks in the following cases:
#[ in content block ]
#[but not in this one ]
* in strong syntax *
* in
multiline
strong syntax *
_
in emph syntax
_
#[- with blocky content inside]
#[$ "equation is also blocky" $]
#[= But heading is ok]
which with -l=0
can be formatted to
leading spaces are trimmed
= In Heading
- In list item
+ In enum item
/ spaces in terms: are trimmed
spaces between words are preserved without `--collapse-space`
Spaces can turn to line breaks in the following cases:
#[
in content block
]
#[but not in this one ]
* in strong syntax *
*
in
multiline
strong syntax
*
_
in emph syntax
_
#[
- with blocky content inside
]
#[$
"equation is also blocky"
$]
#[
= But heading is ok
]
It is worth noting that, in the last case, it does not affect the layout to add extra spaces. But this indeed changes the representation, which is a matter of concern.
One tricky case is
#[- 1
- 2
- 3]
As you can see, sticking the first list marker to the bracket [
makes it confusing. So we format it as
#[
- 1
- 2
- 3
]
But it also changes the representation.
Special Rules
There are some existing options to change the default behavior.
--collapse-space
Consecutive spaces are trimmed to one.
--wrap-text
It implies --collapsed
. Any space can turn into a line break.
Discussion
- Should we preserve spaces as-is as much as possible? (which is conservative)
- How should the special rules interfere with the default behavior?