💾 Archived View for rawtext.club › ~sloum › geminilist › 000304.gmi captured on 2020-10-31 at 01:29:07. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

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

<-- back to the mailing list

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

solderpunk solderpunk at SDF.ORG

Sun Jan 12 18:43:41 GMT 2020

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

Okay, I have started to re-engage with this endless discussion -slowly and, I have to admit, reluctantly.  When I think about how manydetails there are to consider here, how many different options we haveto choose among, and how absolutely incredible the power-to-weightratio is of verbatim fixed-width text with a predefined width (Imean, really, you can:

Left align text,                             center text,                                                 even right align text

without the client having to even know what those things are!), it'sincredibly tempting to echo the "reflowed text be damned!" sentimentrecently expressed at mozz.us[1] and spec 40 character fixed text andjust move on.

But I know that'd be rash.  These days I have been worrying less aboutcatering to small-screened mobile devices and thinking more about theability for Gemini to be self-documenting.  Granted, the text/geminiformat is pretty darned simple by design, but nevertheless, havingreally nice and clear instructions for beginners, many of whom mayconceivably never have written either web or gopher content before intheir life, will be important to the widespread adoption of theprotocol.

Imagine how much harder it would be to learn HTML if websites couldn'tactually contain any code that you could copy and paste!  This isexactly where Gemini is today.  Yes, okay, you could put a singlespace at the start of a link line so it would be displayed as-is ratherthan treated as a link, and that would be mostly fine.  But it wouldinterfere with the ability to simply copy and paste a block of examplelinks and have it work as-is, because the spaces at the front of atleast some of the lines would get copied as well.

Gopher is better than the current Gemini spec in this regard, becauseyou can put gophermap lines in an item type 0 text file no problem andthey'll just be displayed as-is.  But copying and pasting thatgophermap is not guaranteed to go smoothly.  With terminal-basedapplications, the tabs would stand a good chance of being transformedinto consecutive spaces, which would actually break them.  Let's bebetter than that!  Let's make it possible to display, copy and paste Gemini links inside of Gemini documents, to facilitate teaching andtalking about Gemini over Gemini.  It seems quite natural that thisshould be possible.

Even if text/gemini were specced at 40 fixed-width characters with noreflow, meeting this goal would require some syntax comparable to<pre> tags in HTML, to switch off processing of Gemini links.  Ifwe're going to have that anyway, we may as well have reflowed text bethe default and this <pre> syntax can do double duty by also enablingnon-reflowed text for source code, poetry, etc.

I remain as commited as ever to the idea that any text/gemini markupshould have the property that simple clients can just dump it right tostdout verbatim and that should be very usable.  As I arguedpreviously, this rules out any kind of syntax where <pre> lines areindicated by some per-line prefix, as that prefix would breakcopy-and-pastability for simple clients dumping things to stdout.This is one more reason not to use the "leading whitespace" systemproposed by Sean[2] (whose detailed spec remains a very nice anduseful precise definition of lots of fuzzy concepts being slung aroundhere).

So, given this, I am pretty much settled on using an easilyrecognisable line to toggle this mode on or off, say:

This is the syntax used in the simplified Markdown proposal atmozz.us[3], and in ratfactor's "Text Junior" format[4], which otherson this list have argued is a good candidate for Gemini syntax.

I have experimented with supporting this syntax, and allowingreflowing of text not enclosed by ``` lines to an arbitraryuser-specified width in AV-98 (not pushed to tildegit yet, but expectit soon). It really is not too difficult to do, so I don't thinkcomplexity of implementation is a good argument against this.

Does anybody know of a programming language where lines consisting onlyof three consecutive single quotes happen to occur frequently?

To address briefly some other points raised in this thread:

Somebody suggested that the ``` syntax or similar be used to toggle onreflowed text, with fixed text being the default. I have to admitthis feels really backwards to me. There are many obvious and commonuse cases for wanting to embed small fragments of fixed text inside adocument that one would otherwise want flowed. I can't think of anycase where I'd want the reverse, but of course if people can I'm happyto hear them.

I am not crazy about the idea of having text/gemini "source code"consist of extremely long lines of text which are then brutallywrapped to a given width by a user's terminal. Some editors might besmart enough to present that long line wrapped at word boundaries tothe author, but many won't be and this will result in a very uglyediting environment. And I'm not aware of any terminal emulator whichwraps long lines at word boundaries, so this will result in an uglyreading experience for *all* sized screens.

I also really don't like the idea of supporting colour in Geminidocuments. I see no way to do this with a syntax which would degradegracefully when simply dumped to stdout. This would also open thepossibility of obnoxious pages with gratuitous use of colour. No,thanks!

Cheers,Solderpunk

[1] gemini://mozz.us/journal/2019-12-05.txt[2] gemini://gemini.conman.org/gRFC/0004[3] gemini://mozz.us/markdown/[4] gopher://sdf.org:70/0/users/ratfactor/phlog/2019-04-21-text-junior