69

Inspired by Markdown, One Year Later, a question I think would be better suited to here, than the blog's comment system..

As for #3, "Automatic return-based linebreaks instead of "two spaces at end of line" linebreaks", that’s one I hadn’t considered. In normal Markdown, this:

  Roses are red¶
  Violets are blue¶

Will render like this:

  Roses are red violets are blue 

The Markdown answer is to add two spaces at the end of the line (or a literal <br>, I suppose).

  Roses are red  ¶
  violets are blue¶

Although it’s easy once you know the trick, this is far from intuitive to most. I’m reminded a bit of the double-click mouse problem. I wonder if we should adopt the GitHub linebreak approach here.

7
  • 3
    What double-click problem?
    – random
    Oct 15, 2009 at 14:49
  • 2
    I guess the problem is "people don't know how when to double-click". Basically the inconsistency of knowing when to single-click, and when to double-click.. I think changing how SO's markdown makes things even more inconsistent and confusing, just like the single/double-click problem..
    – dbr
    Oct 15, 2009 at 15:30
  • Joel: Stackoverflow doesn't use XHTML, so replacing single-new-lines with <br/> would cause validation errors :P
    – dbr
    Oct 15, 2009 at 15:37
  • 5
    dbr, Tidy gives me 56 warnings on this page already.... Oct 15, 2009 at 15:49
  • "Although it’s easy once you know the trick, this is far from intuitive to most." Yes, it's idiomatic. (See About Face 3, pp 273-6. Try "search inside this book" on Amazon.) Oct 15, 2009 at 15:55
  • 5
  • lol - people that don't know when to double click should not be learning markdown!
    – Simon
    Jun 15, 2020 at 22:25

17 Answers 17

78

This has always been an annoyance with me. When I press the enter key to go to a new line, it would be quite nice if the editor actually did what I wanted it to.

5
  • 36
    But the editor knows what you want better than you do. Oct 15, 2009 at 14:57
  • 19
    I refuse to put my trust in the decision making of any machine not named SkyNET
    – TheTXI
    Oct 15, 2009 at 14:58
  • 15
    So rename your machine SkyNET and everybody wins. Oct 15, 2009 at 15:27
  • 11
    Must add my voice to this. I only learnt about the two space hack (and it IS a hack as far as I'm concerned), when I read Jeff's post - that's after one year of using SO...
    – Benjol
    Oct 24, 2009 at 18:07
  • 1
    @Benjol ... me after 10 years of using SO (!)
    – Avatar
    Dec 11, 2021 at 13:52
31

I'll sort of mirror here the post I made on Coding Horror:


Hitting the carriage return key on a keyboard should give the user a new line in the output. This is simply typographical common sense.

A markup should not break elementary common sense rules in order to provide other elevated functionality.

The fact users use two carriage returns to create paragraphs [...] is irrelevant. The markup internal rules stipulate that [...] text formatting can break break because the lack of two carriage returns. That's fair enough. But text doesn't lose readability if instead of a new paragraph, every carriage return introduces a line break on the resulting text.

Take a look at the user edit box here:

alt text
(source: codinghorror.com)

Is there anything in there that is not clear in terms of formatting? He doesn't use carriage returns and yet his line-break formatting style makes that particular text easy to read and appealing to the eye. The markup however made a mess of it. So, the markup actively ruined the user text. This cannot be.

For the sake of some special formatting elements, like list detection the markup aggressively demands two carriage returns to break a line and doesn't accept the idea of a new-line break, unless the user explicitly forces it with the BR tag.

The line that divides easy-of-use and formatting tyranny can be very thin. On this case it was crossed over. The text the user writes on his text box should have been formatted with single line-breaks. The end result would have been readable text, just like the user intended.

7
  • 1
    There's other problems in that question, not just the lack of blank lines.. \\<path to shared folder>\c will be rendered as \\c.. The backslash is used to escape characters, so \` becomes a single `, and <path ...> is treated as an invalid HTML tag and is not displayed.. The solution is to use markdown's inline-code backticks, or code blocks.. Something far less obvious than pressing return twice..
    – dbr
    Oct 23, 2009 at 16:06
  • 1
    ...SO's custom comment markdown is breaking my previous comment, it should be: pastie.org/666799 ..which works correctly with markdown.pl - another reason not to implement your own markup language? :P
    – dbr
    Oct 23, 2009 at 16:08
  • 3
    "He doesn't use carriage returns and yet his line-break formatting style makes that particular text easy to read and appealing_to_the_eye" Seriously? Good thing you are a programmer, and not a typesetter. I think you exaggerated just to make a point. Also: that "common sense" you refer to? Myth.
    – user3850
    Oct 26, 2009 at 3:10
  • 1
    I've posted the text as is, another version that I think is formatted better, and another that is formatted for Markdown. Decide for yourself which ones are appealing to the eye. pastie.textmate.org/pastes/670429 Oct 26, 2009 at 19:35
  • 1
    Really, if you indeed consider the text the use posted as not being well formatted then you are as guilty of formatting bigotry as I am of formatting liberalism. And if you consider his text is not a considerable improvement over what markdown made of it, then your opinion ceases to interest me.
    – A Dwarf
    Oct 26, 2009 at 20:35
  • A Dwarf, I misread what you wrote as "makes that text particularly easy to read." I think it could be formatted better, but it's not bad. As for the HTML, the software didn't do a good job divining the user's intent, but it wasn't a total failure. It didn't lose any information, commit irreversible changes, or force the user to "fix" the code before proceeding. The only true failure I see is hiding <path ...>, as dbr pointed out. (Ironically, the failure to format the numbers may grab the attention of an editor. Otherwise the missing the <path...> might go unnoticed.) Oct 27, 2009 at 1:54
  • "elementary common sense rules" would actually be a line break with a new textline. I would like to see the downvotes on the answer above. And no, the text example above rendered in one line is not "easy to read and appealing to the eye". – I think it is important to consider the target user. Programmers will get the recent behavior. Normal users will be confused.
    – Avatar
    Dec 11, 2021 at 13:41
22

Personally I am completely against this.

Firstly, the other changes (auto-linking bare http://example.com links, no intra-word emphasis a_b_c) don't deviate too far from regular markdown, this does.

The other changes aren't really problems for users of the data-dump, or who are used to markdown else where. The intra-word-emphasis default behaviour should be quite rare, due to the in_line_code formatting, and markdowns ability to escape underscores (yay\_for\_escapes). The non-auto-linked links are a minor annoyance, plus many markdown parsers already have options for auto-linking.

I also think this change will encourage people to try and post code snippets using new lines, rather than the proper 4-space indentation of pre tags.. This will lead to less subtle errors, for example:

Am *def = 456;¶
Ex *abc = *def;

..will become bold, and look broken.. but not not quite broken enough for the user to look at the preview and think, "hmm, I wonder how I post code snippets without it breaking"

Yes, people still post code despite it looking like a mess, but at least it's easy to spot a giant blob of text, and for someone to edit the question and fix up the formatting (something I regular do quite happily)

On the subject of the preview, all the SO markdown modifications this far have been made to SO's markdown engine, but not the preview. The disparity between the showdown.js rendered preview and final output was already a problem, and this will further exacerbate it..

Ignoring all the miscellaneous weirdnesses like this:

  • Removed support for intra-word emphasis like_this_example

    This change hasn't be mirrored in the preview (a_b_c shows up at abc in the preview, but a_b_c in the final post)

  • Added auto-hyperlink support for http:// URLs in posts

    Nor has this change been mirrored - http://example.com shows up as plain text in the preview, and a link in the final post

Further, I think encouraging people to split text into paragraphs makes their text easier to read. Allowing one-line-break-br's will increase the number of "giant lump of text" questions.

Perhaps the largest issue is: how will questions be migrated to the new markup syntax? This will screw up the display of older post - you can't justswitch to the new markdown() function, not when you can edit old and new posts alike. Say I edit a post that was made with "so-markdown-v1", where new lines are handled the "old" way. I fix a spelling mistake, and click save. Suddenly it's rendered with "so-markdown-v2" and is displayed completely differently.. Another way would be to convert all old posts, removing any new lines not ending in two spaces. This could work, but are you going to do this across all the SO family, and all the StackExchange sites, without introducing any formatting errors?

Finally, I don't think this is a particularly big problem.. There are currently over 330,000 questions on Stackoverflow. Most are perfectly well formatted, most of the others are badly formatted because, well, the author is lazy - lack of any kind of punctuation/formatting, basic spelling mistakes, where the user clearly hasn't re-read their question (I don't mean people who are learning English as a second language, but rather from people who clearly don't care about their question) - such questions would not be helped by turning newlines into <br> tags, as there is no newlines anyway!

I've tidied up lots of badly formatted questions, but I recall seeing very few questions where someone has tried to format their question nicely, but not understood simple markdown syntax, such as two-returns == new paragraph, lists need spacing.. Besides, once they've made the mistake once, it's easy to pickup the solution - put a blank line between chunks of text, just like every book uses to separate paragraphs..

All that said, if this change is made, please do what Github has done - do not call it "Markdown", it's not, call it something distinct, like "Stackoverflow Flavoured Markdown", and mention that clearly next to the input box.

Also, make it internally consistent - if you change the behaviour of newlines in text:

Hi¶
this is my question

..becomes..

Hi
this is my question

Then the same should happen with blockquotes..

> Hi¶
> this is my quoted question

..becomes..

Hi
this is my quoted question

Not like the current markdown:

Hi this is my quoted question


Since this post is rather long and rambling, my main concerns are:

  • Is this really worth the effort?
  • Will the site make it clear it's no longer using standard markdown? (Github does this well)
  • Will the alterations be internally consistent? Must act the same in different blocks, including markdown blockquotes, must not require blank lines about lists and code blocks, and be consistent with the WMD preview
  • How will questions using the old markdown be migrated, without breaking the formatting of old questions?
9
  • 2
    Since it seems we markdown purists are in the minority, I've switched to staunch-the-bleeding mode. meta.stackexchange.com/questions/26011/… Oct 16, 2009 at 18:04
  • @dbr, so, if I got this right you actually propose that markup be imposed on the user simply because otherwise it would break the current code. You don't actually propose that the code be made better and allow for single-line breaks (aka, fix the code). You expect users to surrender to the programmers whim.
    – A Dwarf
    Oct 25, 2009 at 3:00
  • You also propose Yet-Another-Markup. As if there wasn't enough people already thinking they have the answer to "The Right Way!". When we start reusing IN FULL other people ideas instead of trying to outsmart them, these type of problems will go away. Because everywhere you go things will function pretty much the same way and users will know what to expect. The problem is that everyone thinks they have the answer. It's like Regular Expressions: everyone just thought they could come up with their own flavor. The result is a mess that turned RegEx into as much a problem as it is a problem solver.
    – A Dwarf
    Oct 25, 2009 at 3:04
  • 2
    @A Dwarf: I don't understand. I'm for keeping markdown as standard as possible ("I am completely against this").. Creating your own markup language rarely works well, and as you say, it creates a situation where people aren't sure what markdown variant they are using (like regex).. Single-return==new-line might be better, but I'd say it's more a case of "standards" over "better".. If it is going to be changed (as most other responses are for), at least make it very clear SO no longer uses "Markdown", but rather their own custom, markdown-inspired markup language
    – dbr
    Oct 25, 2009 at 13:33
  • 2
    So you would rather be 'standards compliant' than easy to use?
    – Josh Hunt
    Oct 27, 2009 at 4:28
  • 2
    That's a false dichotomy. It can be standards compliant and easy to use. If Markdown isn't easy, use a different standard. en.wikipedia.org/wiki/List_of_lightweight_markup_languages Oct 27, 2009 at 12:39
  • 4
    The idea of markdown is that you have text that is easy to use in plain and that can be converted. Plain text without line breaks is not easy to read. Concerning usability: GitHub uses the automatic-line-breaks method for issue-tracking, and it's a nuisance. When I paste plain text into the GitHub issue tracker, then I always have to remove line breaks as otherwise they would render to <br>.
    – feklee
    Oct 26, 2012 at 22:15
  • "encouraging people to split text into paragraphs" That's not what happens with this "feature". What it does do is discouraging use of line breaks when you should be using them (happens to me, very, very often). This is analogous to discouraging all usage of semi-colons simply because they could be used wrong. Or those stupid keyboards where you have to press altgr to type a "?" or "/". SE should definitely use a "flavor" for this. It's not like we're limited to 80 char console screens on a website.
    – geekley
    Aug 20, 2020 at 9:11
  • Who writes Hi¶ this is my question in two lines but thinks of a one liner in the first place. More than 99.9 % of people would write it in one line if they want one line.
    – Avatar
    Dec 11, 2021 at 13:46
21

Here's an explanation from the Markdown docs.

<h3 id="p">Paragraphs and Line Breaks</h3>

A paragraph is simply one or more consecutive lines of text, separated
by one or more blank lines. (A blank line is any line that looks like a
blank line -- a line containing nothing but spaces or tabs is considered
blank.) Normal paragraphs should not be indented with spaces or tabs.

The implication of the "one or more consecutive lines of text" rule is
that Markdown supports "hard-wrapped" text paragraphs. This differs
significantly from most other text-to-HTML formatters (including Movable
Type's "Convert Line Breaks" option) which translate every line break
character in a paragraph into a `<br />` tag.

When you *do* want to insert a `<br />` break tag using Markdown, you
end a line with two or more spaces, then type return.

Yes, this takes a tad more effort to create a `<br />`, but a simplistic
"every line break is a `<br />`" rule wouldn't work for Markdown.
Markdown's email-style [blockquoting][bq] and multi-paragraph [list items][l]
work best -- and look better -- when you format them with hard breaks.

  [bq]: #blockquote
  [l]:  #list

That's the text before it's converted to HTML. You can read the docs in text or HTML format.

[1]: Here's what the Markdown docs say about line breaks. html: http://daringfireball.net/projects/markdown/syntax.php#p

10
  • 4
    +1 Thanks for digging it out, Patrick. My opinion about that text is: That's all fine and dandy. But it doesn't hide the fact the "feature" exists because the coders couldn't get around a programmatic challenge. So they sacrificed the user for their ineptness. A little rough, I understand. But... there's nothing much else I can say.
    – A Dwarf
    Oct 23, 2009 at 16:43
  • 2
    The "one or more consecutive lines of text" sounds like an arbitrary design decision to me - one that could be reversed. I haven't seen the benefit to allowing hard-wrapped input. Oct 23, 2009 at 20:37
  • So it sounds like the "feature" was an attempt to properly line-wrap paragraphs, so if you have more than 80 chars, you get more than 80 char lines. But instead it ends up giving the wrong result on short lines that don't need wrapping. Oct 25, 2009 at 18:38
  • Adding <br /> would still allow for 'consecutive lines of text' so I don't see any reason for not converting newlines to actual newlines within a paragraph of text.
    – Jacco
    Oct 26, 2009 at 17:08
  • 3
    Would someone please hit the markdown people over the head with an Enter key. Seriously. Take a look at the key. It has a nice little arrow on it indicating that pushing the key will result in a NEW LINE. Doing anything else breaks convention AND changes the meaning of a very common key on the keyboard. This would be akin to showing a 'k' every time someone pushed 'c'. Arbitrary and stupid.
    – NotMe
    Oct 29, 2009 at 23:00
  • 1
    My enter key has no such line :( in fact my enter key has return on it.
    – epochwolf
    Nov 22, 2009 at 23:07
  • Mine too. And when I press the return key the cursor moves to the beginning of the next line, just as Chris suggests it should. Chris, I'm sorry to hear that your enter key is defective, but I don't see what that has to do with Markdown. Nov 23, 2009 at 17:53
  • but a simplistic "every line break is a <br />" rule wouldn't work for Markdown. ... I would really like to know WHY?!
    – Avatar
    Dec 11, 2021 at 13:49
  • 1
    @avatar In the source, line breaks are used to break up paragraphs for readability. If you’re looking at it in an editor that wraps lines, it may not be necessary. But that wasn’t a common feature In 2009 and it’s still not universal. In the output, we would rather let the layout engine decide where to wrap based on the width of the container and taking into account variable width characters. Dec 12, 2021 at 23:12
  • Thanks for the clarification. It's 2021 and I wished that would be different now. I wrote my own simple "markdown" style markup language. My "normal" users requested the behavior we discuss here: Uinsg Enter for breaking text in the editor also breaks the text in the preview. Two Enters create an empty line and thus a new paragraph in the preview. ... Who knows, maybe Markdown will be adapted to this in the future - or not. 😀
    – Avatar
    Dec 13, 2021 at 4:43
13

I am way late to this ball game, but I have to raise a point that I don't think anyone else has mentioned. Markdown behaves this way for a specific reason:

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. Source: Markdown Philosophy

In other words, Markdown is designed to be equally nicely formatted both as a text document and as an HTML document. That is the reason behind the line break behavior. Markdown documents read nicely as text documents because the author can control the text display without having to depend on the word-wrapping behavior of the editor. This is a feature and by design, not lazy programming as some have suggested.

I, for one, dislike GitHub for making the change they did, because now I have to make a choice between a Markdown document that looks nicely on GitHub and one that looks nicely to someone reading it in a terminal window.

11

I have a suggestion that might allow everyone to have their cake and eat it too. Leave the parser, but change the editor to add two spaces and a newline when the ENTER key is pressed.

That way code would remain standard Markdown and compatible with every other Markdown parser. Also new posts/edits would be compatible with existing posts.

1
  • 5
    This would just make things confusing for people who still dont understand why they need an extra newline, and annoying for people who go back and add newlines earlier in their post.
    – Justin
    Oct 27, 2009 at 9:55
9

To answer the question "why can we not treat line breaks in the input as line breaks in the output?"

Suppose hard linebreaks in the input where converted to linebreaks in the output, as many have proposed.

Now, here is the problem: there is no way for me to see the difference between hard linebreaks on the one hand and word wrapping by the editor on the other.

These two paragraphs look the same in the editor:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam venenatis augue
non ipsum dignissim eget posuere nisl porttitor. Vivamus est ligula, aliquam
consequat sodales non, aliquet non nulla.

Nullam interdum tincidunt convallis. Morbi vel pulvinar nisi. Nullam pharetra
sollicitudin libero a vestibulum. Maecenas eget tellus mauris. Phasellus ut
tortor at sapien varius dictum eu in velit.

Because it is only soft wrapped by the editor, the first paragraph would render as:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam venenatis augue non ipsum dignissim eget posuere nisl porttitor. Vivamus est ligula, aliquam consequat sodales non, aliquet non nulla.

While the second paragraph–hard wrapped by the user—would render as:

Nullam interdum tincidunt convallis. Morbi vel pulvinar nisi. Nullam pharetra
sollicitudin libero a vestibulum. Maecenas eget tellus mauris. Phasellus ut
tortor at sapien varius dictum eu in velit.

If I wanted to make the second paragraph look better, I would have to do the backspace-space shuffle for every single line in that paragraph.

(Incidentally, Markdown's usage of two invisible spaces at the end of a line may or may not be called brain dead for the same reason…

If you expect the text to be read in its ASCII form, Markdown's approach is nicer looking than an explicit line break tag like \\ or <br>, but still it is invisible markup.)

3
  • 2
    Re "invisible markup": I don't think it would be bad for the system to say, okay, that's cool that you're leet and know the two spaces trick, but for the sake of everyone else I'm gonna change that to an explicit <br> mkay? Oct 26, 2009 at 1:03
  • /some/ visible markup, but please not that angle-bracket crap!
    – user3850
    Oct 26, 2009 at 2:59
  • 2
    A <br> may be ugly to some, but it works without introducing new syntax and balkanizing Markdown. And it's not such a big deal; single line breaks are rarely used. Oct 26, 2009 at 12:58
7

I think the "two spaces at the end of a line -> line break" is a weird convention (personally, I'd support getting rid of it and just requiring <br> for this case).

But "blank line between paragraphs" is a decent convention; it's also used in TeX (and friends) which is a pretty good endorsement, IMO.

4
  • 2
    Isn't it really the convention for english typography in general? Even from before computers, I mean.
    – user3850
    Oct 23, 2009 at 23:52
  • None of my typographer friends are available, and I can't find any sources for it on the net... damn CSS has ruined the internet for typography research ;)
    – user3850
    Oct 26, 2009 at 3:00
  • try "typography -css -internet" ?
    – epochwolf
    Nov 22, 2009 at 23:08
  • @hop: My english teacher insisted on indents rather than double newlines. Most print media uses indents rather than double new line.
    – Macha
    Jan 18, 2010 at 17:46
5

The non-intuitive line break thing was a problem for me one time. But, then I learned how to correctly do it and haven't had trouble since.

For a tech-oriented site like Stackoverflow I think it is not a problem. However, some users may have a steeper learning curve.

3
  • 5
    Just because one can get accustomed to a bad design, doesn't mean the design wasn't bad. The moms4mom crowd has probably never been exposed to an environment that didn't word wrap and do line breaks on Enter - your point is well taken. Anyone who has used HTML where line breaks are ignored completely has a much shallower learning curve. Oct 23, 2009 at 20:21
  • 2
    Looking at a bunch of random moms4mom questions, its users seem to be getting on perfectly well with Markdown. moms4mom.com/questions/1671/… - separating paragraphs with a blank line isn't exactly complicated or hard to learn.. It's how people generally write anyway (look at the paragraphs in any book)
    – dbr
    Oct 25, 2009 at 13:38
  • 2
    I can't find any evidence that they have a problem with markdown, either... programmers are just a bunch of whiners.
    – user3850
    Oct 26, 2009 at 3:01
4

In the context of a text input box, the only reason for the Enter key is for formatting text - it has no purpose otherwise. Why would you purposely ignore a formatting input?

And if the text is being pasted from another source, line breaks and all, is it such a bad thing if it matches the format it had in that other source?

3
  • 4
    It's not a WYSIWYG editor, so you're not formatting text. You're formatting source code. If people are really having a hard time with that, I think it would be fine to switch to another markup language in which a line break in the source becomes a <br> in the HTML. All that I ask is that the SO team please don't balkanize Markdown. I want Markdown to work the same way wherever I go. I'm happy to learn another markup language. That would be much easier than trying to keep straight in my head different flavors of Markdown. – Oct 27, 2009 at 13:21
  • 1
    @Patrick: I see where you're coming from, but I take a different view. The question is not what's best for Markdown, the question is what's best for SO. Improving the user experience here should be the utmost concern. Inconsistent versions of Markdown might degrade your user experience, but I think the gain in consistency with other applications such as email would more than compensate. You might technically be typing in Markdown source, but that's not what it looks or feels like unless you take pains to use the Markdown features. Oct 27, 2009 at 22:02
  • 1
    @Patrick: Thanks for the invitation to call, I enjoyed the chat very much. I think we're in agreement that we will continue to civilly disagree on this topic? It's all down to a matter of perspective. Oct 28, 2009 at 2:55
3

MarkdownSharp does have this option...

http://code.google.com/p/markdownsharp/

like so..

var m = new MarkdownSharp.Markdown();
m.AutoNewLines = true;

string input = "this\nis\na\ntest";
string output = m.Transform(input);

which produces..

input:
this
is
a
test

output:
<p>this<br />
is<br />
a<br />
test</p>

But I don't think we'll be exercising it on the trilogy. Way too many breaking changes from existing content.

1
  • 2
    Way too many breaking changes from existing content -- but above all: this would create lots of <br>'s where people probably intended to start a new paragraph, for which I guess you'd prefer <p> for the layout/CSS? (How often do people really want/need a <br>?)
    – Arjan
    Jan 18, 2010 at 17:17
2

Seems like most of those advocating for change assume that messages are typed into a browser window in one pass. Most of those who like it the way it is edit, quote other texts, and use a text editor (i.e., emacs).

1

Just in case this thread is read when things are to be changed: if anything is changed, then I'd still like <br> to be an exception. For example: I would not mind if both a single and multiple Returns are converted into a single <p>. But I'd not like a single Return to become a <br> like the title suggests.

(I would still be pressing Return twice then, while others might happily use only one. I am not sure if that affects the data dump in any way? Also, old post might look horrible like dbr noted.)

0

Perhaps allow a raw text entry mode, selected by default, with a switch (either in the user's profile/settings, or on the submission form itself) to use Markdown? More advanced users who want to use Markdown to style their submissions shouldn't have any issue switching, and it allows the less advanced users to use simple WYSIWYG ASCII entry.

1
  • 3
    I think this is catering to a minority as a majority.. There's 334,000'ish questions, most are reasonably formatted, there's lots where they are poorly formatted because the author is, well, lazy (and the WYSIWYG-ASCII formatting wouldn't help - i.e no punctuation, really basic spelling mistakes, didn't re-read their question etc) - I think there are very few cases where people simply don't understand how markdown works, and in those cases, it only happens once, since markdown is very simple to learn (two returns == new paragraph. That's about all most people need to know)
    – dbr
    Oct 23, 2009 at 15:14
-2

Please do that. I'm all for it, but I assume converting the old posts will be a nightmare. Markdown decision is totally absurd in my opinion.

-2

A really confusing design.\
I want \ or other charactors to replace two blanks to change line.\
A visibale charactor is always better.\
Or there need an option so that everyone may use his own style.\
Er.. Is there any easy solution so far?\

1
  • A backslash at the end of the line does now work as a substitute for two spaces, per our upgrade to CommonMark.
    – animuson StaffMod
    Jan 4, 2021 at 17:53
-2

Yes. When I press enter, I expect to see a new line just as I would see in this editor. If I wanted a space, I would press space. (I pressed enter after each of these sentences and I just got a space instead of a line break) enter image description here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .