About tables in gemtext (yes again ;)

renders links csv or tsv link in the document

I think that the human readable rendering of a csv file in a gemini client is a good feature as such. On the other hand, let's not forget why we use tables, we don't make databases. This approach forces you to multiply as many files as you want to integrate tables, which seems to me to be a very cumbersome way of working.

integrate the csv syntax in main document

gemini://auragem.space/~krixano/20210531.gmi

The second proposal solves the problem of multiple files by integrating them directly into the body of the document. It solves this aspect, but on the other hand, it makes the source file unreadable. Yes, I say non-readable: have you ever had fun counting the number of commas in a csv file to know which column it corresponds to? This would mean that it would not be possible to read the information correctly without using a client, which seems to me to go against the philosophy of gemtext.

in a purely non-objective way, I also find that integrating csv or other variant in a gemtext is not elegant.

It is also to put the foot in the door to integrate little by little code in the gmi files what seems to me not to go in the philosophy of gemtext.

the "preformatted table" tag proposal

The first time I saw the tables with the preformatted text blocks, I, like I think a lot of people, thought it was a bit of a hodgepodge. But now, having seen in which context it was needed (gemlog) and the other possible solutions, I find it a very interesting way to present tabular data. I would like to point out that for me, a table is not a presentation but a content. A 2-dimensional information can hardly be transmitted without using a table, it is not just cosmetic.

if we compare the size of the files, the csv and derived version wins by far. This is of course quite true, but I remind you that the goal is not to write databases, so most of the time the size will not matter given the volume of data.

In this sense the use of preformatted text already plays its role well. The only problem I see is that it's not very clean and the tables are relegated to second-class status with everything that doesn't fit, which I think is a shame.

That's why, in order to facilitate its integration, a specific tag ||| that would be used like the preformatted text ``` tag seems to me an elegant solution.

very easy to integrate : a basic implementation would just be to replace the ||| tag with ```

the source document remains and will always remain fully readable

it is still possible to parse the table and adapt to screen width

this format allows for easy and intuitive integration of cell merges

i also know that the algorithm to parse table is not trivial (must be able to handle different graphical representations of borders, merges, multilines) but it doesn't seem insurmountable to me either.

we must prohibit the use of links in cells to avoid that it is diverted to make layout of presentation

to think about

how to produce these tables easily ?

For me it is more a problem of text editor and for example with vim, we can already easily do a lot of work. It is indeed a point to dig (to be inspired by orgmode ?) and to improve.

do we have to impose a style of table representation ?

we should think about a precise and simple standard to represent a table. First of all, the use of ascii characters ( = - | ) seems to me important, the nice rendering with unicode characters can be done on the client side.

This would greatly facilitate parsing and homogenize the rendering of source files. We could also have a "compatibility" mode that would try to parse more exotic forms of table if the need would be felt. In any case, I don't have a strong opinion on the matter.

source examples

gemtext with csv

how to specify that the cells are merged ? it could just be the same data in two different cells and it's difficult to read informations for me for the first table for example.

gemtext with preformatted table

First table is for classic format (single line data) with label and foot note which is detected because there is no last line in the table.

Last table illustrate multiline, cell merging and higlighting another line than the header.