# Inline “preformatted text” formatting used when multi-line selection doesn't contain hard break

**URL:** https://meta.discourse.org/t/inline-preformatted-text-formatting-used-when-multi-line-selection-doesnt-contain-hard-break/387049
**Category:** Bug
**Tags:** composer
**Created:** [October 29, 2025, 12:01pm UTC](https://meta.discourse.org/t/inline-preformatted-text-formatting-used-when-multi-line-selection-doesnt-contain-hard-break/387049 "2025-10-29T12:01:29Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![renato](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/renato/32/383632_2.png) [@renato](https://meta.discourse.org/u/renato)
#### Post date: [October 29, 2025, 2:35pm UTC](https://meta.discourse.org/t/inline-preformatted-text-formatting-used-when-multi-line-selection-doesnt-contain-hard-break/387049/4 "2025-10-29T14:35:07Z")

</div>

> [@per1234](#):
>
> The correct behavior would have been to put the content in a single code block:
> 
> ```plaintext
> foo
> bar
> 
> ```

I’m not sure about this, this was an intentional exception, because you still have a single paragraph with a line break in this case, and adding inline code mark should be possible in this situation.

We can even consider a change in this behavior, but it’s not really a bug. /cc @lindsey

> [@per1234](#):
>
> The Markdown editor has the correct behavior of always placing the selected content in a code block when “preformatted text” formatting is applied retroactively to a multi-line selection.

OK, sorry, I hadn’t noticed this. I think it makes sense to keep both consistent, indeed.

---

_[View the full topic](https://meta.discourse.org/t/inline-preformatted-text-formatting-used-when-multi-line-selection-doesnt-contain-hard-break/387049)._