Comment by 🦂 zzo38
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.
2024-10-06 · 2 years ago
19 Later Comments ↓
🚀 clseibold [🛂] · 2024-10-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.
🌆 skyjake [mod...] · 2024-10-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 [🛂] · 2024-10-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] · 2024-10-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] · 2024-10-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?
🦂 zzo38 · 2024-10-06 at 18:45:
@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>:
─────────────────────────────────
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚀 stack · 2024-10-06 at 19:44:
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] · 2024-10-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...
- They start with the two characters =>,
- followed by optional whitespace (spaces or tabs, as many or as few as you like),
FML
🚲 halscode · 2024-10-06 at 20:10:
@stack ... are you not using .startswith("=>") or equivalent to determine line type?
🚀 stack · 2024-10-06 at 20:39:
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] · 2024-10-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
🦂 zzo38 · 2024-10-06 at 22:46:
@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.)
🚀 stack · 2024-10-06 at 23:40:
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...] · 2024-10-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.
🚀 stack · 2024-10-07 at 04:25:
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] · 2024-10-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
🚀 stack · 2024-10-07 at 16:22:
@gentooshnik, I don't think it actually answers much if you read it carefully.
💎 pista · 2024-10-22 at 16:47:
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.
Original Post
— astrobotany.mozz.us/public/d042d6e56d684136ab0d07b128df0a50/m1
Rationale FAQ — If it doesn't exist already it should be created. There's a discussion at [https link] 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: Why no inline semantic markup? Like <strong> <emphasis> <a> etc. (Nobody actually misses things like fonts...