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

[solderpunk]

On Wed, Jan 15, 2020 at 12:03:28AM -0500, Michael Lazar wrote:
> 
> Not to mention, pages like this [1]
> display perfectly on my iphone using a
> gemini-http proxy server. Regardless of
> whether you choose to adopt the ```
> mode, you're still going to need to
> recommend a line length for authors to
> hard wrap their text/gemini files at.
> And I suggest that 40 is still worth
> considering for this.

Yes, I definitely intend to include a recommendation that text/gemini
content be hard wrapped at something less than the traditional 70 or 80
columns.  This convention seems to slowly taking hold in the
phlogosphere (driven, delightfully, as much by retro PDA enthusiasts as
smartphone users!).  In writing about this earlier, I idly raised the
prospect of clients for "real computers" displaying text hard wrapped at
~40 characters displaying multiple columns side by side - I actually
bumped into an example of this in the wild the other day (see the end of
gemini://tilde.black/users/brool/stoned.txt) and thought it looked
great!
 
> Here are some other alternatives that
> might be worth considering. I do think
> that displaying gemini links is a valid
> use-case, but adding a whole new
> preformatted text mode only for this
> narrow case feels a bit heavy-handed to
> me. Granted, I realize there are other
> benefits to the preformatted mode that
> have already been outlined.

I agree that the ability to display literal Gemini links inside a
text/gemini page probably doesn't, by itself, justify adding any kind
of markup complexity.  But there are indeed many other benefits, as you
mentioned.  I had kind of been on the fence about whether or not such
complexity was worth adding mostly on the basis of those other benefits
(which mostly relate to supporting mobile devices, which, even though I
do use them, I kind of hate and feel reluctant to cater to).  The
realisation that a verbatim text mode can also do some genuinely useful
work even on a "big screen" where text reflowing never has to be done
has, I think, tipped the scales for me enough to decide that this is
worth it.

After all, the essential complexity cost we'd be paying for these
benefits is quite low.  Remembering that it will be explicitly okay for
simple clients not to reflow text if they don't want to, the most
anybody will be obligated to do is something like the following:

in_verbatim = False
for line in all_the_lines:
    if line == "```":
        in_verbatim = not in_verbatim
    elif line.startswith("=>"):
        handle_a_link(line)
    else:
        print(line)

This won't display the ``` lines and will avoid trying to parse any
links which are supposed to be presented verbatim to the uesr (which,
for the purposes of education, might be syntactically invalid and not
something the client should try to parse anyway).  Nobody can
reasonably call the above difficult or bloated, and it's only three
lines longer than the bare minimum that is currently required:
 
for line in all_the_lines:
    if line.startswith("=>"):
        handle_a_link(line)
    else:
        print(line)

(as an aside, the times recently I've talked about "simple clients
catting content straight to stdout" was a bit careless, because of
course you need to actively extract the links as above)

If this is all it takes to make it possible for ambitious client authors
to support word reflowing on mobile clients without making it impossible
to include ASCII art, source code or poetry, that seems like a fair
trade to me.

> Option 1. Use a no-op link
> 
> Pick a URL that by convention doesn't
> lead anywhere useful, and then hijack
> the (link friendly name) portion to
> display your gemini link.
> 
> =># =>/about.txt About
> 
> "#" is a valid relative URL, right?

This is kind of a cute hack, I'll admit, but I worry that (especially to
people that aren't intimiately familiar with RFC3986!) it's obscure and
less easy to remember than the back tick syntax familiar from several
other markup languages.  Also...

> This would be displayed on
> most gemini clients as:
> 
> =>/about.txt About

...it would display as something like:

[7] =>/about.txt About

in AV-98.  And with a button styling in Castor!  In general I think it's
nice if clients have a little leeway in choosing how they want to
present links.

> The line would be highlighted as a link
> (unless clients choose to handle this
> special case), 

Which I guess would take at *least* two extra lines of code, giving this
approach only a one line advantage over the ``` approach which also
facilitates reflowing text (this hack is just to make it possible to
display link syntax insie text/gemini documents, right?).

> Option 2. Use text/plain
> 
> ...
> 
> How you feel about this option likely
> depends on which side of the fence you
> fall on regarding text/gemini usage.
> Should text/gemini be used like HTML is
> on the web, with most content being
> written as gemini files? Or should it be
> more like gopher, where directories are
> type text/gemini but many people write
> their blog posts and other leaf
> documents as text/plain.
> 
> Lately I have been leaning more towards
> the second interpretation. Take another
> example: Instead of writing a python
> code snippet inline in a text/gemini
> document, what if you instead added a
> link to your code snippet and served it
> as "text/x-python"? This feels natural
> to me given that other media content
> like images also can't be displayed
> inline.

This is a conversation well worth having!  From my point of view, Gemini
very deliberately chose to cast aside Gopher's strict distinction
between menus and content, in part because so many people in Gopherspace
seemed to be disatisfied with it.  So, it seems kind of a shame to just
disregard this and go back to the gopher way.  Of course, people are
totally free to do so if they want to!  Neither the protocol nor I will
object.

It is true that there seem to be quite a lot of cases in the wild where
people are using text/gemini menus to link to collections of text/plain
files.  Sometimes this seems to be accidental, because the files
actually contain attempted Gemini links, e.g.:

gemini://tilde.black/users/fox/journal/20190831-starting-out.txt

Other times I suspect this is to facilitate straightforward bihosting on
Gopher and Gemini.

I presonally plan to write Gemini content primarily in text/gemini, and
in fact I'll probably decide how to distribute content between my Gopher
and Gemini sites based in part on how well different kinds of content
benefit from Gemini's ability to do in-line links.  Is anybody else
planning to do this?  Are the people currently not doing this doing so
out of conscious choice or just carrying over old Gopher habits?

As for using in-line links as a way to include un-flowed text, I did
think of this option (maybe somebody else already mentioned it in the
list?).  It would work, but I feel like the user experience would be
fairly clunky, especially for the combination of articles with frequent
short code snippets (like programming tutorials) and simple
terminal-based clients where going "back" to the text/gemini document
from the text/x-python document wouldn't return the reader to the same
point in the (potentially quite long) document from which they followed
the link.

I do take your point, though, that we're already forced into that clunky
paradigm for images and other non-textual media...

Ultimately I don't think I like either of these alternatives as much as
the ``` syntax, but I'm happy to hear others' thoughts...

Cheers,
Solderpunk