Comment by 🚀 stack
I've never had an issue with the color escapes except a very long time ago with 24 bit ones
2024-10-06 · 2 years ago
30 Later Comments ↓
🚀 stack · 2024-10-06 at 00:33:
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 [🛂] · 2024-10-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
🦂 zzo38 · 2024-10-06 at 01:32:
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 [🛂] · 2024-10-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.
🚀 stack · 2024-10-06 at 02:51:
I like the fact that you can easily attach a reader or even a braille output device and it will mostly just work.
🦂 zzo38 · 2024-10-06 at 02:57:
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 [🛂] · 2024-10-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 [🛂] · 2024-10-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.
🚲 halscode · 2024-10-06 at 04:12:
@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 [🛂] · 2024-10-06 at 04:32:
@halscode Agreed!
🦂 zzo38 · 2024-10-06 at 04:33:
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 [🛂] · 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...