@josias There's only one thing I miss from gemtext and that's a way to escape code blocks. Like, some way to include the characters ``` in a code block.
@almaember I personally do that by indenting those characters with a space.
This is also a problem in Markdown, which resolves it by having two kinds of code block delimiters, ``` and ~~~.
@josias Oh yeah. I think the best solution would be to require the alt text to be duplicated on the closing end. That would allow you to include (in theory) any arbitrary text in a code block.
@josias A way to tell the browser the difference between a code block and an ascii graphics block so the browser can just block ascii junk.
@devinprater Do you think this could be possible with existing Gemtext? Clients might be able to determine whether or not something should be read by whether the alt-text contains "ascii" or "graphics" or something like that.
@derwinmcgeary You can already serve org-mode with Gemini, but that requires using Emacs to use it properly.
Unfortunately, elpher doesn't support org-mode directly at the moment.
I would like support for stock Markdown or maybe CommonMark. The current markup is *almost* there but it uses EOL as a paragraph break, which really doesn't work well with common editors.
@suetanvil Markdown is difficult to parse and render properly unless you're just converting it into HTML, which isn't ideal for Gemini.
It's not straightforward or simple to implement, unlike Gemtext. Something between the two seems appropriate, at least IMO.
Actually, I'd be content (well, less annoyed) with gemtext as-is except that adjacent lines form paragraphs with blanks as a separator.
I mean, it's a trivial script to fix this but that's always struck me as Just Wrong about the design.
@PetabyteStudios At this point Adobe flash might be retro enough to fit into Gemini. Not simple at all though.
@josias support for tables would be nice.
And there might be some cool use cases for streaming. For example a syntax for replacing previous lines. Something like terminal control sequences, but simplified & with nicer syntax?
@antolius That's not a bad idea. It's out of scope for this, as this is supposed to follow the philosophy of Gemtext while adding a couple features, but this could be useful elsewhere.
To support basically any environment, I think instead of having the client render it directly, a compiler should turn the source into the actual control sequences. That should make it run anywhere.
Whether this is a good idea or not is another question...
@vidak Gemini clients are only supposed to make one request per page, so embedded images wouldn't work in any spec-following client.
I think Lagrange's approach to inline images in existing Gemtext in as good as we'll get, allowing you to click an image link to load it. It already works pretty well.
In my opinion, Click-to-load is a great compromise between inline images and external ones, and actually fits fairly well into Gemini.
1. As you mention elsewhere, wouldn't compression be a server and client feature? Gemini doesn't forbid sending or decompressing gziped files.
2. As for TOFU, I liked the concept of also loading the capsule via Tor alongside the first request to see if the certificates match before adding it to the list of trusted certificates. Could that work?
You could embed an image right in a Gemtext file using a data-uri.
For example —
=> data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg== The "alt" Text For The Image
The Gemini browser just needs to display it.
(Terminal based Gemini browsers could display images too as a sixel, or some other Terminal image technology — that most people are unaware but are old.)
@josias inline images. If Gemini never concedes its blinkered stance on images nobody (other than people who write gemblogs about how great Gemini is) will ever actually use it for anything
@ItsTheManOnTheMoon How about the clients that make images click-to-load? Are those reasonable in your opinion?
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).