Huh, it's not segfaulting for me anymore.
But even then, we can support other schemes through Gemini. Perhaps for gmlnm it could be supported through a special visit-with-other-scheme command? For gmni it could just be an option.
gmnlm https://sr.htreports that the given URL is not a Gemini one and promptly segfaults. However, Gemini does allow requesting URLs of other schemes through the Gemini protocol (i.e. going to
https://sr.ht). This could be supported, with a warning to the user if the scheme is non-Gemini (i.e. letting them know that it will still be requested through Gemini).
Best way to do this IMO is to offer to either:
- Save it to a user-specified location (or $XDG_DOWNLOAD_DIR)
- Pipe it to a user-specified program, possibly after saving it to a temporary file (user should be able to enter e.g.
vimand have it just work)
Okay, that makes sense. From the discussions I've seen (i.e. this one), tables are a difficult feature to get right. The most common format is pipe tables:
| Header 1 | Header 2 | |----------|----------| | Text 1 | Text 2 |
There are many related extensions adding support for things like column alignment, but this is the basic idea. See the linked discussion for some pros/cons.
We can support multiple table formats. I think we should support pipe tables initially, and add more stuff as we move forward.
P.S: It was weirdly difficult to find the Markdown page for sr.ht. Could we make it more widespread somehow? (e.g. putting "markdown supported", which links to the page, below or near text boxes supporting markdown).
There's a possibly relevant bug: https://github.com/miyuchina/mistletoe/issues/60. It's about the parser not dealing properly with tables without headings (it could be why the other tables in the README worked?).
I don't understand what you mean by 'commonmark standard extension', but I'm guessing you're talking about clearly defining how tables would work. There's some general consensus among Markdown parsers about this, I'll see what I can find tomorrow.
P.S: My development environment is completely broken at the moment, so I may not be able to make/send patches immediately.
We're using mistletoe, which is supposed to support CommonMark, and we've only added plain links on top of that. Nothing else is supported, at least at this moment. From the looks of it, CommonMark doesn't support tables, so even the current state is just mistletoe being nice.
For now, I guess, use inline HTML for tables containing images (but this issue should stay open until we actually decide on the feature). I'll check mistletoe code tomorrow, see exactly what level of support is provided for tables. I suspect there's a parsing precedence issue somewhere resulting in images overriding the table from being parsed properly. I may end up submitting a ticket for mistletoe and implementing a fixup on our end (we can override mistletoe functionality in our Renderer class).
Bug filed in mistletoe: https://github.com/miyuchina/mistletoe/issues/102