💾 Archived View for rawtext.club › ~sloum › geminilist › 000379.gmi captured on 2020-11-07 at 01:26:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sat Jan 18 21:33:03 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` On Sat, Jan 18, 2020 at 11:20:10AM -0800, Aaron Janse wrote: > I think we made an oversight: syntax nested within quotes. > > Client: > *doesn't know to make quoted link clickable* > *doesn't know to fancy-render the quoted list* > ``` Hmm, I really would not have had any expectation that quoted Geminisyntax would do anything at all. What sort of context would you expect this to occur in? > * Preformatted text toggle lines only need to *start* with three > backticks. Specify the significance of text after the backticks. I think I'm probably fine with this, does anybody have objections? > * Specify that preformatted code blocks are intended for content such as > ascii art and code, meaning that it should be easily copy-pasteable > into a text editor without needed to undergo extra steps to revert it > from its displayed form to its original form Yeah, it might be a good idea to emphasise the intent to preservecopy-and-pastability. > * Add horizontal rule lines (three+ dashes) I guess this is harmless. It feels a bit to me like we're adding itjust because Markdown has it - unlike headings and lists and even,occasionally, quotes, I don't know that I've ever seen a horiozontalrule used in Gopherspace. But I don't see a good reason to disallow it. > * Specify that ordered lists MUST use plus sign markers Yep. > * Specify Tomasino's nested list system I think I'm still onboard with this, although I'm starting to wonderabout how these nested lists will look when rendered by a basic clienttreating them as text lines. I'm not sure it degrades to somethingterribly readable. > * Explicitly specify markdown syntax that is not allowed. It feels very strange to me for a syntax specification to explicitlylist stuff from a different syntax specification which isn't allowed. Ican see it being helpful to point this stuff out in a tutorial forpeople learning text/gemini, but in a formal specification of a markupformat, it goes without saying that anything which isn't explicitlysupported is unsupported. > but maybe we could even advise clients to shame this syntax the same > way modern web browsers are shaming non-HTTP sites? Wouldn't doing that (all questions about whether this is appropriatebehaviour aside) require writing code to detect all the stuff that we'renot supporting precisely because it's a pain to write code to reliablydetect it? Seems counterproductive! > Regardless, here > are some things that I think we should explicitly ban in text/gemini: > ... > * Hard-wrapping text I don't want to explicitly ban hard-wrapped text, I don't see the needto. I think this syntax actually degrades pretty gracefully when fedhard-wrapped text that is shorter than the viewport, and that's nice. Ithink the vast majoity of people will end up taking the long lineapproach because it will support a wider range of clients (especiallynarrow screens) and some things will render slightly nicer. If a smallpercentage want to stick to the old ways for whatever reason, knowingand accepting the downsides, I see no reason not to let them. > Are we really limited to a max depth of three? Even if we allow unlimited > depth of headers and lists, clients would only need to read the first two > chars of a line to determine its type (unless we add horizontal rules, > in which case we'd need to read three characters). Good catch, technically speaking once a line is detected, on the basisof the first three or fewer chars, as a header or list, it can be passedto a function than handles a header line or a list line, and thatfunction has access to the whole line. That said, maybe we should add a limit anyway. Otherwise clients haveto write totally generalised code to handle arbitrarily many levels,which could get tricky. > Well, worst case scenario, if someone really badly wants comment threads, > maybe they could use nested quote blocks (assuming we figure that out). Well, it seems like the > syntax generalises in exactly the same way asthe heading and list syntaxes. Speaking of these...what happens when a client encounters this: