I think think many clients will opt to implement markdown parsers (heck, some may even try html parsing), but I think it would be a bad call to include it in the spec for gemini. Now that it has been brought up, I may add markdown parsing to the client I am working on (I am still in planning stages figuring out how I want it to work and the necessary structs and execution flows). I think markdown can be rendered in cool/sensible ways in a terminal as well, so it can be a very nice way to go. I think that inline links can still be handled in the bracket number style (link[7]) that many use in gopherspace, for example. However, markdown will require the writing of an actual lexer/parser rather than just reading in lines and looking for a magic string at the beginning. Not a huge deal for some, an insurmountable challenge for others. Me personally, I think it would be fun to code it up, but only as an additional feature for my client and not as a core part of gemini. I would definitely support a few optional things that can be rendered as a part of text/gemini. I had brought these up with solderpunk earlier in development of the spec and they, I believe, were deemed implementation details for the client... which I am mostly fine with. My only worry is that if we leave it to clients to add support for things like bold text in gemini documents we will end up with a fragmented situation where some clients support one way of doing it and others support others. I think picking the bare minimum essential styling and providing that as a part of the spec would be helpful in making text/gemini attractive without going the way of html/css/http. I think the following limited set makes sense and can be handled with basic string replacing if people dont want to parse: 1. Bold Bold can be rendered in most terminals as bold. Clients that prefer could just string.toUpper or the like. If this was done with opening and closing tags a substring replace (or proper parse) could just replace it with the escape sequences for bold. 2. Italic Same situation as bold, more or less. For situations where italics is not supported by whatever viewing system, the tags could be replaced by asterisks? Like *this*. 3. Bold-Italic Mostly the same as above, but a combination. 4. Heading (only one level) This can be rendered a number of ways. In a terminal I would likely render this with the escape for 'inverse' text. Makes it really pop. I think the above four would provide sufficient styling to handle most basic uses and provide a little bit of flair. If people were into the idea, we'd need to come up with how to denote those things in a text/gemini document. I am not adamant that the above needs to be included, but I think it could be nice. As for text reflow: I am not in favor of html style text reflow (ignoring more than one space char). I think it makes sense, like gopher, to render text as provided. The exception to this would be word wrap, particularly for clients intended on width limited devices. My plan is to have word wrapping be a togglable feature in my client. Anyway, much like solderpunk: just thinking out loud. ps. As to bullets: since gemini is utf-8 by default bullets should be very much in play. --? Sent with https://mailfence.com Secure and private email
---
Previous in thread (6 of 148): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (8 of 148): 🗣️ Brian Evans (b__m__e (a) mailfence.com)