[request] Support double return/enter for paragraph

[sumyungguy]

I've tried many other markdown editors, and Typora is definitely in line to be the best! I'm looking forward to using it as my main writing tool.

Unfortunately, there's one thing that stands in the way at the moment: using a single press of the return/enter key for a new paragraph. I've been writing on my computer nearly my whole life, and I always press twice for a new paragraph. It's really not possible for me to "unlearn" that, nor do I want to. So at the moment, I can't use Typora. I hope you'll consider changing the behavior, or at least adding it as an option, to support the way the great majority of people write on the computer.

If Typora would support double press of return/enter for paragraph, then I'd like a single press to produce a hard line break, as used on Github, Wordpress, and so on. I really don't like the "two spaces at the end of the line" method of original markdown. It's easy to make mistakes, and there seems to be no need for it, other than to support automatic unwrapping of hard-wrapped paragraphs, such as text copy-pasted from an e-mail. Typora could support that with an "unwrap selected text" function, like TextWrangler's "remove line breaks".

On the other hand, it would be good if Typora could support both flavors of markdown, for compatibility with other markdown editors. But even then, I'd like a single press of return/enter to automatically add the two spaces by default; also to pasted text. Pressing option-return/alt-enter, or option/alt paste, could create lines without the spaces. There could be an option to invert the behavior.

Thanks for considering this!

[sumyungguy]

I had another idea, in case the above is not possible for some reason. Typora would work the same as it does now, but you could set an option that if you press enter twice, the first time will make a new paragraph as usual, and the second time it will just be ignored.

It's a hack, but it would at least let me use it. I can't remember to start writing a new paragraph one way in Typora, and a different way in every other markdown editor.

[abnerlee]

Hi, Thanks for your feedback,

I think if Typora is going to support pressing two return key creates a new paragraph. It's better to use same behavior like other Markdown editors: one return key -> new line, two return key -> new paragraph.

Anyway, single line break is going to be supported by Typora from next version up, then we can consider your requirements.

[vassudanagunta]

I agree with @abnerlee.

to support the way the great majority of people write on the computer.

Can you back that up? Because my understanding is that the great majority does not do that. Most WYSIWYG editors work exactly like Typora: Pressing Return starts a new paragraph, and hard line breaks and soft line breaks are created by using meta-key such as ⌘, CTRL or ⌥ combined with Return.

I'd like a single press to produce a hard line break, as used on Github, Wordpress, and so on.

GitHub works like Typora. It is only within GitHub comments such as this where pressing Return inserts a hard line break rather than a paragraph break. Try editing a Markdown file in a repo via the GitHub web interface. It works like Typora, following GFM/CommonMark spec.

I really don't like the "two spaces at the end of the line" method of original markdown.

Yes, in a user-friendly WYSIWYG editor (#1317) one shouldn't have to type "two spaces at the end of the line" for a hard line break. But you don't have to. In Typora you use a meta-key + Return to achieve that.

What you describe makes more sense in Source Code Mode, because you are in essence typing raw Markdown. But even there I'm not sure. I'd bet the current behavior is what 99% of users want.

@abnerlee If you implement this, please do it as an option, not default behavior.

[sumyungguy]

Typora isn't a typical WYSIWYG editor. Most WYSIWYG editors don't let you type in Markdown. Typora should not be trying to be a copy of Microsoft Word, that happens to have Markdown underneath. Typora's audience is mostly people who are used to writing in Markdown, and enjoy the continuous preview. And many of those are used to pressing return twice for a paragraph - just as people who are used to writing in all kinds of plain text editors, e-mail composers, forum comments, mobile phones, etc., etc. Also it supports the practice of pressing Return at the end of each sentence for better behavior with diffs.

I'd bet the current behavior is what 99% of users want.

Can you back that up? Because I would certainly bet that a lot more than 1% of users would use an option for the return key to work the way it does when writing in many Markdown editors, like Github comments, Wordpress, etc. Are you seriously saying it should not even be an option? That seems like a rigid adherence to some idealized notion of what a "WYSIWYG" editor is or should be, and not consistent with the reality of many different types and ways of using Markdown, and the hybrid nature of Typora.

[vassudanagunta]

You're probably right that more than 1% want what you want. Maybe a lot more.

But you haven't backed up your claim either. This is one of the oldest open Typora issues, and it has only 3 👍 's. I sorted all open and closed issues by up-votes, and it's on the third page, putting it at around #60, and that's not adjusting for how long it has had to accumulate votes (2+ years).

Typora has Focus Mode and Typewriter Mode. It's designed for writers who want their work to be saved in a widely adopted plaintext format. So it is more like a word processor that doesn't uses a proprietary file format. It doesn't totally hide the markdown aspect, because that keeps writers aware that their content is being written in a generic unstyled form underneath (like HTML). But I can also use normal word processor keyboard shortcuts to add formatting and never touch Markdown.

But you should read the last line of my previous comment. 😄

[AlexPasternak]

Are you seriously saying it should not even be an option?

If you implement this, please do it as an option, not default behavior.

Seems like no 😄

[sumyungguy]

Are you seriously saying it should not even be an option?

If you implement this, please do it as an option, not default behavior.

Seems like no 😄

Am I misreading something? Is he not making arguments about how basically nobody would want this feature, and it's probably not worth implementing?

What you describe makes more sense in Source Code Mode, because you are in essence typing raw Markdown. But even there I'm not sure. I'd bet the current behavior is what 99% of users want.

I think it's a completely reasonable request, I've explained good reasons for it, others have said they'd find it useful, and @abnerlee has already said he'd consider it. I'm disappointed of course that he hasn't had time for it in the past two years, since I've had to abandon Typora. I'm still hoping that it could be added in the future. I write Markdown in multiple different editors, and I'd love to be able to use Typora too, but I just can't deal with the fact that the return key works differently from every other editor I use! I'm not able to adapt, when switching back and forth.

You know how in feature requests, there's always some guy who pops up saying "I don't have a need for this feature, so you shouldn't need it either"? Don't be that guy... I don't appreciate what seem to be arguments to dismiss my needs, and persuade the developer that the feature is unnecessary and my request can just as well be ignored. Especially when it seems to be based on personal assumptions about what and who Typora is designed for.

I disagree strongly with the characterization that "It's designed for writers who want their work to be saved in a widely adopted plaintext format. So it is more like a word processor that doesn't uses a proprietary file format.[...]" And from what I've read, that isn't how @abnerlee sees it either. I think it's instead an innovative hybrid of a plain text editor with an inline Markdown preview, aimed mainly at people who write in Markdown. Those people often need interoperability with various other editors and platforms, and need various preference settings to accommodate that. The idea of an old-school WYSIWYG word processor that happens to use Markdown as its underlying file format is the philosophy of Texts, which I think is awful and doesn't suit my needs at all.

Just to end with one practical example: often if I'm writing a Github comment like this one, and it starts to get a bit long, I'll copy it into a Markdown editor with a two-pane preview and other features, like Atom or MacDown, and continue working on it, then copy it back. Those have options that make it seamless, typing and preview work virtually the same as they do here. I wish I could do that with Typora because I prefer the inline preview. But I simply can't handle the return key changing its behavior! I want it to be so that if I close my eyes and touch-type Markdown, it will come out the same, no matter which of several editors I happen to be using at the moment. Again, I think this is a totally reasonable and valid feature request, and a common use case!

[vassudanagunta]

This my last reply, because this is getting silly. Why are we arguing? I simply expressed my opinion, and asked the developer to make it an option rather than default behavior if he decides to do it.

[sumyungguy]

I opened this issue in January 2016... obviously by now he doesn't plan to make it the default behavior.

When someone comes to a more than two-years-old feature request arguing that 99% of the users don't want this, and that it doesn't fit the concept of the product - especially if that person has a "contributor" badge - it seems pretty clear they're making the case that it's worthless to implement the feature, even as an option.

So yes, I'm going to argue with that, because I feel like you haven't acknowledged that there's any validity to my request, and have just dismissed it as being irrelevant. I'm going to defend my reasoning that Typora is not a WYSIWYG word processor, nor a plain text Markdown editor, but has mixed elements of both, and ought to accommodate customers using it in either way - one of which is to type paragraph breaks the same way as virtually every other Markdown editor that exists.

[abnerlee]

Sorry for keep this open from 2016.

I agree with that Typora is a mix of WYSIWYG word processor and plain text editor, and this issue is a problem for some users.

About this request, there are actually another old related issue #233, and they may contains "conflicts" with each other, for example, if #233 enabled, then when you press return, you will see a whitespace, then press return again, a new paragraph is created...

Anyway, line breaks in markdown is confusing to users, it is also unpredictably, for example, Github handlers line break differently in readme file and in this comment text area. So if a website claims it supports markdown, we still don't know how it handles line break. So the safest way seams follow a way differently markdown engines support in common, so users can use it for general purpose.

I understand different users have their different preferences, but they are preferences for power users.

We may add following options in future updates.

When Editing -> 1. Render single line break 2. Do not render single line break. When Export -> 1. Render single line break 2. Do not render single line break. Press Return -> 1. Insert single line break 2. New paragraph Press Shift+Return -> 1. Insert single line break 2. Insert two whitespace and line break. 3. Insert <br/>

But we need to think how to make it NOT confusing and NOT complicated for most users.

[sumyungguy]

@abnerlee, thanks for your answer, good to know you're still thinking about it. I understand there could be interactions with issues like #233, and it's not easy for you to solve. One idea with "do not render single line break" could be that when you press return, you will see a special character instead of a whitespace, and if you keep typing it changes to a whitespace, or if you press return again you get a paragraph break. Then in this preference there's a third option something like:

When Editing -> 1. Render single line break 2. Do not render single line break. 3. Show invisible line breaks

Which would always show the special character even when you keep typing.

if a website claims it supports markdown, we still don't know how it handles line break. So the safest way seams follow a way differently markdown engines support in common, so users can use it for general purpose.

I don't think there exists one way that works for general purpose. Even people who aren't power users need a different setting to work with different Markdown engines they're using. Like you say, even two settings just for Github. The best way to make it not confusing is to have good, clear explanations in the help, about the main differences like line endings, and how to make a simple test of the system or website you're using, to set the preference correctly. In the end it's not so difficult to understand, just a few minutes of reading...

[ExtravagantAardvark]

I think the following is closely related, at least I found this thread while looking for more info: I have a problem with Typora treating an end of line in the text as a paragraph break. This is in contrast with any other markdown viewer I know. What I would expect - and suggest ;-) - is that if you enable the 'strict mode ' preference that the behaviour would be like the standard.

Now my question is: if you would implement that, could that not be automatically tied to the behaviour in the wysiwyg mode? I know that in the markdown mode it would mean a single return meaning next line in file, but not visible in wysiwys, while a double return would add a blank line and thus a new paragraph. The wysisyg mode could then reflow the actual markdown lines in the same place you see them in the preview.

I think that if tying that to strict mode everybody could be happy?

Would in fact even make me more than happy, because then the begin/end keys would jump to the begin/end of the line in both wysiwyg and markdown mode instead of the current behaviour of jumping to the begin/end of the paragraph.

[martzell]

How it should be IMHO:

• Return key makes new paragraph: empty line in source view.
• Shift Return makes new line inside paragraph: \ at end of line in source (or \<br /> or 2 spaces; but 2 spaces are invisible and so not recommend).
• newline character in source, which does not renders as line break or new paragraph, should not break the line in Live Preview but shown as space or a placeholder symbol like ↩︎.

I've stopped using Typora because line breaks (shift return) are shown in Live Preview but disappear in exported file. When I've returned with the bachelor thesis .md file from Texts app I had a hard time because Texts hard wrapped the paragraph lines and Typora could not handle it correctly. Have I reported a bug for that? It would also be great to have a command to prettify the source, because mixed heading format (# and ## or underlined with === and ---) is not so pleasant.

I think there is a more general problem. Typora Quick Start says Typora uses GitHub Flavored Markdown, but this is not true for line breaks, because \ at end of line does not render as line break: https://github.github.com/gfm/#hard-line-breaks

CommonMark, which GitHub Flavored Markdown is based on, is the most solid Markdown specification and should strictly followed. https://spec.commonmark.org/0.28/#hard-line-breaks

Okay, I've just learned CommonMark knows no tables and strikethrough and GitHub Flavored Markdown can't do footnotes. So Pandoc Markdown seems the best choice.

[abnerlee]

It seems a bug if Shift Return inserts extra \ and \ does not mean line break unless next line is not empty.

And there should be no line break in above two line based on GFM, but there is. We don't know whether current user wants line break or not, so use "Return" instead of "Shift+Return" is always recommended.

We have related settings on how to treat single line break. -> https://support.typora.io/Line-Break/

[martzell]

I understand.

I have the feature request to easily input line break and non breaking space because addresses and measures like $ 5 or 9 € or 50 % are quite common. On Mac alt space inserts a non breaking space and shift return line breaks usually.

Another feature request is line breaks in table cells.

What is the intention that line breaks are shown in hybrid view but not rendered at output?

Bug: Export to word rendered \<br /> as text in the word document. html line break visible.docx

Why is the standard markdown way (GFM, CommonMark, Pandoc) for line breaks – backslash \ before newline character and following line not empty – not supported?

Have you created your own Typora Markdown dialect, because Typora can do Footnotes and more things that GFM can’t? Why don’t you use Pandoc Markdown which seems the feature richest markdown dialect and offers the most output and input formats? What Markdown does Typora use?

How to easily input addresses or poems? Code blocks are not the right way. Pandoc Markdown knows lineblocks. The recommendation not to use line breaks only paragraphs is not right for addresses, opening hours and many more:

Bad:

Address:

One Infinite Loop

Cupertino, CA 95014

(408) 606-5775

Driving directions and map

Store hours:

Mon - Fri: 9:00 a.m. - 7:00 p.m.

Sat: 10:00 a.m. - 6:00 p.m.

Sun: 11:00 a.m. - 5:00 p.m.

Special store hours:

November 22 Closed

Good:

Address: One Infinite Loop Cupertino, CA 95014 (408) 606-5775 Driving directions and map

Store hours: Mon - Fri: 9:00 a.m. - 7:00 p.m. Sat: 10:00 a.m. - 6:00 p.m. Sun: 11:00 a.m. - 5:00 p.m.

Special store hours: November 22 Closed

Why is hard wrapped text still first citizen? Only because some are used to it and don't know how to use diff, emacs, vi and other popular tools with soft wrapped text files? If you change later hard wrapped text line breaks go amok. I would prefer an option to soft wrap… wait… I've just found the option in the preferences. Thanks, thats great… but not standard markdown.

Bug: When copying the text as Markdown or HTML there are no line breaks. Or are there unicode line breaks? Because exported as HTML breaks without \<br /> tag.

[ghost]

Maybe I am part of the 1% discussed earlier in this thread, but having just discovered Typora the only thing that is giving me hesitation is this issue.

Aesthetically and functionally Typora is without a doubt the Markdown editor I have been searching for, but the fact that the Enter key behaves differently to all the other tools I use daily is the thorn in my side. I regularly write markdown in a variety of tools depending on the task, and in all of them 1x Enter = 1x newline in the document source, and 2x Enter = 2x new line = new paragraph.

At this point I don't think I can retrain my fingers to press Shift + Enter when I want only a single newline in my source, and given that Typora is the only editor that requires this I don't think I should either.

I would happily implement this feature myself, were Typora open source. In the meantime I can only offer my comment that I 100% support this feature request, although I know a 3 year old issue is unlikely to be addressed at this point.

[thiagodiascano]

Maybe I am part of the 1% discussed earlier in this thread, but having just discovered Typora the only thing that is giving me hesitation is this issue.

Aesthetically and functionally Typora is without a doubt the Markdown editor I have been searching for, but the fact that the Enter key behaves differently to all the other tools I use daily is the thorn in my side. I regularly write markdown in a variety of tools depending on the task, and in all of them 1x Enter = 1x newline in the document source, and 2x Enter = 2x new line = new paragraph.

At this point I don't think I can retrain my fingers to press Shift + Enter when I want only a single newline in my source, and given that Typora is the only editor that requires this I don't think I should either.

I would happily implement this feature myself, were Typora open source. In the meantime I can only offer my comment that I 100% support this feature request, although I know a 3 year old issue is unlikely to be addressed at this point.

I just discovered Typora and it's the exactly same for me. It's the only 'plain text' software/application where I'll need to press shift+enter for a new line, so probably I will keep looking for another option out there. Which is sad since I really like it

[tghuguenin]

This is my first GitHub interaction. I signed up for a GitHub account specifically for this issue. I am a writer who uses an AlphaSmart Neo2 for distraction free writing apart from my computer at times. Since it only saves in .txt I decided to learn Markdown. Since I primarily only need italics and paragraph breaks as special formatting requirements while I use the Neo, the flavor I use is not particularly important, but since I generally use Pandoc to convert to docx when I'm finished, I suppose you could say I use Pandoc as my flavor-of-choice. But I'm pretty sure pandoc and GFM are basically the same for what I need it for.

OK so for those of you who have never used a Neo, the way it sends information to your computer is by emulating a keyboard. So let's say I type 1k words in the Neo, then want to save it to the master text/markdown document on my computer, preserving my italics and paragraph breaks. I type it in markdown (asterisks for italics, a blank line between text for paragraph breaks), plug via USB into my computer with a text editor open, and press SEND. It sends the raw text into the text editor as if I were typing it in (though much quickly than my average wpm). It sounds kind of crazy but if you realize what the Neo was actually designed for, it makes a little more sense. But I don't want to get into that.

So I think, instead of doing it this way, then opening up a terminal window (I'm on macOS) to use pandoc, why not find a markdown editor that will convert to docx and get rid of the terminal/pandoc step (or at least have it be already within my editor)? So I found Typora, which I really loved, until I found that a single return creates a new paragraph. This is confounding as I had retrained myself when learning markdown to hit return twice for new paragraphs, I did this precisely because I chose to write in markdown, and now I find a markdown editor I actually like only to find that I have to go back through my master document and get rid of the double-returns if I want it to parse correctly. This seems completely backwards. What was the point of switching to markdown when the only markdown editor that appeals to me in every other respect doesn't actually use markdown for the one of two elements of the language I had to train myself to use?

So I'm here wondering if this is still being considered. I would accept it as a preference option, but that seems silly to me since it the defined syntax of the flavor of markdown Typora supposedly uses agrees with me: [https://help.github.com/en/articles/basic-writing-and-formatting-syntax#paragraphs-and-line-breaks]

[Theneum]

I love everything about Typora, especially the folder structure, but I don't think I'll keep using it because of this issue. I'm usually in a code editor so maybe that's part of it and I wanted to use Typora for my personal knowledge base, but so far I just can't get used to this single return = paragraph thing. Sad, but I think I'm back to Evernote for my purposes.

[moremammal]

This one may be a deal breaker for me as well. It is not intuitive for me to remember the Enter key works differently in this one editor. Please give us an option or method to hack it.

I tried overriding key bindings in conf.user.json, but sadly every listed shortcut I tried could be re-mapped except for "New Line" and "New Paragraph". If I could at least get that workaround to function I'd be happy.

In every other respect, Typora is a joy to use.

[Theneum]

After trying a bunch of different options I found Joplin did everthing I wanted, and the return key actually works the way I expect it to.

[moremammal]

I am reviewing my tools/system lately, and I keep thinking, "Typora would work great for this." However, I still spend a lot of time in plaintext editing and coding, so, I still have trouble with remembering Shift + Return when I intend to write a single newline.

I am a little shocked that this is still an issue, especially after so many other cool options, which must have been a lot more work, have been implemented.

Now, each time I make the Return for newline mistake in Typora, I feel exasperation. I am interpreting the refusal to allow even a hacky option to change this is really a sort of passive didacticism, directed at people like me. I am reminded of this every time I hit Return.

I understand that you want people to learn to write in (your preferred interpretation of) a flavor of markdown. I assume the idea is that we'll be forced to just learn to do md "right." That could actually work for me if Typora was where 90+% of my time was spent, or if I really wanted to retrain myself to accommodate this one quirk. At the moment, I don't.

In the future, if this behavior change is allowed as a configurable option, I would happily spend a fair amount on licensing the software. That is, assuming I haven't already worked out an acceptable alternative. If I've already bought other software, probably not.

I have not found an ideal alternative yet. The two-panel solutions are distracting, and any of the other inline rendering editors I've found lack Typora's features/options. However, if/when I do settle on an alternative, you'll have lost me (and others like me - there must be more than a few.) I hope you reconsider.

[dazdaz]

Wouldn't it be possible to have an option to alternate between both behaviours, which pleases all parties ?

shift + enter = new parapgraph shift + enter = single newline

This is a request from 2016 that has not been actioned. I really do appreciate Typora, it's a greap tool however the only reason that I don't use it more is because of this and surely it'd take only a few programming hours to implement a simple option to switch between both modes of operation.

What would it take to make this happen ? Heck, i'd even be willing to make a donation and i'm sure that others would too.

[ryamair]

I just made this autohotkey script which, if the active window is Typora, will remap the following keys/key combos:

'Shift+Enter' to 'Enter' 'Enter' to 'Shift+Enter'

It took about a minute to make and I'm very much a beginner ;)

Here ya go:

if WinActive("ahk_exe typora.exe")

Enter::send +{Enter} +Enter::send {Enter}

if

[dazdaz]

hammerspoon script (init.lua) to achieve the same functionality on macOS.

local handleTyporaKeypress = function(event)
  local keyPressed = hs.keycodes.map[event:getKeyCode()]

  if keyPressed == 'return' then
    local flags = event:getFlags()

    if flags:containExactly({'shift'}) then
      -- handle shift + enter
      return true, {
        hs.eventtap.event.newKeyEvent({}, 'return', false), -- down
        hs.eventtap.event.newKeyEvent({}, 'return', true) -- up
      }
    elseif flags:containExactly({}) then
      -- handle enter only
      return true, {
        hs.eventtap.event.newKeyEvent({'shift'}, 'return', false), -- down
        hs.eventtap.event.newKeyEvent({'shift'}, 'return', true) -- up
      }
    end
  end

  return false
end

local typoraTap = hs.eventtap.new(
  { hs.eventtap.event.types.keyDown },
  handleTyporaKeypress
)

local function handleGlobalEvent(name, event, app)
  if event == hs.application.watcher.activated then
    local bundleId = string.lower(app:bundleID())

    if (bundleId:match("abnerworks.typora")) then
      -- start the keypress handler
      typoraTap:start()
    else
      -- stop the keypress handler, because you switched to another app
      typoraTap:stop()
    end
  end
end

watcher = hs.application.watcher.new(handleGlobalEvent)
watcher:start()

[smankoo]

@dazdaz I logged in to thank you. This worked like a charm. I still don't understand why something so basic cannot be implemented directly in the otherwise awesome app.

[slawoslawo]

I've used typora as my scratchpad for coding mainly. I was just alt+tab switching and making some quick notes. Now i have to remember about this new line shortcut - shift return. I dont use typora in full screen, i have only some small window for quick notes. Hate this new paragraph thing because right now i can only type few line and i am out of space in my window. I have to remember about this shift + return thing. The funnies thing is that my typora app worked great, and i made update. I tried later to download the old app but it is not possible anymore. There is this fix with autohotkey, but i don't know if i will use it or just look for other text editor. It is funny because i thought it is just a problem for me, but i see for other people its a deal breaker too.

[sn0utss]

I just made this autohotkey script which, if the active window is Typora, will remap the following keys/key combos:

'Shift+Enter' to 'Enter' 'Enter' to 'Shift+Enter'

It took about a minute to make and I'm very much a beginner ;)

Here ya go:

if WinActive("ahk_exe typora.exe")

Enter::send +{Enter} +Enter::send {Enter}

if

Thanks for a straightforward solution to this moronic and obnoxious issue.

[vassudanagunta]

Thanks for a straightforward solution to this moronic and obnoxious issue.

To bad there isn't a straightforward solution to moronic and obnoxious comments.

[sn0utss]

Thanks for a straightforward solution to this moronic and obnoxious issue.

To bad there isn't a straightforward solution to moronic and obnoxious comments.

Just remember to press shift every time you read something...

[vassudanagunta]

@sn0utss

https://community.signalusers.org/t/reminder-please-be-nice/21217

https://news.ycombinator.com/item?id=25757398

You are the kind of person being talked about. Please learn from this rather than reply with yet another self-centered comment.

[johnsa777]

Can't believe this issue has been open for so many freakin' years. Please add an option to select behaviour (new line/new paragraph). It can't be that hard. Just do it.

[LakeishaKowalczyk]

Obviously, the author generated the adolescent rebelious phase towards this matter

"It can be that hard, just don't it, you can't do it"

Hope it works

[rehack]

Has the problem been solved?

How to use enter to implement new line on MAC instead of Shift + ENTER

[Altair-Bueno]

Any updates on this? I just realised that Typora writes a paragraph on a single line instead of word wrapping automatically (i have wrapping enabled on settings, but this only applies for the UI). It's annoying opening a document on nano or vice verse: by default normal text just looks like a mess. It should definitely behave like other markdown editors/parsers and scape single \n. Also, why does the word wrap option on settings don't wrap the generated markdown too?

The hole point of using markdown is writing formatted text easier, everywhere. Even on a toaster running nano

Opening a md file generated using typora

 

Opening a md file correctly formatted (manual word wrapping on col 80)

 Notice the empty space on the right 

Now that i've found out this behaviour i'll need to look for some utility that wraps all my typora's documents for me

Also, i found out that Pandoc does indeed support line wrapping with a flag, so there should be any technical limitation

[chrisdaniells]

Has there been any update with this? Typora seems exactly what I'm looking for... except for this issue. Such a simple thing makes it unusable for me. I'm amazed reading the comments at how much resistance this perfectly reasonable request seems the be generating!

[Theneum]

Pretty sure after 5 years they don't care what we think. I've used Joplin instead the past few years and I'm happy with it so far.

[thquad]

Typora is probably the best editor for markdown i've used so far, but this one issue is something that keeps me away from using Typora for professional settings, since reading or converting a "Typora-formatted" markdown file to other platforms / programs is a pain. I agree with @johnsa777 , why not make it an option in the settings? Seems like such a simple solution.

[abnerlee]

put into #4759 since it addressed the issue better