After years of using the Gemini protocol, I see only one significant issue in this beautiful ecosystem: its incompatible Markdown format, Gemtext. It requires constant adaptation, and I definitely can't adjust everything in large articles, such as one-line links or links with URLs in scopes. It's madness - just thoughts.
Yes, you might argue that "it's for privacy," for example, to prevent the preloading of inline images. However, Gemini allows for external redirections, so why not make it possible to preload content from the current host?
I am close to implementing a Markdown renderer in the Yoda browser and using it instead of GMI, at least for my own use.
Sep 19 Β· 4 weeks ago Β· π chilledfrogs
18 Comments β
π skyjake [mod...] Β· Sep 19 at 04:53:
If you prefer Markdown, you should just go for it and implement the support. Gemtext may be the primary document format due to pragmatic reasons, but there is no rule against supporting whichever media types you want.
Even Lagrange allows viewing Markdown, albeit in a limited fashion.
π½ spc476 Β· Sep 19 at 07:58:
And the MIME type is text/markdown. Check out RFC-7763 and RFC-7764 for more information.
π stack Β· Sep 19 at 09:15:
Which flavor of markdown...
π ingrix Β· Sep 19 at 20:22:
I agree with skyjake that you should definitely implement a markdown renderer if you feel the need.
In defense of gemtext I will say this about it: it is really easy to read in raw form. I use lagrange and other graphical/semigraphical/curses-based browsers plenty, but I also do a ton of browsing of geminispace on the command line. Markdown is usually not too bad for raw viewing but there are features that can make things really confusing to visually parse. And I am coming to the conclusion more and more that building a network around something that you can't look at in raw form (ala html) is building a network for bots, not people.
π pista Β· Sep 20 at 00:07:
The only thing that really bothers me, from a text formatting perspective, is the lack of either an italic or underline tag.
You donβt need both, but you really should have at least one of them because there needs to be a way to call attention to titled works and separate them from sections of published works. Same for identifying foreign words within other body type (e.g. π΄πͺπ€).
Yes, you can force it by rewriting using dedicated Unicode italics, but damn is it dumb and bad for search.
π» ps [OP] Β· Sep 20 at 04:15:
@pista, in my case, also I want inline code support (as per the specification) because I am already using scopes, so why not format it? Gemtext is definitely something for the plain text extension. I feel uncomfortable with it and prefer web/Markdown because of that.
π stack Β· Sep 20 at 14:18:
A few things I really miss in gemtext:
- horizontal rule
- Emphasis of some sort for runs of text inside a paragraph
- inline switch to ```fixed/preformatted``` text
I write as if these were _already_ implemented anyway. [^1]
Tables are really nice to have, and I struggle with ASCII/unicode line graphics (and nice round corners) manually a lot. I can see it would be more of a pain to implement than the rest of Gemtext.
[^1]Maybe someone will create an option to render bold or italic -- it would not break anything! Why not?
π¦ zzo38 Β· Sep 20 at 21:31:
I think Gemini format has the advantage that the text format is readable and also easy to parse by a computer program, but that when you want a more complicated text based format, there is escaping and other things to be considered. I made up a binary format with emphasis and some of the other features, since I think a binary format has many benefits. I also think it is helpful if some features are optional that you can easily skip past them if disabled or unimplemented. (I also think there are problems with Unicode, but that is another issue.)
π jsreed5 Β· Sep 21 at 01:17:
Gemtext is one area where Gemini's ancestral link to Gopher, rather than HTTP, is quite evident. Gophermaps are line-oriented, where a parser can understand what kind of line it's dealing with just by looking at the first few characters. Gemtext uses the same paradigm, but unlike gophermaps, it's also designed to be easily readable in source form. In-line anything goes against that paradigm--one can argue whether that's good or bad, but that's why it works the way it does.
I suppose if one wanted to add tables, one could extend gemtext to add a "table toggle," similar to how three backticks are a toggle to begin preformatted mode. Then, the following lines could be tab-separated values that are filled into the respective columns of the table. A second toggle would return to text mode. That would probably fit the line-oriented paradigm of gemtext the closest.
When I want to add tables to gemtext, I use the preformatting toggle to "burn" them in. It's easier for me, and it gives me the freedom to format the table as I like.
πΎ jecxjo Β· Sep 23 at 21:49:
The thing i love about all of the smolweb protocols and formats is that they all can be minimally implemented in a few lines of shell script. Pipe openssl to awk and you have a gemini client. Do it in reverse and you have a gemini server. nex is just nc and find.
Gemtext is again super simple. Just txt with links. No inline formatting means awk line matching is two cases: links and preformatted text.
Smolweb is litterally a game of I can name that tune in X lines of shell script.
π¦ zzo38 Β· Sep 23 at 22:07:
Adding tables would make it more complicated to implement and use, especially in a text-based format, although tables are useful for displaying data, and if the data is stored that you can also make calculations, sorting, filters, etc, then that is also more useful, so it might be useful to use a separate file (e.g. CSV or DER) for the data tables than for the text, like pictures, sounds, etc also use separate files. (Although, there is also a problem with the preformatted toggle in my opinion, that lines beginning with ``` cannot be used as plain text)
πΎ jecxjo Β· Sep 24 at 00:20:
we should be embracing different file types for different use cases. personally i would rather watch a video in vlc than some crappy embedded player. why wouldn't table data be any different.
π¦ bluesman Β· Sep 24 at 01:24:
@jecxjo What if the embedded player is VLC?
π norayr Β· Sep 25 at 00:15:
why embed?
even pictures are not necessary to embed. you click the link, the image gets saved ho the temporarylocation and opened in a dedicated picture viewer, whichever you want.
same with audio or video.
one of the problems of user interfaces is that we lost modularity and composability we had in console.
programs are monolitic and have everything in them.instead we could have modular programn, each part of a program could be changed with something else.
lets say our chat programs have contact list windows, chat windows, video viewers.
why can't we change a program that shows a contact list with other program that shows a contact list?
so less features in gemini browser the better.
π stack Β· Sep 25 at 00:31:
Except then you wind up with 50 windows open and a total mess of files saved by various programs in different directories. And trying to get a dozen other people's programs to work with yours is harder than just implementing a bunch of code yourself.
But I understand your sentiment, and do not disagree.
π¦ bluesman Β· Sep 25 at 00:50:
@norayr You can always pipe gemget into less.
πΎ jecxjo Β· Oct 02 at 01:31:
the issue i see with embedding is you are now forced into the defined method of media consumption. the choice of how to consume goes away.
As an example I like running on low power hardware as my daily driver. it was nice to be able to load videos in an mpeg format and pipe them to a player that directly decode them on my video card so there was almost no CPU. cant always do that when the browser decides the player.
π stack Β· Oct 02 at 12:59:
There is usually a configurable subsystem that decides how to open files of different MIME types. I always forget how to do that and have to look it up.
Source