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.
@Ivar How do you like the new long text editor? Have we addressed the issues from your point of view - maybe not all of them comprehensively, but by and large?
@rdb I have actually been thinking of popping in here to write a few words, but haven’t found the time until now.
First of all, I’m really glad for the response to this post. I’m usually not writing in these kind of forums, and didn’t really expect anyone would listen to me. I’m really glad the most urgent problems has been fixed, like the risk of data loss if you would start typing when a long text field was selected in the table view, and the whole view collapsing when you tried to select text in the expanded view.
Still, there are a few annoyances left:
When I start typing in a long text field in the table view, now this is what happens: 1. The first character I type is inserted at the end of the text field (expected). 2. The text field expands (expected). 3. The insertion point is set to the beginning of the text field (not expected). 4. The rest of the text I’m typing is inserted at the insertion point (expected, but still messes it up because the insertion point has been moved). So if I start typing “Hello” into an empty long text field in the table view, the result will be “elloH”.
In the record view (the one you get to when pressing the expand arrows in the table view), the text field will expand to the height of the text in the long text field. This is great! But when I click on it to make changes, the height of the text field will become fixed, meaning it will shrink if you have entered a lot of text, making it harder to see all the text you have written. This is not so great. From a UI standpoint I also think it’s confusing when elements change size for no apparent reason.
I still really miss being able to turn off markdown formatting. I actually always write in markdown, even in the long text field, but I think the advantage of markdown is that you are in full control of the formatting. When the markdown syntax gets hidden and replaced by formatting, I get confused. I would suggest implementing the kind of subtle markdown formatting being used in apps like Byword or MultiMarkdown Composer. This formatting doesn’t hide the syntax, but make it clearer. For example, a bold word would look like **this**, instead of this. But even if this was the case, I think there should be an option to treat text like plain text and not markdown. What if you would want a long text field with just python code? Then every comment would be treated as a heading. What the long text editor is trying to be now is a word processor. That’s fine, but if that’s the case, I also think there should also be column type for plain text. Just like the normal text field, but also allowing line breaks.
On my phone the long text is presented as plain text. This is inconsistent.
I still miss being able to enter line breaks, not just paragraph breaks.
Again, thanks for listening and keep up the good work!
)