Table formatting - feels a bit limited?

Perhaps I haven’t read all the documentation or played with Bear long enough. As far as I can tell, it’s quite tricky to format tables in a flexible way.

I’m not expecting a Microsoft Excel-like experience, but I would like to be able to add colour to headings, add rows more quickly, and turn off the alternating colour per row that seems to be in place. I don’t want grey, dark grey, grey, dark grey. I just want a header that’s one colour and all the other rows can be white or blank in a classic table sense.

Can anybody help me out with this please? It’d be good to add a bit more colour and structure to the tables. Thanks.

5 Likes

Anyone?
Appreciate this might be an old subject but couldnt find a specific answer to my question
thx

I can confirm it’s not possible to change the cells’ color. I interpreted yours as a feature request and generally speaking we are more interested in understanding how the rest of the people feel about those rather than replying ourselves.

Regarding adding rows more quickly I can suggest using the shortcuts.

Hi @trix180 , is it possible to change the width of the columns? There is a limit to minimum width of the cell and it widen when I type but for the columns that only has a few characters there are a lot of empty spaces. Thanks.

No. Unfortunately, markdown tables don’t come with a way to specify column widths.

Hmm, Bear supports resizing images in notes, but as far as I know, Markdown doesn’t allow custom image sizes (please correct me if I’m wrong). So could changing table column widths be handled similarly?

1 Like

I hear you on tables. I don’t use them much because of the limitations; however, I’m sure I would use them if they were more robust.

1 Like

That’s a legitimate question. To allow image resizing while not breaking markdown standards we use a special HTML comment (metadata) next to the image markup. This is something we can do for inlines but we struggle to do for full lines (table, code blocks, …) because the metadata should be on an invisible paragraph. This paragraph should act as if it’s not there on backspaces, new lines, cursor movements, caret placing, and a lot of other cases. Also, it should disappear with the table on deletion.

3 Likes

The Bear app could allow adjusting the column width and store that width as metadata internally in SQLite. That wouldn’t affect Markdown export.

I guess storing metadata per cell, which I understand is being asked for, is going to get very messy, very quickly.

Some years ago I wrote an evernote parser to convert my notes to Bear or Obsidian that preserved lots of metadata and formatting information (like gps coordinates, image widths, links, backlinks, etc). IIRC, some markdown processors/renderers utilize the number of dashes under the header text to define the rendered column width (though since at the time Bear didn’t support tables I didn’t end up coding this in my markdown converter). So a wide column would have more dashes than a skinny column. Perhaps you could use something like that to “encode” column widths. It would perhaps break the elegant markdown you guys create for tables, but would make the table view in the Bear client much nicer to view and work with.

For example:
initial table:

| Col 1 | Col 2 | Col 3 |
| ----- | ----- | ----- |
| *foo* | *ipsum lorum blah blah blah* | **pizza** |

And in the case the middle column is resized to handle the longer text and ‘soft wrap’ at a fixed width, the markdown would look like…

| Col 1 | Col 2                | Col 3 |
| ----- | -------------------- | ----- |
| *foo* | *ipsum lorum blah blah blah* | **pizza** |

Perhaps each additional dash = some fixed width increment.

Bear goes in the opposite direction, we try to have everything concerning the “style” of the document inside markdown. This is the reason link previews, image widths and other metdata are stored as HTML comments inside MD iteself. We do this to not defying one of the key advantages of MD: portability.

Also, I’ll be glad we have a syntax we can use in the markdown export.

2 Likes

This is new to me. Do you remember one or two of those processors/renderers?

I looked and I don’t have any notes about this. I evaluated a lot of note tools when leaving evernote and at the time the top candidates for me besides Bear were obsidian and notable. I created export flavors for both of those in my evernote parser, so perhaps notable was one, however I don’t think so because I would have implemented support for column widths. There were quite a few fledgling md tools a few years back, many of which are now defunct.

I can accept not being able to resize columns, but the minimum column width is 2-3 times too wide. If the first column only has sequential numbers, it’s a waste of space.

How Bear handles all of the customization with syntax within the note is probably my favorite feature of Bear and why I use it as an archive tool over other apps. I love being able to bulk modify the entire note from a text editor. Open Note in External Editor would be a dream, but I’m fine with copy and paste over nothing.

Don’t necessarily need infinitely customizable widths, but they do take up a lot of space as currently implemented. Tables would be 10x more graceful to use (in Bear) if they would at least just collapse down to a standard min-width. I use them daily, and heavily - but the experience is hit or miss. I can see how people would get frustrated and just move on from trying. Too much time wasted trying to negotiate with them to shrink down and fit on the screen. Sometimes they seem to generate with reasonably sized columns, sometimes they take up 2x the amount of space needed, for seemingly no reason.

So, why don’t they behave like most basic markdown environments as default?