#17

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…

4 Likes
#18

I would also like to see this to be added, by default or with a toggle to turn it on or off.

#19

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.

#20

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.

#21

I’m not sure I understand.
What Shift-Enter behaviour?

For me, it’s all the same as the legacy editor. Enter gives, new line; Enter, Enter gives a blank line; blank line clearly visible and editable.

#22

Shift+Enter as you suggested yourself above to create a new line whereas Enter creates a new paragraph. This should be an optional feature and should generate the correct markdown representation (single line break for Shift+Enter, double line break for Enter). If Live Edit mode behaves semantically exactly like Markdown edit mode I don’t really see the benefit of Live Edit.

#23

Current behaviour is
Enter= new line
Shift-Enter= new line
Enter, Enter= new paragraph

This is the case in both Legacy Editor and Live Preview.

Markdown itself makes no reference to keystrokes. It was simply an old convention that markdown editors would allocate Enter to new line. Most don’t allocate Shift-Enter. Presumably this comesz from old text editor conventions.

Word processors have Enter=new paragraph and Shift-Enter=new line.
Typora, MarkText, roam etc also have this.

The feature request is for default behaviour to be the same as word processors, with toggle to reverse they key allocation. Removing the need for anyone to Enter Enter.

#24

That is exactly what I was referring to. I just wanted to suggest that in Live Preview Mode the blank line should not be rendered (as it would be in the plain markdown view) but instead generate a div or p element or whatever so that the paragraphs can be properly styled with CSS.

#25

Ah, I get you.
I’d certainly agree that styling for paragraphs as distinct from lines would be good, though I think that would need to be a separate feature request. MarkText shows a paragraph marker.

When lines are styled to look like paragraphs, the distinction becomes invisible.

#26

This is a must feature to add!

So in the reading view I find that a hard line break results in a
and two hard line breaks generates a new paragraph.

I find this problematic as to me a hard line break to me should be a new paragraph, and a soft line break (shift+enter) should be a new row.

This is especially disturbing if you want to input some css for each

in the reading view and you basically can affect the full page then, not each individual paragraph.

#27

Strict line endings (if you use those) requires two spaces to make a hard line break, which allows you to use semantic line breaks for long lines:

If you use/interact with git, using semantic line breaks can make your changes much easier to track (though this would break the writing habits of people used to writing in word processors).

This Enter-Enter / Shift-Enter stuff for paragraphs totally breaks that flow (and hasn’t been mentioned at all thus far). If you understand the options (two spaces for a hard line break, Enter for a wrapped line, Enter with leading spaces for a continuation of a bullet…), all of this stuff just works, but it does require you to take (a little) time to learn it.

I personally am a big -1 on this. I get that it seems there are a bunch of people that don’t want to know very much about markdown. If this is really required, I would like a “Please hide as much markdown as possible” thing you have to opt into, rather than changes to default behavior like this that start to turn obsidian into a word processor (which, IMO, it is not).

4 Likes
#28

I write fiction.
I like to have my dialogues like this :

— Blah blah bla ?
— Blab !
— Blah blah bla…

And my text like this :

And then it lorem ipsus facto from hell dat iz good two reed ya know.

And here come the juice. Again and again. Arguing with Lorem and talking with Ipsus.

I don’t work with Typora because it does not allow me to work the way I want. I would like to keep the way it works now. As an option, it would not be a problem, but changing it ? I would change the software totaly.

#29

Only the keystrokes are different
At present you do dialogue Enter dialogue Enter dialogue Enter and text Enter Enter text Enter Enter
In Typora you would do dialogue Shift-Enter dialogue Shift-Enter dialogue Shift-Enter and text Enter text Enter.

That simply demonstrates the importance of users being able to use the keystrokes they are used to.

The suggestion is for there to be a toggle option between the two.
I suggested default For Enter & Shift-Enter because WP users will in general be less accustomed to setting options than those used to text and traditional markdown editors.

#30

I did. But it was not recognize by other softwares, it appears like that :

— And then blabla ? — Bleh.

The Enter keystroke is the only one to use. But with your proposition, we also have to use Shift and Space. What a pain for a messy final.

I suggested default For Enter & Shift-Enter because WP users will in general be less accustomed to setting options than those used to text and traditional markdown editors.

Are WP users the main public of Obsidian ? I don’t know, I am just asking. I saw a lot of people willing to do a Zettlekasten with Obsidian who comes from plain text editors like Sublim Text, Visual Studio or Vim. I don’t know if “WP users only” are such a majority that it would justify a change in the way Obsidian exploits paragraphs in its editor. If it is just an option, it’s okay, but a total change to looks like Typora would be a pain.

#31

Looking at prior experience, there are three categories of users:

  • Those coming from code editors and historic markdown editors
  • Those coming from word processors - or requiring very easy interaction with word processor files;
  • Those coming from other PKM programs.

(coming from probably includes still using)

The first uses current Obsidian behaviour, the last two use Enter, Shift-Enter.
Live Preview is based on the interests of the last two groups (most of the first preferring the old two-pane approach).
I believe Obsidian, especially Live Preview, has most in common with the last two groups, too. It isn’t even able to behave as a traditional markdown editor where you could open any markdown (often including .txt and a number of markdown extensions). So it makes sense for it to be able to behave in the same way as other PKM programs.

I have only suggested the change as an option.

And, since we agree on that, the only question is what should be default.
I appreciate the logic of the suggestion made above that it should be default only in Live Preview (though I think it would be less confusing for Obsidian to maintain the same default across all editors).
I compared the three groups of users and asked myself which would find it easier to find and use the toggle. I had no doubts in my mind that it would be the first, so I recommended the default be changed.

#32

I’ve checked again, and it works perfectly with Shift-Enter.
What other program or converter did you use that removed the line feeds?
Or did you use Shift and Space as you wrote, which certainly wouldn’t produce a line break?

#33

I’ve found a setting that stops it working.
Under Preferences>Markdown>Whitespace/Line Break, it needs to be set to ‘Preserve sequential whitespace and single line break’ which iirc is the default setting.

#34

This would actually improve internal consistency. Shift+Enter already = new line in lists (ie new line instead of new bullet)

#35

I come from a 25 year programmer perspective. I have used Markdown syntax previously in informal documentations. Looking at my small collection of Obsidian notes I observe that:

  • most are in paragraph forms

  • but some are not

It would be odd for an Enter to advance two lines when I am editing these single line constructs.

for example:

Hi Jane
How are you?

I am ok.
Thank you.

Significant faith stopping events:

  • Meg no longer certain about creeds and certain doctrines
  • Sharon’s panic attacks

Hoping to see you soon.

Regards,
My Name

Category Delta Omicron
case volume 16929 52133
hospital admission 1.12% 0.17%
ICU admission 0.14% 0.001%
on ventilator 0.06% 0.00%
death 0.08% < 0.01%
#36

That’s exactly it.
Coders like - and are used to - the current key allocation.
Writers are used to the requested feature.

If you think of Obsidian as a traditional markdown editor, you expect. current behaviour; if you look at Live Preview, the request is consistent with the other WYSIWYG markdown editors.
If you think of it as a PKM program, the request is consistent with the other PKM programs.

It’s a question of how you see Obsidian and what you are used to. That’s why the suggestion is for a toggle. Everyone can have their preferred behaviour and keystrokes.

You would be surprised at the number of people trying to use CSS to make lines work like paragraphs. Which may be fine for web publishing where similar CSS can be used but not otherwise.

3 Likes