microsoft / PowerToys

Windows system utilities to maximize productivity
MIT License
110.16k stars 6.49k forks source link

Markdown newline behaviour (non-uniform) #10354

Closed foosmate closed 3 years ago

foosmate commented 3 years ago

Summary

Unfortunately, the newline behavior is not uniformly solved in many Markdown tools. Some require (correctly) the double spaces at the end of a line to insert a newline. Others do not require this. And a few apps even trim the lines (before saving) and delete these double spaces.

Obviously this double space trick is a holdover from earlier times where plain text documents often were wrapped at 78 characters with artificial linefeeds. Nowadays, all editors are capable of automatic line wrapping (based on window width), so this double space trick no longer brings any real advantages in Markdown. In fact this is a point that rather confuses many non-expert users (because the behaviour is unexpected).

For this reason I strongly recommend to include an optional configuration switch whether normal newlines (without double space) should be interpreted as a line break or not. This would improve the handling of external Markdown files, which are often displayed incorrectly.

Especially since there are some apps around (e.g. for mobile devices) that do not require / support double space and sometimes even remove them when saving.

📝 Reproduction steps

first line<br>  
second line<br> 

✔️ Expected result

first line
second line

❌ Actual result

first line second line
crutkas commented 3 years ago

This is more of an enhancement.

how i'm reading your ask is to support HTML elements like line break (<br />), correct

foosmate commented 3 years ago

No, this enhancement is pretty minimalistic ;-)

It's just about introducing a configurable option that toggles whether all lines that end with normal linebreaks but without trailing double spaces should be rendered as newline or not. Currently they are not, but if the "new" option is set they will.

The name of the option could be:

"Ignore double spaces at the end of a line and use every linebreak as a newline." -> ON / OFF

PS: The <br> in my example is only to clarify that there are not two trailing spaces there. :-)

crutkas commented 3 years ago

Where is this deemed standard behavior?

foosmate commented 3 years ago

To illustrate the problem, I made a screenshot with several standard editors side-by-side. In the Markdown standard it is defined that (1) you have to insert a blank line to get a double line break (a paragraph) and that (2) a line must end on a double space to get a single line break (a newline).

However, most Markdown editors do not follow this confusing second rule. For this reason, there are many documents around the world that do not contain a terminating double-space for a single line break. All these documents are displayed differently by PowerToys Markdown Preview in comparision to the Markdown Editor previews.

You can easily try this yourself with the various online editors for Markdown, such as StackEdit or Dillinger.

https://stackedit.io/ https://dillinger.io/

Below is a screenshot showing an example with 3 standard editors to illustrate the problem. You can see that the PowerToys Markdown Preview (bottom right) "glues" the first and second line together. This is standard compliant, but unexpected for most users, because hardly nobody (in the common user group ;-) knows and applies this double space rule anymore. In the plain text version (upper left) you can see the trailing spaces and newlines, which the editor shows as special character (in light blue).

I therefore suggest to add a switch to the PowerToys plugin to toggle this behavior so that PowerToys can display the MarkDown documents in both ways (standard compliant and new way).

Currently we have the big problem that our users (with thousands of Markdown files in our repository) see a "broken" Markdown preview in the Explorer, because many lines are glued together. Nevertheless, these files are "correctly" shown in most editors and also are "correctly" printed by our tooling. This is a bit confusing for our users (only having common Wiki knowledge), but the proposed option would easily fix that. :-)

Thanks for your support and best greetings!

Example

dedavis6797 commented 3 years ago

Resolved with the release of v0.41.