💾 Archived View for gemi.dev › gemini-mailing-list › 000028.gmi captured on 2023-12-28 at 15:39:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Hi all,
Just joined the list to add my 2 cents to the reflowing discussion. With
all
due respect, I think that long thread didn't touch on a couple fundamental
aspects I believe worth considering.
1. Text reflow IS A MUST.
We live in a world of wildly varying screen sizes these days. The
trend
is clearly headed towards polarization: huge 22'+ desktop screens in one
corner, small less than 7' smartphone screens in the other. Nothing in
the
middle. There's no way you're going to get decent presentation of non
reflown text on both kinds of displays. No matter how many kludgy rules
you
instate on default width, max before forced wrap, etc.
2. Author's having selected lines not reflown IS A MUST.
This has nothing to do with formatted lists, tables, fancy styling or
ASCII art. Fact is that Gemini is a publishing platform and by not
allowing
this, you'd be precluding certain kinds of content from being
distributed
over it. Those include text snippets whose semantics intrinsically
depend
on formatting (spacing and horizontal alignment), such as:
- The simplest of mathematical formulas involving fractions
- Source code snippets in some computer languages. Hey pythonists, I
see
several of you hanging around here!
You literally cannot convey that kind of thing in the presence of text
reflowing.
If we can agree on 1 and 2, then we could as well man up, select a proper
line marker and be done with it.
Is the spec golden goal to end with exactly on special line marker?
Or is it ending with exactly what is needed, no more, no less?
How about (in non standarese):
Each line in a text/gemini document can, at the option of the client, be
reflown and/or be presented in any font the client deems appropriate except
for lines beginning with => or ==. These line markers mean:
=> (arrow) line is a link in the format bla bla bla...
== (equal, of all things!) line is preformatted text which MUST NOT be
transformed by reflow nor proportional font rendering.
That's it! Let's talk about text styling in some other occasion.
Finally, I firmly believe trying to accomplish this with a space is a bad
idea: That conspicuous space *IS* markup. Some magical text sequence,
sitting
at the right place, triggering special presentation of text following it.
Pitifully ashamed of itself markup, markup to the core nonetheless.
Trying to hide the need of an actual line marker behind some half-baked
one-space convention seems particularly unsuitable to me. Besides... What'd
be
the point? Having our poor author repeatedly misinterpreting which line is
each kind in his own document?
It doesn't even work all the time. Using a space opens a whole new can of
worms. For one: Have you noticed I've been opening every paragraph with 3
spaces? This is quite common, at least it is in my country.
In my view the issue arises from trying to abuse the meaning of the space
character. A space is, well, some white space. It separates things, it is
invisible, and you can only perceive it because of an absence between said
things. Overloading such an entity to mean something totally unrelated,
depending on the happenstance of being inserted at the beginning of a line
or, God forbid!, at the end, is simply calling for trouble in the long run.
If you happen to have endured my prose all the way down here, many thanks
for
your attention. You're a remarkably forgiving reader.
Best regards,
Andram
On Tue, Nov 26, 2019 at 01:13:31AM +0100, David Requena wrote: > Is the spec golden goal to end with exactly on special line marker? > Or is it ending with exactly what is needed, no more, no less? There is nothing particularly special, as far as I'm concerned, about having exactly one bit of special syntax, as opposed to two or three. But I am concerned, and consistently have been all throughout Gemini's development, about making sure we don't provide a toehold for extensibility to creep in. HTML has this problem, very clearly - there is no natural limit at all on the variety of tags which could be defined. And the consequences of this have been seen:
Hi Solderpunk,
Thanks for taking the time for exposing things in full.
I did due diligence before posting here. I read all materials at
gopher://zaibatsu.circumlunar.space:70/1/~solderpunk/gemini as well as
enkiv2's and John Olmo's pieces. Also nearly all of this list's
archived emails.
That is to say, I believe I have a good grasp on the philosophy
behind Gemini and the principles that have guided it's evolution. Let
me spell it clearly: To those principles I violently agree!
I'll be cherry-picking topics below were actual disagreement exists.
On Tue, Nov 26, 2019 at 19:06:30 +0000, solderpunk wrote:
> But I am concerned, and consistently have been all throughout
> Gemini's development, about making sure we don't provide a toehold
> for extensibility to creep in.
Sorry to say, that ship already sailed the moment => was
specified. The most you can do is to make some hard requirements in
the specification.
In all honesty, it sailed even before that, when mime types were
adopted. What's to prevent some Gemini server to serve text/html with
external js indeed? What's to prevent certain clients from rendering
such content as a web browser does?
I'm not trying to open a new discussion here. We all know this is just
an matter of balance.
> I am firmly of the belief that open-endedness and extensibility are
> nothing but poison for a project which wants to remain small and
> simple and to strongly enforce certain ideals.
Agreed, but... A standard that falls short of its intended purpose
in life is just calling for the very same kind of de-facto
standardization you so well describe for http.
> Thus, my big concern about using == as a start-of-line marker to
> indicate verbatim text (and let me be very clear that I recognise
> and appreciate the beauty of using this common notation for equality
> to mean "present exactly this"!)
== possesses a certain beauty and elegance about it, doesn't it? :-)
At any rate which actual marker is adopted is of no consequence. Let's
call it the 'verbatim marker' from here on.
> [...] is that it might soe the seed of the idea that the text/gemini
> syntax is one where features are defined by two character markers
> where the first character is =. If => is special and == is special
> then if we ever decide to add explicit representation of bullets
> everybody will have to agree it is obvious and consistent that this
> be done with =* and by this point the war is lost. =$ and =# and =?
> are all fair game. Someday somebody will propose that [...]
I get it, really. Let me try to convey why I state this does not apply
to the verbatim marker: it is an unavoidable requirement.
In fact there's two unavoidable requirements at stake here.
1 - There must exist an option for the client for reflowing text. I
won't elaborate much here. There's simply no way verbatim
formatted text will look good simultaneously on big desktop
screens and small smartphone displays. Doing that according to
an RFC backed set of precise rules is nothing but 'the right
thing' (TM).
2 - In the presence of 1, some way to specify verbatim formatted
text lines MUST exist for the Gemini author.
Number 1 will always be an option for the client, be it in the spec
or not. So better handle it in an unambiguous way to avoid a myriad
of, client chosen, different ways.
The capitalized MUST in 2 reflects the fact that it's a fundamental,
intrinsic, requirement for any text content distribution
platform. There're sure many more use cases. I mentioned Python source
and mathematical formulas.
It might be an inconvenience having C source code garbled, but it
will compile anyway, and can be automatically reformatted. That is
not the case with Python code, with its syntactically relevant use of
white space.
Take a Python snippet, reflow it, and you just lost its semantics.
It won't run. It cannot be automatically reformatted. Depending on
code complexity, even manual reformatting might be impossible. Simply
put, information has been irremediably lost at this point.
Now take a simple polynomial expression. Exact same situation
arises when the reader cannot discern which numerator goes with which
denominator.
In short, I object this is just a desirable feature of the
text/gemini format, as you state elsewhere in your reply.
Admittedly this could be subsumed in a more general markup facility
if the markup du jour was to be adopted, with all its nice to have
text styling and structuring features. Fact remains verbatim
formatted text must be available regardless.
If not specified, someone will implement this sooner than latter, in
a not controlled way. It might get generally liked, hence adopted.
Back at square one then.
Or someone will start experimenting on how to abuse with => markers
in order to somehow achieve this kind of thing. Coincidentally, the
spec is not yet finalized and this has already begun with some
result. Check
gemini://gemi.dev/gemini-mailing-list/messages/000019.gmi in this
very same list.
What's to be expected once the spec is set on stone?
> This is precisely the reason that when the question came up as to
> how we should best implement something like Gopher's item type 7 in
> a system without item types, I rejected the notion (even though it
> seems to make perfect sense) that we use =? instead of => for search
> points (I *think* this was julienxx's idea?).
That, I believe, would have been just a case of bad tool for the job
that was very appropriately handled IMHO.
> [...] and I admit that Gemini is slightly more naturally immune to
> this than HTML is - Gemini clients are by design very simple, which
> means many people will write them, which means there is less likely
> to evolve a situation where a small number of highly influential
> clients [...]
Also worth of consideration: general user population will likely be
composed of disgruntled former web users in one hand and former gopher
users on the other. I don't expect any of these groups to be
interested in such an outcome. Both had the web option available
before gemini; both opted out.
> This principle of not inviting future extension has informed a
> number of decisions about the Gemini protocol.
As stated above, I fully agree with this approach. Anyway, sometimes
you must handle the smaller evil in order to avoid the big one.
> [on the use of syntactic white space]
I don't think I need to expand on how an atrociously bad choice
white space would be. This very same email would be rendered in a
mixture of formatted and reflowed paragraphs :-)
> frustrating that is. I do certainly agree with both of your
> premises, that some solution to widely varying screen sizes and some
> way to embed unreflowd text, are very highly desirable.
I beg to disagree on the "desirable" bit, you know :-P
I personally would settle with any solution not involving stealth
white space markers. Client driven text reflow cannot be ruled out, so
verbatim formatted text must be in the spec in some form or another.
>> If you happen to have endured my prose all the way down here, many
>> thanks for your attention. You're a remarkably forgiving reader.
> Don't worry, I have been working hard for months to scare anybody
> without a very high tolerance for verbosity far away from anything
> to do with Gemini. :)
Well, I'd say both of us seem to lean a bit on the loquacious side...
Best regards,
Andram
Having read the discourse between andram and solderpunk I have some thoughts: Reflowed text brings with it other problems for client implementors 1. No one wants to read text that is flowed to the full width of a full screen reader on a large screen.. So there is a question of reasonable max widths and variance in how those get handled. 2. There is also the question of paragraphs. When text is reflowed all but one single space character in a row are generally ignored and newlines and other whitespace are traditionally completely ignored. As such, defining paragraphs becomes trickier. There is a LOT more complexity to handling reflowed text than simply saying let the text reflow. Now, wrapping text is easy (and is what I am currently doing in my client), but leaves that ugly jagged look when wrapping occurs (because wrapping leaves and respects newlines). I suppose one solution to this is to re-purpose the non-reflowed line indicator and just follow it with no content to create a blank line. This could get weird to write and read though (for readibility I am using the newly proposed `==`): ``` Here are some lines of text that could get reflowed by the client into one long line that then gets wrapped. == So the above should put in a blank line between each block and create two paragraphs. == == Done with a third block that has a double line break above it ``` I guess it isnt too cumbersome, but it does feel a little weird. It would be completely unclear with the leading space concept for creating a non-flowed line. As such I think that if the above model for flowing text gets adopted (which, I understand, it may not) I absolutely think a more visible marker for unflowed text is necessary. As an aside, did we land on what is to happen if the unflowed text is longer than the current client window? Are we wrapping or truncating? Ideally a horizontal scroll would be available but I do not know any clients that have implemented it and would prefer to not do so for mine. With either of the above two items the ability to make a small (100 line client) starts to get smaller as there is more parsing overhead than just looking for `=>` and handling those lines. I would LIKE reflowed text. I do not see it as the necessary thing that andram sees it as. I have been reading gopher content for some time and have not really missed flowed text that much. That said, I NEVER use a phone (and in fact do not have a phone capable of displaying this sort of content) to read gopher content and can see how wrapped text just gets unreadable after a certain point. I do sort of agree that the ship has sailed regarding markup. `=>` is a concept that could easily be expanded on by those building clients, with or without the blessings of those steering gemini development. Something to think about in that regard is PHP. Yes, PHP. It is an ugly mishmash mess of a language where people have just slapped on this or that and nothing seems to go with the other particularly well. It works, sure... but it is a mess. It might be worth the conversation to see if pointedly steering into the skid is something to be brought up again? Deliberately adding the things that will be most desired. Doing so could build a big enough swell of features that there would be less desire to do ad-hoc additions on a per client basis. It would have the added benefit of being carefully chosen by those thinking out all of the repercussions, rather than those wanting quick fixes to perceived problems. No matter which way this goes I do think it should be a mandatory part of the spec that a gemini document cannot make further requests (ie. images, stylesheets, scripts in http-land) without a user following a link. This was all kind of off the top of my head while in a hotel with family for a holiday, so sorry if it isn't as coherent as it seemed to me while writing it.
A relatively quick response to this, while I have a little spare time
and one clearly formed idea in my head:
If it is considered desirable that Gemini documents be able to contain
source code which can be successfully copied and pasted directly into
another file and then compiled/interpreted without error (which sure
seems like a nice thing to have, and one which would likely be
appreciated by a hypothetical "typical Gemini user")...
and given that the spec currently says (and I am about 95% sure I will
not be convinced to change this) that simple clients which don't want
to fuss with text formatting can display the non-link lines of
text/gemini content as if it were text/plain (i.e. raw text with no
wrapping, reflowing, etc) and still be considered valid, spec-abiding
Gemini clients...
then the folling seems to me an unescapable conclusion which must be
taken into account in any discussion of text/gemini markup:
We cannot convey "this line is verbatim text which should not be
reformatted at all" with a start-of-line marker like ==, because that
marker will get picked up by the copy and paste, and almost certainly
break the semantics of the code. Instead, there need to be lines which
toggle on and off a verbatim mode, which a user of a simple client that
does no formatting can simply not select before copying. Something
like:
```
// Parse request as URL
URL, err := url.Parse(string(request))
if err != nil {
conn.Write([]byte("59 Error parsing URL!r\n"))
log.Status = 59
return
}
log.RequestURL = URL.String()
```
That particular example being borrowed from ratfactor's Text Junior
format, but certainly other things would solve the problem. But there's
no getting around the conclusion that verbatim text needs to be included
unedited, so needs to be denoted by lines before/after the text iteself,
not markers at the beginning.
It's not logically necessary that the on/off lines be identical, but
it's simplest if they are.
Cheers,
Solderpunk
solderpunk wrote of their suggestion to have a beginning and end marker for raw text strings in gemini content. If I am understanding correctly, the suggestion would serve a similar purpose to the web tag `pre`: <pre> Here is some text. Whose newlines and spacing are exact/raw. </pre> I actually think we should go the opposite way. I think we should provide a start and end marker for reflowed text, treating raw text as the default. Since raw text output is what simple clients will likely build, it makes sense to treat that as a first class citizen/default. GIven that a large percentage of potential userbase will also be using gopher, they are used to text behaving in this way. Adding the extra ability to have text reflowed gives them what they know, but with added features. Seems like a win. As a result we could end up with something like the following: This is a _____line with extra spaces ________denoted here with udnerscores since this __will___be rendered____as html for this list. .FLOW And here is a line that would get all flowed together ignoring the newlines I have annoyingly entered. .ENDFLOW The flow___state___has been toggled back __off, and these spaces and newlines are now rendered as written. ________________________________________ Something like the above could work (I am not at all proposing that marker text/name it is just being used to represent an idea). Given that .FLOW and .ENDFLOW are on their own line it is easy to parse them out and not have them print. Anyway, those are my two cents at present. Subject to change. --? Sent with https://mailfence.com Secure and private email
solderpunk <solderpunk at SDF.ORG> writes:
> We cannot convey "this line is verbatim text which should not be
> reformatted at all" with a start-of-line marker like ==, because that
> marker will get picked up by the copy and paste, and almost certainly
> break the semantics of the code. Instead, there need to be lines which
> toggle on and off a verbatim mode, which a user of a simple client
> that does no formatting can simply not select before copying.
I agree with this. This is a case where considering the simplest
possible client implementation implies a more complex (in some sense)
markup specification.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20191202/23ab 1369/attachment.htm>
I somewhat agree with lel at envs.net depending on how you think of raw mode. If indeed the thought is that raw is truly 100% raw and cannot even make links, then I agree. However, the current state of every gemini client I have used is that of a hybrid raw mode in which there is no text reflow (I have not seen a client implement reflowed text, only wrapped text) and text is rendered as written, with the one single exception of lines beginning with `=>`. This is lightweight and is working now. It is coded and people are using it. It is what we have: a raw mode (potentially wrapped), with the ability to add links. So, given the above, the desire is to _also_ have reflowed content. As such I think adding in tags to start and end reflow makes sense, rather than pretend that what we have and are doing is reflowed text and that we are adding raw text mode... which just isn't the case for any extant client that I have encountered. The ability to add line breaks within reflowed text has also not been discussed and seems to me to complicate markup. Unless we are adopting the double line break thing that some markup languages use... but I have found that to be annoying to work with (it leaves unclear what happens with triple newline for example and also leaves room for weirdness in files that use \r\n line endings).
---