Make editing long table entries easier

Feature archive
1

Opening a new request, because the old one was closed out.

Tables, Word-wrap, and Horizontal scrolling

As has been previously stated the application does not word-wrap text that has been defined within a table, except in preview mode. And horizontal scrolling is evil and yucky.

Proposed solution

Wrap long lines within table view mode while keeping the beautiful editor view of the tables.

Alternatively, only word-wrap the line that is selected (placing it in the normal word-wrap view that appears in the workaround below). This way the table view stays the same, but when you click on a row in the table that has a long string of text it will switch to the word-wrap mode for editing and pop back out when the line is left.

Current workaround

Currently, while editing the line of a long table entry, you can remove the " | " from the beginning line and it will wrap the text in non-table view so that you can edit the line more easily, and then add the " | " back when done.

Related feature requests

Would be cool if a closing " | " were added automatically once the editor realized you intend to create a table.

1 Like
2

This might help…

tables
tables1318Ă—1012 127 KB

Angel

3 Likes
3

Thank you. Is that a universal syntax for .md or is it just internal to Obsidian?

My understanding is that the format is:

| title 1 | title 2 |
| ----- | ----- |
| 1 | description |

And using this format, Obsidian wont wrap properly.

4

It appears that I may have missed a currently open request along the same lines here → Word wrap in markdown tables

5

The sample table used comes from the Obsidian help vault. It doesn’t use pipes at the start and end of rows.

First Header | Second Header
------------ | ------------
Content from cell 1 | Content from cell 2
Content in the first column | Content in the second column

The Markdown Guide recommends using leading and trailing pipes.

To add a table, use three or more hyphens (—) to create each column’s header, and use pipes (|) to separate each column. For compatibility, you should also add a pipe on either end of the row.

| First Header | Second Header |
| ------------ | ------------ |
| Content from cell 1 | Content from cell 2 |
| Content in the first column | Content in the second column |

So for compatibility it is best to use the leading and trailing pipes, but they aren’t necessary if working in Obsidian alone. And adding a single pipe on the header line does cause the table to wrap in the editor if using the syntax suggested by Obsidian, in Obsidian.

If using leading and trailing pipes, users can get some wrapping in the editor by entering a paragraph return above the row / rows being edited and then removing the return afterwards to bring the table back into the correct format.

Alternatively, a backslash \ before the header row will cause the whole table to wrap while editing. It does need to be removed afterwards or the first pipe will appear in cell A1 as part of the column title. If using linked panes, with the editor in one pane and reading view in the other, users can at least see how the table is formatting while editing (and without having to scroll sideways in the editor).

\| First Header | Second Header |
| ------------ | ------------ |
| Content from cell 1 | Content from cell 2 Content from cell 2Content from cell 2Content from cell 2 |
| Content in the first column | Content in the second column Content in the second columnContent in the second columnContent in the second columnContent in the second columnContent in the second columnContent in the second column|

Angel

1 Like
6

I appreciate the additional methods of workarounds, it gives me more insight into how this application handles .md

That said, I need to stay true to the standard for importing into Scrivener and such.

7

There’s nothing in the above that has any impact on how tables appear in reading mode (when editing is complete) or how they open in other apps. But it appears to be prudent to use leading and trailing pipes for maximum inter-app compatibility.

Scrivener recognises MD tables with or without leading and trailing pipes and can compile both cleanly. It’s also possible to copy from the editor or reading view in Obsidian and to paste into Scrivener as Markdown or WYSIWYG text. Pipe usage in Obsidian is immaterial if pasting as WYSIWYG.

I am heading the other way with my work.

  • Scrivener’s development has always been slow and repeatedly delayed
  • Feature incompatibility between macOS and iOS
  • The iOS app has never had any significant updates
  • The iOS app hasn’t had any updates at all since 2019
  • The developer has signalled the end of Scrivener 3, despite only releasing the Windows version less than a year ago
  • Scrivener 3 remains buggy
  • Other more-modern apps work better all round, especially across OS platforms
  • Other apps are updated regularly
  • Other apps sync between macOS and iOS without needing Dropbox

I currently regard Scrivener as abandonware.

Angel

1 Like