Markdown pane does not collapse line breaks by default

[maximlt]

By default, the Markdown Pane does not collapse line breaks. This is when you write on multiple lines:

My name
is Bond,
James Bond

And it is displayed on a single line:

My name is Bond, James Bond

This is the default behavior on VSCode or in JupyterLab.

It doesn't seem to be the default everywhere, at least not on Github.

It looks like this used to be the default behavior in Panel but was changed in #5376. I'm opening this issue as I was updating the Exoplanets example which has this multiline string displayed in a Markdown pane. The string is written in a way to make it easy to read in a notebook, this would also be valid for code written in a .py file. Unfortunately, the line breaks are all preserved and the end result doesn't look great. Removing these line breaks while keeping those desired isn't trivial, it requires either refactoring the multiline string or processing it (e.g. txt.replace('\n\n', 'XXXXX').replace('\n', ' ').replace('XXXXX', '\n\n').

background_text = """
For the past 25+ years, NASA has used ground- and space-based methods
to [identify exoplanets](https://exoplanets.nasa.gov/exep/about/missions-instruments) (planets outside of our solar system).

In the past ten years in particular, campaigns like Kepler, K2, and TESS have
produced an explosion of results.
To date, approximately 4,400 exoplanets have been identified, and over 3,000 potential exoplanet candidates have 
been discovered.

This dashboard uses [Holoviews](https://holoviews.org/) and [Panel](https://panel.holoviz.org) 
to visualize the discovery of confirmed and candidate exoplanets over the years.
Also included is a scatterplot that reveals details about the relationship among mass, radius, and temperature of exoplanets, 
as well as controls to filter the data based on whether the planets could support life, and if so, 
whether chemical rockets could be used to escape the planet.

See [examples.holoviz.org](https://examples.holoviz.org/exoplanets) for details on the data used here and how to interpret it.
"""

The current workaround is to instantiate the pane with pn.pane.Markdown(background_text, renderer_options={'breaks': False}), as breaks=True is the default.

panel/panel/pane/markup.py

Lines 418 to 419 in 4e4c82b

	if "breaks" not in renderer_options:
	renderer_options["breaks"] = True

The other two renderers have the opposite behavior.

I think my preference would be to default to breaks=False (revert the change made to the markdown-it renderer). If not, we should try to align the behavior across all the renderers and make it very easy to switch that behavior (via doc and/or code), as I believe displaying a multiline string in a Markdown pane is a pretty common thing.

@ahuang11 I understand your use case had to do with Markdown generated from an LLM? In which case, yes, I understand that in this context a line break should be considered a line break.

[ahuang11]

I agree it the behavior should be aligned across all renderers.

However, I don't think we should revert the behavior because to me, if I type \n, I expect to see a new line (thus I raised that issue in the first place)

I do agree we should make it relatively easier to switch between that behavior.

[maximlt]

However, I don't think we should revert the behavior because to me, if I type \n, I expect to see a new line (thus I raised that issue in the first place)

Yeah that's indeed kinda weird but it makes sense in some contexts and is part of the original "spec" https://daringfireball.net/projects/markdown/syntax#p. CommonMark respects it too (like other flavors, but there are too many to check!), these two sections of their spec are a good read: https://spec.commonmark.org/0.31.2/#soft-line-breaks and https://spec.commonmark.org/0.31.2/#hard-line-breaks. I knew that line breaks were respected when the line ends with at least two spaces but I didn't know about the backslash. So, these two will be displayed with a line break, at least for CommonMark :)

foo••
baz

foo\
baz

The renderers we use follow this spec by default.

Unsurprisingly, there's a similar issue for streamlit (streamlit/streamlit#868) about st.write with an interesting discussion. They have st.markdown that respects the Markdown spec (unchanged behavior for them) and now have st.write that no longer parses string objects as markdowns. Gradio also respects the default spec with gr.Markdown (example app)

So we have users who don't know Markdown well enough and users who need to handle output generated from an LLM (streamlit/streamlit#7978 (comment)) versus respecting the Markdown spec and its default behavior that others have adopted too (I didn't check more than Streamlit and Gradio). I'd like others to chime in, I think I still prefer reverting the behavior and follow the spec.

---

Just a side note, the Markdown pane is the default for string objects so to toggle the behavior you need to write a lot more code:

# from
pn.Column(background_text, ...)
# to
pn.Column(pn.pane.Markdown(background_text, renderer_options={'breaks': False}), ...)