markdown: Preserve inline code line breaks if --prose-wrap=preserve#11373
markdown: Preserve inline code line breaks if --prose-wrap=preserve#11373thorn0 merged 1 commit intoprettier:mainfrom
Conversation
Fixes prettier#11372. Signed-off-by: Anders Kaseorg <[email protected]>
andersk
force-pushed
the
inline-code-wrap
branch
from
10372cf to
a013659
Compare
|
This is very helpful for two reasons. Not only the fact it makes mdfiles easier to see, but also it works well with markdownlint, since markdownlint will consider inline code-blocks as usual line-length. Hope this gets merged soon. |
|
Still waiting for a maintainer to look at this very simple bug fix (3 lines plus tests). Here’s a sample from the actual buggy change that Prettier wanted to apply to the Zulip documentation, which motivated this fix. Before: (The `--config pull.rebase` option configures Git so that `git pull`
will behave like `git pull --rebase` by default. Using `git pull
--rebase` to update your changes to resolve merge conflicts is
expected by essentially all of open source projects, including Zulip.
You can also set that option after cloning using `git config --add
pull.rebase true`, or just be careful to always run `git pull
--rebase`, never `git pull`).Prettier 2.7.1: (The `--config pull.rebase` option configures Git so that `git pull`
will behave like `git pull --rebase` by default. Using `git pull --rebase` to update your changes to resolve merge conflicts is
expected by essentially all of open source projects, including Zulip.
You can also set that option after cloning using `git config --add pull.rebase true`, or just be careful to always run `git pull --rebase`, never `git pull`).With this fix: (The `--config pull.rebase` option configures Git so that `git pull`
will behave like `git pull --rebase` by default. Using `git pull
--rebase` to update your changes to resolve merge conflicts is
expected by essentially all of open source projects, including Zulip.
You can also set that option after cloning using `git config --add
pull.rebase true`, or just be careful to always run `git pull
--rebase`, never `git pull`).There should be no backwards compatibility concern because the buggy formatting will be preserved if it was already applied. |
return { ...node, value: node.value.replace(/\s+/g, " ") };Turns out this replacement isn't correct at all. See #13485 (comment) |
thorn0
left a comment
thorn0
left a comment
There was a problem hiding this comment.
Let's do #11373 (comment) in another PR
|
Okay, but there will be a conflict. |
4 participants
Description
Fixes #11372.
Checklist
docs/directory).changelog_unreleased/*/XXXX.mdfile followingchangelog_unreleased/TEMPLATE.md.✨Try the playground for this PR✨