Hm, but there is already Shift+Enter keyboard shortcut. Doesn’t it work for you?
1 Like
Correct! Thanks, @Chr1sG, this is for simple Text Tables, not entities…
BTW, Shift+Return at least on the Mac is used for the classic Enter: It will add a new line but not exit the container (i.e. it stays in the same row). You can test that with lists and paragraphs, where it just starts a new line without an added padding. Return on the Mac does Return, and thus move to the next container (or row) adding an li in a list or starting a new paragraph, etc.
Google Sheets uses Return to move to the next row, Shift + Return to move to the previous row and Alt/Option + Return to insert a new line in the existing row. IMHO that’s in reverse
So from that perspective I would suggest at least on the Mac for both Table and Text to add a new row on Enter (Return key)—just like Google Sheets and most apps, and just insert a line break with Shift+Return (as it should be) or Alt/Option + Return (like Google Sheets).
Now, the UI can say “Enter” and most people do not notice the difference between Enter and Return.
1 Like
Please add a simple way to add new rows in tables
That would be nice.
Tables in a document aren’t the same as spreadsheet - the whole editor context is different. You much more frequently want to put carriage returns in cells, and changing how enter works based on whether you’re inside a table cell or not doesn’t sound very intuitive.
Also, you should be able to add either a newline or a full paragraph inside the cell. So both return and shift+return are already taken. It has to be something else (option+return or something) for a newline, no?
Well, in a document context RETURN (my Macs don’t have enter anymore) does move me to the next container like a new paragraph or a new list item. SHIFT+ENTER gives me a new line in my current container (i.e. same paragraph or list item).
I don’t see why an in-line Text Table should behave differently. And even the Entity Table Views actually would make sense with that setup as their layout does not encourage multi-line entries.
That said, while I’m no big productivity shortcut fan, I usually unconsciously learn the editor and table shortcuts. So rather than perfect, I’d have one now so I don’t always have to grab, click, search, click… 
I don’t see why an in-line Text Table should behave differently.
The point is that in the context of a table cell, “the next container” (as you put it) could be either a new paragraph inside the cell, or a new row for the table. It’s ambiguous.
Given that, I would expect return to give me a new paragraph and shift+return to give me a new line, because that’s the behaviour in the rest of the document. And a different shortcut for a new row.
When you say “new paragraph” and “new line”, what do you mean?
Inside a table cell there are usually no paragraphs, moving the caret to a new line in the same cell is exactly what I would shift+return or alt+return expect to do. And then that leaves me with return to get a new row…
Anyway, just tested this on Apple Notes and their apprtoach is:
Returngives me a new row and moves the caret into the first cell of itAlt+Returngives me a new line inside the current cellShift+Returnmoves the caret into the cell above the current cell
This feels in line with many apps and Notes does combine text and tables in a basic but neat manner. So I’m not sure how things work on Windows as I’ve not used it for 2 decaeds, but I would argue that Apple has generally done their homework regarding UI details and interactions. Their HIG are still a key reference for many of us desigenrs.
So if in doubt and there’s no good reasons against, I would argue for simply coping them. 
1 Like
Thanks for clarifying @HereBeBeasties!
To me new paragraphs are a bonus. If I can have that, cool. But most inline tables from Notes, to Google Docs and Confluence don’t really have that I think.
Respectfully, I strongly disagree. A document editor should let you cut/paste text from outside of a table cell into a table cell, and it should not mangle the formatting as it does that.
Ipso facto, if new lines and paragraphs are different things outside of a table they should be different things inside a table cell too. And keyboard shortcuts should behave consistently inside/outside a table cell also.
The simplest thing to do would be to keep the current enter and shift+enter behaviour and add a new shortcut for new rows.
2 Likes
Happy to go with your suggestion—as indicated before—if that means I don’t have to grab the mouse each time I need a new row. I use tables A LOT, and currently it’s a pain.
2 Likes
+1 for simplifying adding new rows to tables without grabbing the mouse.
TBH I can’t believe that this is not an already existing feature. I guess not all nerds are keyboard warriors like myself and @njyo!
@HereBeBeasties on avoiding text-mangling on paste: Agree. But I don’t see why we need to think of that as a goal precluding keyboard shortcuts for creating new rows? Perhaps I’m missing something.
Take Google Docs and how they have pasting as a simple example:
- I select a cell and paste: Every new line in the pasted text becomes a new row in the sheet. Useful if I have structured text that I expect to become rows in a spreadsheet.
- I select a cell and, double click it/ start typing into it, and paste: Every line in the pasted text becomes a new line inside the cell. Paragraph spacing is retained and the text is kept as-is, but within one cell.
On the other problem of resolving the ambiguity between creating new rows and paragraphs: It’s been tackled by many before us. Don’t think we need much rocket science there. Again, Google Sheets is one example: Press Enter on a cell to enter “Edit mode”. Type text. Create paragraphs with CTRL+Enter. Leave edit mode by pressing Enter again. The cursor will then also move down to the next row.
At least as far as my own user needs go, Google Sheets manages to allow me to navigate to the next row (‘create a new row’), paste, navigate, create paragraphs, etc. without creating much confusion. In fact, I’d argue the opposite: Users are more confused when these features don’t exist as we have been accustomed to Excel, Google Sheets its many clones since the beginning of time.
2 Likes
bjornlll wrote:
@HereBeBeasties on avoiding text-mangling on paste: Agree. But I don’t see why we need to think of that as a goal precluding keyboard shortcuts for creating new rows? Perhaps I’m missing something.
I never said it did, the complete opposite in fact:
The simplest thing to do would be to keep the current
enterandshift+enterbehaviour and add a new shortcut for new rows.
bjornlll wrote:
Take Google Docs and how they have pasting as a simple example […]
You are talking about Google Sheets, not Docs:
- A Fibery document is not a spreadsheet. It is a document
- An embedded table in a document is also not a spreadsheet, unless you have specifically embedded a spreadsheet, OLE-stylee
Spreadsheets and document editors are necessarily fundamentally different in terms of how they handle text and tables:
- If you paste text into Google Docs or Word, it doesn’t magically convert it all into a table on the line-breaks
- If you paste text into a table cell in Google Docs or Word, it doesn’t magically convert it into new rows in that cell - it embeds it all into the cell without making new cells
This is about principle of least surprise. In Fibery’s document editor, I expect CTRL+B to bold text, CTRL+I to make it italic, enter to give me a new paragraph (unless I am inside a code block, where there is only the concept of newlines and there are no paragraphs) and shift+enter to give me a new line.
When editing table cells, I often want to be able to insert both paragraphs and new lines, and I would therefore like the keyboard shortcuts to be consistent when using the editor, both inside and outside, in much the same way that I don’t expect to need to have a different keyboard shortcut to make my text bold. It should all be the same thing.
If you agree with that, it logically follows that you need three keyboard “shortcuts”:
- The two we already have (let’s not break existing behaviour and let’s keep things consistent):
- One for paragraph (<enter>)
- One for new line (<shift>+<enter>)
- One for new row (<ctrl>+<enter> perhaps, but it shouldn’t hijack the above two)
It’s either that or ban paragraphs from table cells (as otherwise how do I make one if you take away one of the existing options above?), which would suck.
I hope that makes things clearer, although I think this topic has been done to death now.
2 Likes
Yes, meant Sheets. Thanks for the detailed response!