💾 Archived View for rawtext.club › ~sloum › geminilist › 000353.gmi captured on 2020-09-24 at 02:37:51. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sat Jan 18 11:45:03 GMT 2020
- - - - - - - - - - - - - - - - - - - ```
On Fri, Jan 17, 2020 at 09:59:18AM -0800, Aaron Janse wrote:
>
> Lines consisting of only and exactly three back ticks (```) are preformatted
>
> toggle lines.
>
> Hmm, this might confuse some people who are used to markdown's allowance of
> specifying the language:
>
> ```python
> print("Hello!")
> ```
>
> Plus, if we *allow* people to specify the language, maybe some clients could
> implement syntax highlighting. Would that be too complex?
Ah, yes, Tomasino mentioned this earlier.
I guess it is harmless (?) to change the definition of these lines toany which begin with ```, not which consist strictly of ```. That letssufficiently fancy clients support this, the rest can just ignore it.These lines are never actually shown to the user, so it doesn't matterwhat junk comes after the ```.
> If not, what would happen if people add text to the closing three ticks?
Well, that's unambiguous. If we didn't make the above change, lines withtext after the three ticks would not meet the definition of a preformattedtoggle line, so a client would identify them as a text line and they wouldbe rendered accordingly.
>
> Lines longer than the client's viewport must not be wrapped, leading or
>
> trailing whitespace must not be removed, etc. Handling of lines longer than
>
> the viewport is client-specific
>
> These two sentences contradict each other, I think.
Hmm, okay, I guess they technically do. Clients can handle over-longlines however they want as long as they don't wrap them?
> Are minus signs allowed for unordered list items? How about plus signs etc?
> I'm somewhat in favor of limiting bullets to astrisks and minuses.
I'm fairly strongly in favour of limiting everything to exactly one wayof doing it. The other day I skimmed the CommonMark spechttps://spec.commonmark.org/0.29/ to reassure myself we weren't doingtoo much wheel re-invention. Holy heck, there are so many differentways to do everything! Simple is best, less is more, one is enough!
> Can top-level bullets begin with a space? What about nested bullet points?
If a line begins with a space, then it doesn't begin with a *! So thenit's by definition not an UNORDERED LIST ITEM. It's a TEXT LINE. Ireally did mean "begins with" everywhere I said it. IMHO this syntaxquickly becomes really unappealing unless the task of deciding whichtype of line a line is remains dirt simple.
Yes, this means no nested lists. It may seem like I've gone nuts andsuddenly happily let a whole bunch of complicated stuff into the spec,but I really haven't! This is still supposed to be a very simplesyntax, which inevitably comes with limitations. There is no nestedanything in the whole syntax. Reliable detection of nestedness in theface of even slight variation in how authors write things will requireconsidering lines in the context of previous or subsequent lines, andthat's a no-no here. I'm only willing to allow all these fun toys in ifwe can do it in such a way that an adequate rendering job can be done byconsidering each line of the file in perfect isolation, with a singlepass of the entire document.
>
> 7. ORDERED LIST ITEMS
>
> I'd further specify what is/isn't allowed here. For example:
> - Some people may try `1)` instead of `1.`. I personally think that spec should
> say that only the latter is allowed but clients may choose to *render*
> ordered lists as the former
> - What about nested ordered bullet points. Wouldn't they start with whitespace?
> - Markdown allows lists to be auto-numbered. For example, the nested bullet
> points would be re-numbered from 1 to 5 in markdown:
> 1. one
> 1. two
> 5. three
> 2. four
> 1. five
> - What about lettered lists (A-Z)? I think these would be cool to have but I
> doubt they'd be worth the complexity. I'd be explicit in the spec
> - What about roman numerals? I don't think these should be allowed
>
> While we could leave some stuff un-specified and see how things play out, I
> think there could be some value in limiting authors for the sake of preventing
> a scenario where making a client is so complex that very few nice clients exist
> (as we see in the world of web browsers).
Okay, I totally goofed up here in declaring the changes as "obvious". Imeant "obvious to everybody who has readgemini://mozz.us/markdown/design_document and accepted is as theirpersonal Lord and saviour". Well, actually, I read that and foolishlyassumed the nice approach to ordered list items was more or less thesame as standard Markdown. Turns out it's not and Michael has done verygood simplifying work here.
As said above, I am strongly in favour of there being exactly one way todo things, and of identifying a line's type being brutally simple. Thistotally rules out letting authors actually write numbers. Actuallyhaving a number followed by a period define such a line type would alsobring a very high risk of falsely identifying ordered list item lineswhen processing hard-wrapped text if a sentence ending in a number, like"Ten Gemini crews flew low Earth orbit (LEO) missions during 1965 and1966." was wrapped in such a way that the final word was at the start ofa line. Yes, I know, this new syntax works best when there is no hardwrapping, so that we can use lines to determine the scope of certainkinds of "specialness", but I will be VERY HAPPY if we can make thesyntax robust enough that it can still be applied to rare instances ofhard-wrapped content without much going wrong.
So, lines beginning with a + (not any whitespace, but a +!) are ORDEREDLIST ITEM lines. Clients who want to be fancy can add a little bit ofextra internal state to their rendering code and can replace the +s withincrementing numbers. It's the client's choice whether it uses 1. 2. 3.or 1) 2) 3) or i
> ii
> iii
> or whatever else. Very fancy clients can letthe user decide. Yes, this means content authors lose precise controlover how their content is rendered (while retaining precise control overthe *semantics* of their content, i.e. authors decide whether an item isordered or not). I'm not just okay with this, I'm actively happy aboutit. The web paradigm where readers are subordinate to authors withregards to layout is a cause of many different kinds of grief. Goodriddace to it!
> Hmm, I only saw 7 different types specified.
Okay, turns out I can't count in a hurry. :) I actually just wrote Nwhen I first wrote that sentence, then when I ran out of time to sketchthis thing out I went back, did a quick, incorrect count, and changedit. In the actual spec I'll double check, and the number will bewhatever it is - I didn't mean for the list I sent out to be exhaustive,although I also think we should resist the urge to add every nice littlething we can think of. It'd be great if we kept the total number to 10or less.
> I also recommend you specify that
> people may use greater-than-symbol quotes, which may be nested.
I have no problem with quotes, but I'm not thrilled by the nestingprospect.
> that authors MUST NOT unnecessarily hard-wrap their quotes, suggesting that
> advanced clients MAY add a visual greater-than symbol to the beginning of each
> wrapped line.
>
> Example:
>
>
> hello this is wider than the viewport
>
> Displayed by advanced clients as:
>
>
> hello this is
>
> wider that the
>
> viewport
This is exactly how I'd expect advanced clients to handle this, and Ithink this whole idea is implicit in the design of this syntax: thestart of a line indicates what kind of line it is, and the scope of thattype is precisely that line. A hard-wrapped quote with a
> at the startof each line is, in this syntax, actually several distinct consecutivequotes.
> What about Gemini proxies of comment thread sites, such as hacker news (*waves
> to Michael Lazar's awesome HN Gopher proxy*). I think we should take those
> into consideration.
Hmm. I would want to think a bit before I lay down a hard statement onthis because I don't want to impose too much of my own ideology onGemini, as it's supposed to be a general-purpose tool....but I am notexcited by verbatim dragging of mainstream web 2.0 cultural conceptslike comment threads into Gemini. The circle of Gemini early-adoptersoverlaps considerably with the "Small Internet" / "Slow Internet"movement, which I guess has coloured how I think about the protocol.Thus the idea of adding something into the spec specifically to supportvisualising deep comment threads in the web-conventional way kind ofgives me the heebie-jeebies.
Cheers,Solderpunk