This is my first post on this forum. I just recently started using SeaTable, coming from AirTable, and so far I’m loving it. The only thing I have a problem with is the long text editor. I will list some problems with it hoping that the SeaTable developers read this.
If I have a long text cell selected in a table and start writing, what I write immediately replaces the content of the cell. This is excepted behaviour for cells with shorter content, but I think for a cell format that’s ment to be used for longer texts, this behaviour increases the of involuntary data loss. I think the AirTable approach of appending the text you start writing is the right solution.
If i select some text through the means of holding down my mouse and draging, and then releases the mouse outside of the text editor, the editor is collapsed.
This might only occur on a Mac. If I type something that is replaced by the OS’s text replacement system and then hit space, the space is lost and I need to type it again.
There’s no way of inserting a line break that does not break the paragraph. So if you for example would like to quote a poem och some part of a Shakespeare play, every line would end up in a separate paragraph. Those kind of non breaking line breaks are available almost everywhere (in html the markup is , in markdown you type two spaces in the end of the preceding line, in Microsoft Word you hold down shift while hitting return, etc.) and I think the should be available in SeaTable as well.
In the Keyboard shortcuts popup it says that command ⌘S will ”Save file”, and that ⌘V will ”Paste screen shot”!
It would be really nice to edit long texts directly in the record details popup.
My suggestion is to do one of the following things:
Skip the formatting of the long text column. You will be able to type markdown markup in a regular text field as well, just not have it previewed.
Offer a third text column type, for plain text that supports multiple lines.
The idea of having formatted text in a field is cool, but with all of the bugs there are right now, just a plain text field that works as well as the single line text field, would be so much better!
Absolutely. When you are in a table view and press the round button with the expand arrows next to the line number, you get a detailed view of the row. If I want to edit a long text field from that view, I first have to click on the text to open it in the editing view, before I can start edit. Compare this to the single text field in SeaTable, or the long text field in AirTable, where I can edit the text directly from the detailed view.
One more thing. The heading of the long text editing view is the name of the column, as opposed to the name of the row, which is the case for the detailed row view. This makes it hard to see what row I am editing. Yes, I can see which line is slightly darker in the background, but the contrast to the other lines is really small, and the editing view sometimes covers the first column of the table.
And an update on point three of the first post. I realised now that the space is inserted, but for some reason the text insertion point is placed before the space instead of after it.
And one more bug: Pressing command backspace on a mac should delete all text left of the insertion point on the current line, but not touch the line above even if the line break is a soft one, caused by text wrapping. In the long text editor it removes the whole paragraph, even if it is wrapped.
I’ll jump in this thread to add two more thoughts on the long text field.
Consecutive line brakes aren’t respected. Sometimes you just want to leave a space! (Example: If you enter 10 line brakes in a row, it looks good while editing, but when you close and re-open the editor it shows as a single line break.)
Lack of ability to see the markdown. For me the most frequent reason I need to do this is to check the URL of an embedded picture. (I changed domains, and URLs in the long text field were not updated. The new domain-changer script didn’t work for me, but that’s a different topic.) It would be great to add a toggle to switch between markdown text and formatted text views.
And one more thing: I have a long text column with a color rule that marks every field that is not empty. Now, if I open one of those fields and enter some text, then change my mind and delete the text again, the rule-system still thinks it’s not empty. To make the color disappear I need to select the field in the grid view and press delete from there.
Another reason to be able see the markdown syntax is that you feel that you are in full control over the formatting. Personally I have always preferred markdown editors that highlights the markdown syntax (ie Byword or iA Writer), over those who hides it (ie Typora).
Hi everyone, I found this topic and saw that enhancements on Long text are planned for v. 4.4 so I hope it’s not too late to tell you about this weird bug I discovered : when copying formatted text from a long text editor, nothing happens if you try to past it in another long text editor… Please note the long text editor behaves this way when you’re editing a database and also a universal app (editing fields’ help text, or long text element on custom page) : I imagine it’s the same component…
If you want to copy the whole text and you’re editing a base, no big deal, just don’t enter the long text editor, and copy/paste the wanted cell. For the other cases (copying just a part of the text or, in my case, editing long text while modifying a universal app), I found this workaround :
Copy the content of your long text editor and paste it in the formatted view of an html editor (https://html5-editor.net/ for example) => you get your formatted correctly
Copy the content of this formatted view and paste it to your other long text editor
This works, but it’s really weird it doesn’t in a more direct way (and this process is a little bit repetitive if you have to duplicate lots of texts I have to say )
Quick update on the upcoming improvements to the long text editor:
When you navigate into the cell and you start typing (without opening the editor), the text will be prepended to the existing text. No deletion of pre-existing text.
This bug is fixed.
Working on it. As a similar improvement, the long text editor does not remove multiple subsequent paragraph breaks.
Fixed. “Save file” has been removed.
We are working on it, most likely to be implemented in SeaTable 5.0 scheduled for this summer.
Fixed (see above).
Not fixed. Maybe something for the future.
Not fixed in SeaTable 4.4, but recorded as a bug to be fixed soon.
)