Testing version: 1.0 (566)
What were you doing: Adding a Separator
What feature did you use: The three dash shortcut to add a separator
What happened: The text just before the separator became big and bold (like Heading 2)
What did you expect to happen: Just a divider
This happens only when using the - - - shortcut to add separator. When using Alt + Cmd + S, it works fine.
Also the two separators look different.
Placing an separator directly below text is an alternate way to make a heading:
It works the same here in the forum editor; give it a try!
You can avoid that behavior by adding a space between the text and the separator.
I tried and yes it does make a heading. It didn’t work like this in bear so it feels un-intuitive.
Just to be clear, in Panda we’re having 2 kinds of Separators:
- Simple Separator - that has the same functionality as Bear’s Separator but it can only be done with the key command Alt+Cmd+S
- A new separator that makes a heading and deleting the divider turns the heading back to simple text.
This has the old separator syntax of Bear “- - -”
Also it doesn’t work like this in Typora, Day One, Notion, Bear etc. So I just want to confirm that this is intended for Panda?
I feel adding and converting to a Heading is already so simple in Bear that the separator’s behaviour shouldn’t be changed to do it and it should retain the way it was in Bear.
These converted Headings don’t show the Heading Icon.
With the new editor we’re trying to keep 100% Markdown compatibility, so those are two different features:
Thematic breaks also called separator
Setext headings are header with a line underneath
Those are both standard Markdown features so we’re supporting both.
The Setext heading is not the same as the other heading, so the representation in the editor is different: no icon, and just a line on the bottom of it.
Hope this make sense
I agree that this isn’t very intuitive. Took me a little while to work out what was happening.
However, whilst this might be accepted behaviour, it does seem wrong that every line above the separator (—) to the next line space, is re-formatted to a heading. Surely, this should just be the immediate line above?
Although, I do concede that adding a line-break above the last line of the heading will change the other lines back to normal text.
Just seems a little confusing - maybe some words to explain this markdown feature will help when releasing this.
I found a workaround: Use a text snippet app to change - - - to Opt Cmd S when using Panda.
I’m using aText, TextExpander will also do the same for you.
The problem is that I like to write in Panda and then copy and paste into Notion. When pasted into Notion whether *** or — is used, it treats the everything like a heading (no space prior to the line). Unfortunately. So I’m left to manually edit the doc once in Notion.
The setext headings are treated differently than the atx headings, in bear as well as in panda. But nevrtheless they appear in toc as heading 1 or heading 2. That is confusing. May it be a good idea to give those two setext headings a different function in the editor? I am thinking of using them not as headings but as marker for sections, so that they also do not act in the toc as headings
Please forget my post. It was so stupid to ask for an implementation that is such a violation of the specification
give me another try after my stupid statement in my previous post: since these setext headings produce so much confusion amongst the userbase wouldn’t it be a good idea to supress them but in a way that not violates the specs? Would it break the compatibility to add automatically an extra blank line between text and —shortcuts? I mean a blank line that is not visible in the editor but in the xported text or md file