Editor feedback

[nezia]

Hey,

this is a mirror from my reddit post, which I posted before I discovered the link to this beta support forum.

Thanks for the open alpha! I immediately tested it

What I find nice:

• lists: finally no more bullet points and list item numbers in the left gutter (left of the margin line)
• styles: style nesting really works well
• styles: links in headers are a nice addition
• font: better default font sizes and weight and spacing for headings

Unsure about:

• editor settings: no paragraph spacing slider to test
• editor settings: it would be great if ordered/unordered lists would be rendered visually more pleasing with added paragraph spacing applied
• style: highlighter color (purple in dark mode) a tone of orange would be a better fit in my opinion
• inserted files: will a quicklook preview work for embedded files?

What I dislike:

• table: tab in the last cell of a table should append a new row
• table: ⇧⏎ should allow linebreaks in cells
• table: no differentiation between the header cells and the body cells
• table: secondary background color of the alternating zebra-style is should be toned down in dark mode, contrast is too stark
• footnotes: they should be numbered and appended at the bottom of the document
• syntax: that the syntax, especially the one for bold, italics, underline, strike-through and highlights are still shown in-line and not hidden
• headline-level: this icon should be in the gutter so that the headline-text aligns properly with the margin of the text. This is different from lists, which naturally are indented from that base margin line.
• headline-level: the icon is less intuitive than the h1, h2, h3, … of Bear, because the mental conversion from which line is longer to how many # it represents has to be made. Especially, when you quickly scan longer documents and want to make sure that your headline levels are correct (btw: a pop-up outline or index would help!) and it’s even worse when you get to h4 levels, because the h4 symbol is the same as the h1’s.

[matteo]

Hello there,

thank you for the detailed feedback!

Some answers about the unsure part:

• All the editor setting are missing atm, but they’ll available, so you’ll be able to tweak everything.
• Colors for the themes are not set in stone, I agree that the highlighter on the dark theme is not optimal.
• Attachment will have quicklook soon.

And some for the dislike:

• ⏎ creates a new row when you’re in the last row of the table, in a similar way as it’s working for list
• line breaks are not really supported in markdown tables, I’ll think a bit about this
• Header and colors inside table are still internally debated, we’re waiting also for more feedback from the community, but we’re going to work a lot on those
• Footnotes will be numbered and at the end in the various export, not inside the editor, BUT you’ll be able to use footnote references that are coming soon
• We’re making a markdown app, syntax is part of the deal, we’ll probably add some sort of read mode soon
• We’re happy with headers levels/icons, but we’ll wait for more feedback, also TOC will be added too

Hope my answers make sense

[nezia]

Thank you for your reply.

@matteo

Footnotes will be numbered and at the end in the various export, not inside the editor, BUT you’ll be able to use footnote references that are coming soon

Do you mean auto-numbered references, instead of the asterisk?

Right now to display the footnote window a click on the fairly narrow space that is given to the asterisk is required. It would be great if hovering over the last word, which is in front of the asterisk would display a non-editable footnote pop-up. If either that pop-up is clicked or the asterisk itself is clicked it could go directly to editing mode.

I find the process a bit rough right now. If you by accident backspace a footnote the entire text of it is gone with just one key press. In my opinion it should work similar to how URLs are already handled.

Example note with the text-cursor caret (symbolized by ⌶) placed at the end:

This is a note in Bear with a footnote.*⌶

Right now, if ⌫ is pressed, the entire footnote incl. the content is deleted. Result:

This is a note in Bear with a footnote.⌶

It should work similar to URLs so that a press of ⌫ converts the asterisk into the markdown syntax representation and the footnote becomes in-line editable. Similar to URLs the last closing bracket (]) should be removed in that case:

This is a note in Bear with a footnote.^[This is the footnote⌶

If the user types the missing closing bracket the the markdown syntax should immediately be hidden by converting it to the much better readable asterisk again.

@matteo

We’re making a markdown app, syntax is part of the deal, we’ll probably add some sort of read mode soon

Oh boy am I’m aware of Bear being a markdown app. I’m a user since many years and have chosen Bear specifically because of that.

To be honest, I appreciate that Bear finally switches to a standard markdown flavor for better compatibility with the rest of the world.

However, from following your subreddit I get that a lot of users primarily wouldn’t want a dedicated reader mode, but more so a hybrid-mode, where syntax is hidden.
I do not understand, how you can be so proud of how nicely URLs are handled and the new live footnote-syntax to asterisk representation in-line conversion works, but not see that the very same could be applied to the text styles as well.

You literally see bold text or one that is highlighted. There is no need to display the wrapping ** or :: at all times. The same logic for URLs and footnotes applies here.

Again, an example with hidden markdown syntax:

This is a bold note in Bear.

Once the text cursor is placed behind the word “note” and ⌫ is hit once it should in-line convert the rendered representation to the markdown syntax:

This is a **bold note*⌶ in Bear.

If styles are nested it should be recognized and the syntax of the entire “chain of styles” should be revealed. Example:

This is a ::~**bold, underlined and highlighted note**~:⌶ in Bear.

Because of this constantly visual syntax, which unpleasantly clutters the text, when reading, I have started actively looking for alternatives to Bear over the last half a year. I almost didn’t renew my subscription last year, because of this, as well.
This would be the best feature addition to the editor.

[louisxiv]

@nezia

table: no differentiation between the header cells and the body cells

I’m kinda conflicted about this. On one hand I expect to see table headers bold by default, but on the other I spend an awful lot of time cursing the assumption when I want a pure unformatted table.

I’d prefer that header formatting is in my control, but I suspect that won’t be the widest compatible way of working to meet people’s expectations.

I’ll be interested to see what Team Bear decide…

[nezia]

(Disclaimer: I had to split this post, because apparently as a new user I’m not allowed to attach more than one image per post.)

Yes, I can relate to the concern. After my post and further testing I took a closer look at the table from the Panda editor example file, which renders to this:

But the syntax actually looks like this:

| Share your feedback | [feedback forum](https://community.bear.app/c/feedback/5)  |
|---------------------|----------------------|
| Report a bug        | [bug forum](https://community.bear.app/c/bug-reports/6)       |
| Alpha test page     | [bear.app/alpha/](https://bear.app/alpha/) |
| Twitter             | [@BearNotesApp](https://twitter.com/BearNotesApp)   |
| Reddit              | [/r/BearApp](https://www.reddit.com/r/bearapp/)      |

So the first line is declared as a header, but rendered without any differentiation.
Content-wise it isn’t a header at all. A header for the given table could be:

| Description | Link  |
|---------------------|----------------------|

[nezia]

If you would copy the markdown-syntax code of that table to another editor (similar to exporting a note later from Bear to .md) the layout might be misinterpreted, due to that. Here’s how the same table gets rendered in Typora using the GitHub-styled theme:

The first row of content is rendered to a header, which can’t be desired by the code that Bear creates.

If the header row would be omitted, the markdown code wouldn’t use proper table syntax anymore and other rendering issues can occur.

[nezia]

The interesting part is that this problem is again solvable by hiding the dreadfully visible syntax and “manually” bolden the content of the header cells to avoid this:

The misalignment caused by the leading ** is very unpleasing.

[nezia]

An alternative mock-up with hidden syntax looks much cleaner:

[migi]

Hidden syntax has long been a point of discussion in Bear, it especially irks me with the headers being indented from the rest of the text

[val]

with the headers being indented from the rest of the text

THIS

[craig]

+1 To OP’s concerns about header levels.

Having used Panda for about a week now on several design documents, I am definitely missing the header level indication. I actually stopped using Panda on longer documents because I couldn’t easily tell my header levels. Bear/Panda render beautifully, and I appreciate the effort. But in this case form shouldn’t trump function.

[ces3001]

@matteo

also TOC will be added too

This make me so happy!