Most editors have Enter=New Paragraph as default behaviour.
With Shift+Enter= New Line in same Paragraph.
This is true in MarkText, Typora, Scrivener, word processors, Focus Writer etc etc. Even Vivaldi’s little note editor.
Currently a substantial proportion of users are using or looking for workarounds, which are all higher friction.
Some looking for CSS, some Entering twice, some bulk converting, some using other programs.
New users arriving since Live Preview are even more likely to expect this.
Make Enter=New Paragraph the default with Shift+Enter for new line in same paragraph.
Toggle for current behaviour.
While I don’t agree with making this the default, I’ll add a +1 to have commands with customizable hotkeys.
The reason I suggested it as default is that most coders (the group I anticipate most prefer current behaviour) would have little difficulty finding the toggle.
Writers, non-coders and new users are the ones most likely expecting the same behaviour as other programs they use, and likely to have the greatest difficulty in locating a toggle.
That might be the case! I’ve used both coding/plain-text editors and apps like Typora, Scrivener and Word, and I would find the behaviour of enter confusing here. Personally, even if it would be easier for one group to toggle the behaviour, I personally don’t think this should be the default and wanted to clarify that. Ultimately, I’ll leave that to the devs.
For the record: Typora has the code-y behaviour (enter is just a new line) when you use source code and paragraph-y behaviour when you use their wysiwyg. For Obsidian itself, I just want this to be decoupled and up to the user to decide what to use regardless of the mode you’re in.
I have been using Typora for 3-4 years now, and still cannot get used to ⇧ + ⌅ (shift + enter) = new line in same paragraph, I find it counter-intuitive.
While I am typing away and in the same paragraph I expect a simple enter tap to remain in the same paragraph, whereas starting a new paragraph is more of an “upheaval“, so would intuitively be more prepared for a keystroke combination.
I agree with @argentum, this should not become default, it should remain an option.
Roam, Athens and Logseq all follow the Enter=New Block behaviour with Shift+Enter for New Line in same block.
I think Obsidian’s behaviour is starting to seem non-mainstream.
I definitely agree that Obsidian, not being an IDE should use shift+enter for a new line within a paragraph and Enter for a new paragraph. this is how lists work already within obsidian
I’m not sure how this would differ from the current Obsidian setup. How does new paragraph differ from new line in Obsidian? There doesn’t seem to be a way of formating paragraphs as in word processors.
Markdown specifies a paragraph as needing a blank line above and below.
You can achieve this in Obsidian by pressing Enter twice between paragraphs. A single Enter gives you a new line in the same paragraph.
Most common behaviour
Most programs use a single Enter to create a new paragraph, with Shift+Enter for a new line.
The feature request is to make the default in Obsidian the same as the other programs listed.
The feature request would make it the same as word processors.
One issue here is that formatting for paragraphs may relevant only to those pages with writing. In many other pages with information, space between paragraphs may disperse the text too much. I found this when applying margin padding as a CSS snippet globally. That’s why the capacity to customise the CSS for an individual page is helpful. But the process for doing this has not been documented yet for non-developers.
This sounds as if your final stage is the preview.
HTML has a different tag for paragraphs vs line breaks.
As brimwats mentioned above, lists in Obsidian already use Enter for a new item.
In markdown, lists are a separate block, just as paragraphs are.
I’m not sure if you are implying that you are already using paragraphs in Obsidian (ie double Enter) or not.
I think this is all wrong. (Did not read every comment )
This is a LivePreview thing, only. In the editor, it should interpret 1 line break as a new line/br tag and 2 line breaks as 2 new lines/p tag when translating for view or into HTML. This is standard markup and making this a setting breaks the foundational idea of standard Markdown files.
It’s different in LivePreview. If you edit in LivePreview, then one return should start a new paragraph as with most WYSIWIGs and shift+return adds a new line/br.
The Obsidian nicety of an enter after a heading starting a new paragraph seems ok, as this what 90%+ users want instead of a heading with a line-break.
No it doesn’t. It’s simply about the keys used. A paragraph would still have clear space (two Enters currently). Makes no difference whether it’s Live Preview or Legacy, or source. It’s a question of which keystrokes produce what markdown.
It’s certainly true that a higher proportion of Live Preview users are likely to expect this behaviour.
You are correct about the keystrokes being tied to a markdown output.
However, I think the base as a text file is really important. Text files can be parsed using any parser. Plain text, Markdown, and Textile to html are common. Almost every CMS has a proprietary set of tags you can add as plain text into your content that will be parsed into whatever content the CMS wants to surface there.
At the base, though, common practice in a text file is that one line break between lines is parsed as a br tag and two line breaks is parsed as a new paragraph when going from plain text to HTML. There’s also the clean-up activity to close the previous block element.)
Don’t know if that made my point more clear. I definitely understand what you’re saying. I think that applies more to Live Preview than editor more, though.
I think I get it now. I just pasted a text from Obsidian to Typora and found that the double enter is rendered as a paragraph. I will do my writing in Typora for the time being. I still think a YAML option would be good in the short term.
I agree it’s about the different user bases and their expectations.
In general coders, and other who typically use text files, are used to Enter creating a new line. While writers, most academics and the general public expect Enter to create a new paragraph. Muscle memory is important which is why there ought to be a toggle.
If you thought the default in Live Preview ought to be Enter=New Para and the default in legacy ought to be Enter=New Line, I probably wouldn’t disagree. Though there ought to be an alternative shortcut for the alternative behaviour. At the moment, the only way of achieving a new paragraph is Entering twice.
But I think it’s probably more consistent for Obsidian to have one default, whichever editor is being used. It has been an issue for some all the time, which probably explains the frequency of requests for CSS to give lines the appearance of paragraphs. Writers need paragraphs, and they need to be able to see them; they also need to paragraphs to convert into other formats including the paragraphs as paragraphs. And that’s true, wysiwyg or no wysiwyg.
I just checked the Help file and found no relevant mention of paragraphs, so I understand how it can appear that they don’t exist. No mention, I think, of new lines or how they differ from paragraphs either. I know it’s just markdown, but many Obsidian users are new to markdown and I feel it would have been better if the help documents did explain how to get paragraphs in Obsidian. I wouldn’t be surprised to find that many users believe their long single line to actually be a paragraph; or, alternatively, paragraphs don’t exist…
I would also like to see this to be added, by default or with a toggle to turn it on or off.
I made this request after seeing a number of issues described on the Discord and realising that this would have solved them, or more likely prevented them ever occurring. I never expected that it would be a significant issue personally since I could switch between lines and paragraphs at the flick of a key. But now it is.
My nascent Markdown-OPML duality requires robust and reliable conversion in both directions. But there’s a problem with the body text/bullet Notes where lines are not preserved, but paragraphs are. The simplest and lowest friction solution will simply be to use paragraphs instead of lines. So I’ll switch my writing to programs where Enter=New Para, which for the moment at least doesn’t include Obsidian.
Interestingly word processors work okay. Copy and paste into MarkText or Typora will even include simple formatting and tables (MarkText includes underline but Typora doesn’t). Paste into Obsidian LP includes bold and italics, but not underline or tables.
Side question: Is it possible to format paragraph spacing in Live Edit Mode? Currently I get a fixed line height spacing in the default theme where the empty line between paragraphs has the same height as a text line. There should be a way to reduce that spacing. I tried a few things in CSS but it always breaks the Live Edit.
Update: I guess the empty line should not be editable at all in this case because when combined with the Enter/Shift-Enter behaviour there is no need to have the empty line selectable when in Live Edit Mode. That’s probably the reason why I can’t solve this with CSS changes only.