💾 Archived View for rawtext.club › ~sloum › geminilist › 000349.gmi captured on 2020-09-24 at 02:38:01. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

<-- back to the mailing list

Text reflow woes (or: I want bullets back!)y

Aaron Janse aaron at ajanse.me

Fri Jan 17 17:59:18 GMT 2020

- - - - - - - - - - - - - - - - - - - ```


> 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 ofspecifying the language:

Plus, if we *allow* people to specify the language, maybe some clients couldimplement syntax highlighting. Would that be too complex?

If not, what would happen if people add text to the closing three ticks?

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. Maybe state that clientsMUST NOT remove trailing space, etc, but state that clients SHOULD allowreaders to copy the text such that it can be pasted directly into a text editorthen run (this would allow the 100-line python client to just print the lines;terminals should un-soft-wrap lines longer than the viewport when copied to theclipboard).

They should be presented to the user in a client-specific "pleasing manner"
Variable width fonts may be used.

I *love* that this is part of the spec!

6. UNORDERED LIST ITEMS

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.

Can top-level bullets begin with a space? What about nested bullet points?

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, Ithink there could be some value in limiting authors for the sake of preventinga scenario where making a client is so complex that very few nice clients exist(as we see in the world of web browsers).

The lines of a text/gemini file come in 8 different types.

Hmm, I only saw 7 different types specified. I also recommend you specify thatpeople may use greater-than-symbol quotes, which may be nested. I'd recommendthat authors MUST NOT unnecessarily hard-wrap their quotes, suggesting thatadvanced clients MAY add a visual greater-than symbol to the beginning of eachwrapped line.

Example:

hello this is wider than the viewport

Displayed by advanced clients as:

hello this is
wider that the
viewport

---

I asked a ton of questions, but I still like the direction we're going. I'djust like to bring up one more thing:

What about Gemini proxies of comment thread sites, such as hacker news (*wavesto Michael Lazar's awesome HN Gopher proxy*). I think we should take thoseinto consideration.

If we wanted to introduce new syntax (which is a bit crazy, but fun), we coulduse pipes like greater-than signs. We could use the exact same code for thisthat we would use for fancy-wrapping greater-than-sign quotes.

For example, the source code would be:

| # John| this is a comment wider than the very narrow viewport|| | # Joe| | and this is a sub comment tthat is very very very long!| || | | # You| | | and this is a sub sub comment!|| | # Bob| | and this is a sub comment

The output on a narrow viewport would be:

| # John| this is a comment wider| than the very narrow| viewport|| | # Joe| | and this is a sub| | comment that is very| | very very long!| || | | # You| | | and this is a sub| | | sub comment!|| | # Bob| | and this is a sub| | comment

I know it's super crazy, but it sounds simple to implement. I was consideringmentioning it in its own thread, but I think this is the most relevant timeto bring it up.

Cheers!