It’s rather a small issue, but I wonder if there is a solution or workaround.
Problem:
if I use the seatable_api to append some rows with base.append_row, and the text contains literal asterisks (*) instead of markup notation, the “long text” cell will show no asterisk and a “…” at the end of the text. See the screenshot.
I would assume that the asterisk (*) is treated as half the italic markup *italic*, and the “…” is telling me it couldn’t find the closing half.
However, if I manually edit the text in webpage, the * will remain if I don’t close it with another *.
However then, in the case that I use API to append text containing asterisks to a long text cell, how to keep the asterisk as is, instead of being treated as a part of markup?
What I tried:
Just like in actual markdown, I tried escape with backslash \*, but that doesn’t work. The backslash itself is shown, but not the asterisk.
The choices I have are: 1. use text instead of long text, 2. accept the behavior, it’s not a big deal anyway.
The long text column store content in Markdown format.
The cell in the grid shows a preview of the actual content of the long text. The * is removed when generating the preview, because * is usually used as markup.
As I explained, the * is removed when generating the preview text for the cell.
It is likely the preview text is not generated in this case, and if the preview is not generated, the first a few strings in the field is shown, which contains ‘*’.
Please pardon me commenting again. I don’t want to bother you, but I think you missed my point.
My major issue is: I need to see *, can I do that?
My reasoning is: It’s not right to make the users (through API) not able to use * as actual printable character in the case fore-mentioned.
In markdown, * can be shown by escaping (\*) or backquoting (`*`) it. Thus I was hoping seatable to support that, too. Turns out not.
My point is that: it is not supported only in the cell preview and I explained the underlying reason why it is not supported: * is mostly used as markup, showing * in the preview will confuse users as in the extended dialog, the * is not shown; also, a lot of * in table cells make the UI looks ugly.
As you said, it is a small issue of not showing *, so we don’t have a plan to support it.