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

[solderpunk]

On Sun, Jan 19, 2020 at 08:15:14PM +0100, Brian Evans wrote:

> I've mostly been sitting back through all of this list and raw mode
> talk, only occasionally popping in small points here or there. But
> I figure if this is a community decision it is good if those in the community
> voice their support or lack of support for ideas. 

It definitely is, if people who don't feel good about proposed changes
keep quiet and all I hear on the list is agreement it will just lead to
the most vocal members driving things.  I'm glad you've spoken up.

This will be a quick and kind of partial reply, sorry.  But, very
briefly, I understand the concern about lists (of all the recent
proposed changes, they are the least valuable IMHO because they only
concern presentation).  How do you feel about the heading proposals?
IMHO they are probably the most valuable of these changes because they
can be totally ignored from the perspective of presentation and yet
still do genuinely useful stuff, like automatically generated tables of
contents, which do nothing but make large and well-structured text
content easier to read, or help with automatic generation of
user-friendly menus or feeds to bodies of content.  That's good stuff,
surely?

> I really do not want to, and likely will not, add support for lists in my current
> or any future gemini client I make. I don't see the point. 

As I intend to actually write all this stuff in the spec, if I decide to
adopt it, supporting the list line types will be strictly optional, so
this is absolutely fine.  For a text-based client like Bombadillo, the
difference between supporting lists and not is an extremely small
aesthetic thing that some users probably won't even notice.

> I do appreciate all of the work and thought that has gone into trying to
> figure these things out. It just feels unnecessary for a simple protocol
> like gemini. Why get complex when just serving markdown or html or
> whatever you like will do the job and people can read it as they see fit.
> We are definitely starting to get into the territory with the proposals
> where some client authors will support some things and some wont...
> which will create a fractured view of gemini to users. So why not keep it
> simple and cohesive by just having links and move on to other things?

The fractured Geminispace thing is a real concern, but actually I think
an argument can be made in both ways here.  If text/gemini is kept
extremely simple and plain and the official policy is "Serve Markdown or
HTML if you want even basic text styling" then people may well do that.
Some clients will add support for rendering those but many won't because
it's so much more complicated (far worse than what has been proposed
here!).  Then we end up with two regions of Geminispace, the text/gemini
subspace which anybody can visit and the Markdown subspace which only
people using the fanciest clients can visit.  IMHO, this is a worse kind
of fracturing than one where we adopt the proposed new text/gemini
syntax and different clients implement different subsets of the optional
features.  After all, the only reason I've been so positive about these
recently proposed changes is that they all seem to degrade very
gracefully if a client doesn't recognise them and treats them equivalent
to text.  The degree of fracturing possible is actually very slight.

> Just my two cents at the moment.

One cent of opinion from client or server authors is valued equal to one
dollar of opinion from anybody else. :)

Cheers,
Solderpunk