💾 Archived View for rawtext.club › ~sloum › geminilist › 000381.gmi captured on 2020-09-24 at 02:36:44. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Aaron Janse aaron at ajanse.me
Sat Jan 18 22:18:39 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` On Sat, Jan 18, 2020, at 1:33 PM, solderpunk wrote: > Hmm, I really would not have had any expectation that quoted Gemini > syntax would do anything at all. > > What sort of context would you expect this to occur in? I often see quoted syntax (e.g. links, lists) on StackOverflow. However,I haven't seen quoted syntax in phlogs. Plus, supported mixing nestedsyntax could be a PITA to implement. Also seen in the wild:* nested lists of links (nice to have, but not sad if unsupported)* hyperlink headers (this sounds like a mess regarding `= > #` vs `# = >`) Either way, I'd still specify what nesting is/isn't allowed. > I guess this is harmless. It feels a bit to me like we're adding it > just because Markdown has it - unlike headings and lists and even, > occasionally, quotes, I don't know that I've ever seen a horiozontal > rule used in Gopherspace. But I don't see a good reason to disallow it. I see horizontal rules used in gopherspace all the time: = > gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/a-new-start.txt= > gopher://zaibatsu.circumlunar.space/0/~tfurrows/phlog/2020-01-02_clickBaitGeneration.txt= > gopher://tilde.team/0/~ben/blog/weechat-setup.md > It feels very strange to me for a syntax specification to explicitly > list stuff from a different syntax specification which isn't allowed. You make a good point here. Maybe, we instead specify that clients MUST NOTsupport non-specified syntax, in order to discourage pages with un-specifiedsyntax from being published in the first place. > I don't want to explicitly ban hard-wrapped text, I don't see the need > to. I think this syntax actually degrades pretty gracefully when fed > hard-wrapped text that is shorter than the viewport, and that's nice. That makes sense. However, would it be unreasonable to state that users"SHOULD NOT" hard-wrap, since doing so degrades quite poorly on mobile? > > > 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 basis > of the first three or fewer chars, as a header or list, it can be passed > to a function than handles a header line or a list line, and that > function has access to the whole line. > > That said, maybe we should add a limit anyway. Otherwise clients have > to write totally generalised code to handle arbitrarily many levels, > which could get tricky. Hmmm. If max depth is one, that makes sense. Same if max depth is two. Butonce max depth is three, it sounds like clients would be using generalizedcode anyway. Plus, a shallow max depth might be very confusing for authorsusing text/gemini. > > > 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 as > the heading and list syntaxes. But for quotes, I beg that a space character is allowed between thegreater-than symbols in nested quotes, so that we don't have to abandonthe way quotes are used in emails. In fact, I think the spec should saythat a single space after a ` >` symbol should always be stripped. > > Speaking of these...what happens when a client encounters this: > > ** Foo > ** Bar > ** Baz > > i.e. a bunch of allegedly nested list items which are not emedded in a > higher-level list? > > For a simple text-based client which only uses the nestedness level to > determine how many spaces to stick in front of the line, this shouldn't > post major problems. But fancy clients planning on doing graphical > things (I'm actually thinking more about quotes here than list items) > might choke if not carefully written. Should we explicitly require > correct nesting? Or explicitly say clients must be resilient against > weird nesting? I personally think resilients is a bad idea. It's partially to blame for somany web browser quirks nowadays. I think that if fancy clients refuse torender invalid syntax, that could be a good deterrant. OTOH, it's sometimestough to contact gopher/gemini users, so maybe nobody would be able to tellthem something's wrong. Unless we write scripts to verify that text is validtext/gemini, and/or integrate this functionality into servers? Cheers!