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

solderpunk solderpunk at SDF.ORG
Wed Jan 15 22:11:17 GMT 2020


On Wed, Jan 15, 2020 at 12:47:27PM -0800, Aaron Janse wrote:

> > Yes, I definitely intend to include a recommendation that text/gemini
> > content be hard wrapped
> 
> May I ask why?

Mostly because I want simple-as-possible clients to be viable, which
means simply printing non-link lines to stdout should result in
something usable.  Paragraphs of text formatted as a single line are
tremendously unpleasant to read when displayed this way!  If this were
the norm for text/gemini documents, I suspect nobody would use any
client that didn't include (tedious to write!) code to wrap these
lines at word breaks.

> In fact, I think *discouraging* hard-wrapping might actually make life easier
> for client implementers. Hard-wrapping would require clients to un-wrap the
> newlines then re-wrap to the desired width.

It wouldn't *require* that, the lines could simply be displayed at their
hard-wrapped width, which is why we're concerned with recommending a
narrow enough width that this would work on devices with narrow
displays.

Basically, consider what happens with the bare minimum amount of code in
either case:

A) If an entire paragraph is one line and a client doesn't have code to
break that big line up at word boundaries, leaving wrapping up to the
terminal results in multiple lines (potentially uncomfortably long for
reading) with randomly cut-up words at their beginnings and ends.

B) If the paragraph is hard-wrapped at ~40 characters and a client doesn't
have code to un-wrap and re-rewrap those lines, the result is lines of a
comfortabe length for reading, which fit on a smartphone and don't have any
randomly cut-up words at their beginnings and ends.

Given these two choices, surely B) is preferable?

Admittedly, this analysis is somewhat terminal-centric.  A lot of GUI
toolkits probably have text displaying widgets which will handle
breaking lines at word boundaries without the developer having to give
it a second though.

On the one hand, the vast majority of extant clients are
terminal-centric and I think the majority of the early adopters (being
gopher folk) lead terminal-centric lives, so a terminal-centric
perspective is only natural.  On the other hand, Gemini isn't supposed
to be only for a certain group of people, so I'm reluctant to lean on
this too much...

> Oh, well. I'm vocal about this because Gemini looks really exciting to me.
> As someone who plans to use it, I simply want it to be what I think is as
> easy to use as possible :-)

I appreciate you speaking up and I'm glad you're excited!

Cheers,
Solderpunk


More information about the Gemini mailing list