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

[Aaron Janse]

> 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?

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 clients
MUST NOT remove trailing space, etc, but state that clients SHOULD allow
readers to copy the text such that it can be pasted directly into a text editor
then 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 the
clipboard).

> 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, 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).

> 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 that
people may use greater-than-symbol quotes, which may be nested. I'd recommend
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

---

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

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.

If we wanted to introduce new syntax (which is a bit crazy, but fun), we could
use pipes like greater-than signs. We could use the exact same code for this
that 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 considering
mentioning it in its own thread, but I think this is the most relevant time
to bring it up.

Cheers!