💾 Archived View for bbs.geminispace.org › s › Gemini › 20416 captured on 2024-12-17 at 15:03:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
If it doesn't exist already it should be created. There's a discussion at
https://www.linux.org.ru/news/internet/17747973
and people ask lots of questions about Gemtext. Most of them are obvious from the Gemini core design principles but some are not. Here are a few:
astrobotany.mozz.us/public/d042d6e56d684136ab0d07b128df0a50/m1
Oct 05 · 2 months ago
🕹️ skyjake [mod...] · Oct 05 at 12:14:
The inline markup and content length questions are covered in:
— Project Gemini FAQ (section 4)
When it comes to tables, they are complicated to parse and lay out, especially when one starts to consider details like merged cells, column/row sizing, content alignment, etc. Complexity-wise, it is not at the same level as the rest of Gemtext, by far. It would be a massive hurdle for client implementers if they were expected to have support for table rendering.
The use of ANSI escape sequences is indeed somewhat accidental, as many clients are terminal-based and therefore can use these "for free". They are not part of Gemtext, and should generally be avoided by default. Astrobotany has a setting for enabling them per user.
🚀 Gentooshnik [OP] · Oct 05 at 18:39:
I'm using Gemini (with Lagrange) for several days now and honestly the only thing I'm missing in Gemtext is <hr> :D
IMO headings just don't structure the page well enough. Can I make Lagrange display a line before every # heading except the first one?
For what it's worth, I find Gemtext a little _too_ simple, so I'm thinking of making a Gemini-specific flavor of Markdown that tries to keep it as simple as possible while bringing "back" useful things like inline links, bold, italics, underlines, horizontal rules (dividers/<hr>), maybe linkable footnotes, and stuff along that line, while keeping things like Gemtext links, preformatted blocks with alt text (even though I think it'll also allow syntax highlighting, if the client implements it), and all newlines being line breaks. I haven't decided what to do with ANSI escape sequences yet.
I'll probably be the first to implement it, maybe the only.
🖥️ mrrobinhood5 · Oct 05 at 20:34:
IMO it's left simple for the client to interpret as desired, not specified by the spec.
For me, the answer to the above is: you don't really need it. btw, ANSI color escape codes have been a standard for terminals for more than 50 years.
(@stack)
Sort of. There are at least 3 ways of doing colour with ANSI codes (4bit, 8bit and 24bit) and different terminals support different methods. Very few support all 3, so it's not necessarily easy to get colour...
🚀 Gentooshnik [OP] · Oct 05 at 23:58:
Also ANSI color codes is a binary markup in an otherwise text format. WHY?
Yes! It looks jarring in a format that is otherwise plain text. Even Markdown (and Gemtext for that matter) is designed to be readable as plaintext. ANSI escapes are quite jarring and unreadable.
I've never had an issue with the color escapes except a very long time ago with 24 bit ones
I think ANSI Escape codes were never meant to be used, but some people found a way to use them tastefully and I am happy with that. Games, ascii art, etc. Perhaps they should only be allowed in the ``` preformatted mode
🚀 clseibold · Oct 06 at 01:22:
@halscode I did a similar thing with my Scroll Protocol. I haven't added everything you listed, but italics/emphasis and bold/strong were a big addition, because I don't really buy the excuse that people don't need emphasis and strong when they have been standards in typography and writing for over 4 times the length of time ANSI escape sequences have been standard, and that's just for bold, which was introduced in the *19th Century* , and italics in the 16th Century.
During Gemini's mailinglist era, around 2020, I remember trying to argue a little bit for adding italics and bold to gemtext, but most of the original Gopher community were against it because they thought parsing them would be too hard/complex (which I still cannot understand, takes less than a day to write a parser to support them).
Anyways, I quickly just let go of the idea because back in 2020 I was more concerned with embracing Gemini and not fracturing the community further at a volatile time of influx of new users.
Now that Gemini is well established, I felt it was time for me to make my own protocol based on my criticisms of Gemini. Most of these alternative protocols that come out of the Gopher and Gemini communities tend to either use gemtext almost exactly (spartan, titan), or make a format that's significantly simpler (nex). I chose to make a format with a little bit more features (called scrolltext) instead.
Honestly, though, I still mourn the rejection of italics and bold. Gemini could have been great... /s :P
My own Scorpion protocol (or, more accurately, the associated file format) also has emphasis, strong, and fixpitch within a paragraph. I used a binary file format in order to avoid some of the issues with using text file-based formats with such thing. I also added the possibility for an optional file size in the header, and other stuff.
(Like Scrolltext, I had also considered criticisms of Gemini, when making the Scorpion.)
(I should also make a more elaborate comparison table, with more rows and columns than those in the Spartan and Scroll, but including the stuff from those tables too, perhaps. I had started to do it (using PostScript object notation); others may contribute if desired.)
🚀 clseibold · Oct 06 at 01:50:
@zzo38 The comparison table would be very useful!
@Gentooshnik I kinda agree about horizontal rules, except I think they are more useful in dividing between two paragraphs, very much like the "* * *" lines in books, rather than dividing documents or section headers. And they would be so simple to create a consistent and non-ambiguous syntax for in gemtext.
Another feature that I really wish we had is *list nesting.* You can "nest" section headings at different levels, but list items, *nope!* I was told by Sean recently that Solderpunk set this as a hard rule for him.
I can definitely understand why tables are missing in gemtext, though, but these typographical standards that have been common since the printing press was invented, and even before that for some of them, is just inconsistent with a library/text-oriented protocol/format, imo.
I find that with text only you can do a lot already. All caps and normal caps titles, proper spacing, proper use of n-dash, and typography in general. + amd - for list creation. I personally think you have to be more creative than using any markup.
I like the fact that you can easily attach a reader or even a braille output device and it will mostly just work.
I have made some parts of the comparison table data, so far. You are free to make suggestions for changes (or questions, complaints, etc).
— Comparison table data (this file is a plain text file)
🚀 clseibold · Oct 06 at 03:22:
@daruma That only works if a human is reading the text with their eyes. Plain text completely fails when computers have to parse the text for semantic meaning. Once you introduce standards like using "-" for list creation, you are implicitly making a markup language - because that's what typography already is to some extent.
As for gemtext, it's so restrictive that you can do more in plain text than you can do in gemtext (a great example of this is list nesting). However, once you create standard ways of representing meaning in plain text, then it's not actually just plain text anymore, it's a subset of plain text that is a markup language.
Restricting plain text can actually do two things: it can prevent one from representing meaning in a standardized way, *and* it can create a standard by providing *one way* of representing some meaning. The trick is in finding this balance.
Part of what makes gemtext so restrictive is that you can't do things like have whitespace at the beginning of a line, which prevents visual list nesting. The tradeoff, however, is that this allows clients to be able to justify text properly.
🚀 clseibold · Oct 06 at 03:56:
@stack According to what I've looked up, some screen readers can already read markdown (and HTML), so those would mostly just work for gemtext. This also means they are already capable of reading something much more complicated than gemtext.
But screen readers that can't, then it just isn't the case that they mostly just work, at least not without a lot of cruft - link lines, headings, list items, etc. would all have their punctuation called out, to my understanding, depending on one's punctuation setting. And if they omit calling out certain punctuation, then if it doesn't understand the document format, it cannot know what punctuation is important to call out and what isn't.
I believe screen readers that can understand a document format are more useful to the blind than screen readers that can't. They have an *incentive* to be able to read document formats rather than plain text for this reason.
This means there is *also* an incentive for document formats to include important semantic detail in their document formats so that screen readers can actually utilize this information.
Anyways, that's just my thoughts on this subject, lol.
@clseibold Bold and italics are more important to me than colors, which are a "nice to have." Also inline code, mostly to indicate when I'm talking about a literal character or to distinguish similar characters like l and I.
🚀 clseibold · Oct 06 at 04:32:
@halscode Agreed!
The only restriction of Gemini compared with plain text is that ``` cannot be at the beginning of any line of preformatted text.
I agree that screen readers (and other programs) understanding the document format is more helpful than those that don't. In Gemini, the heading levels is something that is useful for many programs to understand, e.g. a table of contents menu; you can also specify the language of the document, which is also helpful for computer speech. Scorpion file format has "data/text sub-blocks", to indicate how to pronounce, and if a sentence has one foreign word, and units of measurement.
I also agree with @halscode that bold/italics are more important than colours (especially if you want to print it out and you do not have a colour printer), although I think it is more useful to specify "strong" and "emphasis", so it is what I did in mine. (HTML does both ways.) Inline code also can sometimes be helpful, so I made that too. However, which characters look similar will depend on what font the user has selected and not the document itself.
🚀 clseibold · Oct 06 at 04:47:
@zzo38 I don't think that's the only restriction of Gemini compared to plain text. Gemini has restrictions *of interpretation* . For example, a line starting with "* " MUST be interpreted as a list item. This not only restricts clients, it restricts authors as well. They can no longer create lines that start with "*" unless they want it to appear as a list item. They also cannot do AsciiDoc's "**" for list nesting unless they are fine with clients interpreting it as a regular list item with an asterisk at the beginning of its text. These are all restrictions that are not available in plain text.
However, Gemini *also* has restrictions of ambiguity, and plain text has this same thing. These restrictions mean that authors cannot write text certain ways because clients might interpret them differently because there is no standard. Ambiguity restricts authors by giving too much freedom to clients, effectively allowing clients to contradict each other. HTML had a very big problem with this before HTML5, lol.
An example is that some Gemini clients will remove whitespace at the beginning of paragraph lines, and some won't. This means an author cannot indent paragraphs visually because they cannot rely on all clients behaving the same way. It's a restriction of ambiguity/non-specificity.
So, when you don't have a restriction in interpretation, then you might have a restriction in ambiguity, and vice versa. This is why I agree that it is more beneficial to have restrictions in interpretation where you allow for more variants of interpretation: list items plus list nesting as distinct parts of the spec.
I think that most of people ignore the fact that Markdown already exist and Gemini uses MIME types. Inventing new a protocol just to create different markup language is not necessary.
I think Lagrange can handle Markdown but it translates it to Gemtext. And even when yours Gemini client doesn’t handle Markdown you just need to have a Markdown viewer installed on a computer.
You can even serve PDFs if full rich text with all the niceties is required, and, I think, almost 100% people here will be able to read it on their computer.
🕹️ skyjake [mod...] · Oct 06 at 09:44:
@Gentooshnik:
Can I make Lagrange display a line before every # heading except the first one?
No, such customization is currently not supported. I have been thinking of making the page layout more flexible, but it's a bigger job and I haven't had the chance to tackle it yet.
🚀 clseibold · Oct 06 at 10:43:
@Aelspire
I think that most of people ignore the fact that Markdown already exist and Gemini uses MIME types. Inventing new a protocol just to create different markup language is not necessary.
If by people you mean me or zzo38, then this is completely incorrect. I may talk about scrolltext here, but my protocol wasn't created just for a different markup language, as is very clear in scroll's documentation. The same goes for scorpion, which is *significantly* different from Gemini, not just in the document format, but specifically in the protocol itself, as is clear in *its* documentation.
Nobody here is inventing a new protocol just to create a different markup language. I find it very rude and reductionistic to assume that's what's happening.
🚀 Gentooshnik [OP] · Oct 06 at 11:36:
@zzo38 There's a guy on linux.org.ru who was telling everyone to ditch Gemtext and just use Postscript. Do you know him? :D
🚀 Gentooshnik [OP] · Oct 06 at 11:38:
Sorry, sent by accident.
I mean my browser can't render PS and it's not really human-friendly either. Too low signal-to-noise ratio for a text markup language. Why use it unless you're going to send the document to paper?
@clseibold I’m sorry for sounding rude. It wasn’t my intention. But it my fault: I spoke after only glimpse on markup spec. But hear me:
In my country there is saying: “Perfect is enemy of good”. The main thing that Gemini has is the mindshare. I would change my main smol-internet protocol if other one became more popular than Gemini. But in reality most of things works like: first came, fist served. Gemini have advantage of being the first one appearing in the window where many people start to felling the gopher is not enough.
From my perspective there are already a lot smol-internet protocols: spartan, scorpion, nightfall, guppy and scroll. And what I feel that they are not enough different from Gemini to cause mass movement, and they are too many, I feel completely numbed for new one appearing after seeing so many of them coming and not really causing any change in smol-internet.
@Gentooshnik (20474): I don't know the people at linux.org.ru; I am not Russian and do not know how to read/write Russian.
@Gentooshnik (20475): My browser can't render PS either, but I do have other software on my computer (Ghostscript) that can do so. PostScript is a full programming language, and can be used like the other programming language. PostScript is not a markup language, although a markup language can be implemented in PostScript.
If you are refering to the comparison table file that I wrote, it is a PostScript file, although it is also a plain text file that should be viewable (and editable) in any computer. It is purely a data file; executing it will push a dictionary into the PostScript operand stack. It will not (by itself) produce any output on a PostScript printer.
These (with or without pre fence) works for <hr>:
─────────────────────────────────
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Yes I can see how I felt more 'restricted' in Gemini than in Gopher. Hence I continue to write in gopher but in Gemini I mostly interact (BBS, Farkle, Station) and read. I don't maintain a Gemini capsule for that reason. In gopher, I just put whatever, however and it's all good, which I'd rather use that 'subset' of text only than learning gemtext. I shorten my lines so that even on phone people can read my gopher entries.
Note to future simple markup protocol designers: please use a consistent tagging strategy.
Every gemtext line type tag is parsed differently: using one, two, or 3 characters, and sometimes requiring space. It's as if solderpunk tried really hard to make the parsers ugly. My theory is that he was on drugs.
🚀 Gentooshnik [OP] · Oct 06 at 20:05:
I wanted to say "line type is defined by all characters up to the first whitespace, just like commands in Tcl" but decided to actually read the spec before I post...
FML
@stack ... are you not using .startswith("=>") or equivalent to determine line type?
As a minimalist, I would prefer reading a fixed-size datum, knowing it's metadata and dispatch accordingly, prior to even reading the rest. I may have different buffering strategies, or let the handler deal with it. It is conceptually better for small applications and devices.
@Gentooshnik No, the line may also start with a # or ` or > and in case of ` must have two more ``s, and in case of # 0, 1 or 2 more #s optionally followed by space which is usually not displayed, etc... And if it doesn't work out you have to unparse and treat it as text. Then ``` is modal. If you stop to think it is completely nuts to require a different strategy for each type.
You literally could not come up with a dumber way to do this.
And please note that Gemini is my favorite protocol and the only 'social-media' community. It is OK to understand and accept but be critical of the idiotic aspects of things we love and use.
🚀 Gentooshnik [OP] · Oct 06 at 21:30:
Yes. I think making the whitespace mandatory will fix this. Read the line up until the first whitespace (space, tab, or CR) then you get #, ##, ###, >, =>, ```, and * to dispatch on. If it's neither of these then it's plain text.
IMO fixed size prefix would make it feel like machine-centric format. And even in C it's not that hard to parse the current version of Gemtext with a simple recursive-descent parser. Of course, with mandatory whitespace you wouldn't need anything more than "strcmp(...) == 0" for each option
@stack (20489): I do not think he was on drugs or that he tried really hard to make parsers ugly. You only need to read the first three bytes to figure out the line type; however, I agree that it is still messy, since sometimes one of those first three bytes might be part of the text, and that sometimes there are spaces to skip, and that sometimes a line is shorter than three bytes, etc. Also, the ``` would mean preformatted that other lines after that are not another line type except for ending the preformatted block.
@stack (20495): I agree with that (I would also prefer to read a fixed-size datum; I think that makes more sense and is simpler). (Scorpion file format uses the low nybble of the first byte of a block to indicate the block type, and the explicit length is also specified, allowing to read one block at a time more directly.) (The type of each menu item also is a single byte in Gopher, and with fields separated by tabs.)
@stack (20496): I would not be so sure that "you literally could not come up with a dumber way to do this". Gemini is still much more simpler than parsing HTML, XML, JSON, etc, isn't it?
(Also, the BNF in the Gemini documentation does not quite match the rest of the specification, but that is just a documentation error and is not a real criticism. The main text says "Any line [in pre-formatted mode] which does not begin with the three characters "```" is a text line", but the BNF does not distinguish pre-formatted mode.)
Well, it's not hard to parse, but to some of us non-neurotypicals, it is really annoying. It's like putting square wheels on a car and saying that it's not too hard to compensate for that, with our level of modern tech.
For a system with a leading token type identifier, it is pretty much as bad as it can be -- every type has different sizes, rules, and termination requirements. I am not talking about generic tagging, so I stand by my statement -- that you could not do worse without actual sabotage.
That is, an idiot tasked with this, putting in a genuine effort, would come up with something like this. Hence my drug conjecture.
🕹️ skyjake [mod...] · Oct 07 at 04:03:
@stack Neurotypical or not, calling Solderpunk an idiot on drugs is hyperbolic and uncalled for. Parsing the line types is trivial, and when you consider all the other things that Gemini programs have to deal with, it is a total nonissue.
I agree with @Gentooshnik that it is more important that the design is human-centric, because Gemtext is written by humans, mostly in a plain text editor without any assistance. Having to follow a super-strict syntax would make it less pleasant to use, and that would be a much bigger failure in the design.
Note that I did stop way short of calling solderpunk an idiot on drugs! And I do not object to responsible drug use. I merely prefer the drug theory to the alternatives.
The spec was sloppy and details (or lack of considering them) like this typically imply other issues. The choices taken were largely random and arbitrary. Luckily we needed something like this.
Why not use the first character for instance. Maybe 123 for headings, = for URLs, ` forma blockquote, > as before, space or anything else for text.
Or just use markdown, since you already need a library or two to do comms and crypto, and just disallow things you don't like. Minimalism doesn't matter, right?
🚀 Gentooshnik [OP] · Oct 07 at 08:03:
@stack
Or just use markdown, since you already need a library or two to do comms and crypto, and just disallow things you don't like.
4.4.5 answers exactly your question:
— geminiprotocol.net/docs/faq-section-4.gmi
@gentooshnik, I don't think it actually answers much if you read it carefully.
The lack of italic or oblique type is most frustrating
Italic type has been used for a long time to set off titles of works, whereas quotation marks identify the title of an article or section within a work. It also ruins the ability to set off foreign words within a body of type.
Italic can be swapped with underline, though I find it less aesthetically pleasing. But then... we don't have underline either.
I've found that missing feature a headache on many occasions since it's a part of type used to convey information as opposed to just calling attention. It makes it very annoying to reference other works.