-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
What do you think of the use of ANSI formatting (for [31mc[32mo[33ml[34mo[35mu[36mr[0m and [1memphasis[0m) in gemtext?
This is one of those cases where the current spec is silent. A tradition of using these escape sequences in certain circumstances has built up, popularised (and pioneered?) by Astrobotany, and later Wordo. It worked with some terminal clients just because they didn't think to strip the escape codes, and some graphical clients (Lagrange at least) then blessed the hack by specifically interpreting the codes. The informal convention that seems to have developed is that it's OK to use them, but you shouldn't expect clients to interpret them, and probably you should only present them to users who have specifically asked for them. On the other hand, one could say that it's a horrible hack which has no place in our lovely clean gemtext format.
So what do you think? Poll below. Personally, I'm torn between 3 and 4. Context for this question: I'm considering adding optional ANSI support to SGGS, but I'm not sure if I ought to promote this hack.
1. ANSI formatting is neat and should be considered part of gemtext. Clients should support it.
███▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 13%
2. ANSI formatting is awkward but we don't need to ban it... servers can send it and clients may display it, but they shouldn't be expected to.
████████████▁▁▁▁▁▁▁▁▁▁▁▁ 50%
3. Like option 2, but it should only be tolerated within preformatted text; elsewhere clients SHOULD strip all ANSI escape codes.
█████▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 21%
4. ANSI formatting is an abomination, and should be explicitly disallowed in the spec. Real gemtext does not contain any such escape codes, and clients should of course strip any they find.
███▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 13%
5. Other, see comment.
█▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 3%
38 votes were cast.
2023-06-04 · 1 year ago · 👍 Addison · 🤔 1
I think allowing ANSI codes in preformatted blocks and banning them elsewhere is a nice compromise. After all, ANSI codes are one way of preformatting the text.
No client should be expected to support the codes because 1) that's a lot of work, and 2) not all codes are even applicable everywhere, so stripping them should be the recommended behavior if the client doesn't handle them.
@mbays (This post could be moved to s/Gemini?)
@skyjake Oops yes, I meant to put it in /s/gemini... thanks for letting posts be moved to subspaces after posting!
@skyjake Yes, I think there's an argument for accepting that the tradition of ANSI text art is established enough that it can be part of gemtext. Quick thoughts on how this might be specced: outside preformatted, escape codes are illegal so there's no need to spec what clients should do with them (e.g. they could just strip the escape char, leading to something unreadable, and that's fine). Within preformatted, only SGR codes (\\e[...m) are permitted. Clients should expect them, but can do what they want with them, including just stripping them. Possibly we'd want to indicate which ones clients might consider supporting -- maybe just 0 (reset), the display variants 1,2,3,4,7,9 and their negations, and the colour codes 30-49 in their various forms. Or maybe something stricter (0,1,3,4,30-37,40-47?) to have something minimal which clients who support it at all can be expected to support.
> popularised (and pioneered?) by Astrobotany, and later Wordo.
Konpeito did it first (to add color to the cassette logo), and then later made them optional, and then later removed them completely IIRC.
What other capsules are even using colors? I think I've seen them maybe a half-dozen times in total. It's such a pain to style text this way that it only really makes sense for CGI scripts and other dynamically generated content. Or, very artsy capsules where the author is explicitly pushing the limits of the gemtext format.
I always liked the aspect of Gemtext that styling is left entirely to the client, putting the burden on authors to come up with something worth reading. Well, moreso than on the web, anyway. When ansi codes started appearing or seemed like a conscious effort to find a loophole around that constraint. I'm not any more in favor of it than I am people misusing unoccupied characters for stylistic effect.
That said, compromise is a part of life. And I can see two major uses for escape codes, ansi art, which already is a big part of Gemini, and preformatted code blocks since so many of us here are big Unix nerds. That's something I'd be tempted to add to my capsule.
@jeang3nie That's a good point about syntax highlighting code blocks -- I think that's better than abusing the alttext line to indicate the language so the client can do highlighting, as has been suggested.
Rosy Crow converts everything to HTML/CSS under the hood, so this shouldn't be too difficult to implement. Now I have another excuse to procrastinate on adding Titan support. 😁
@mbays it's one of the few things that I miss from blogging on the big web using Markdown. What I find interesting is that the alt text a we know it in Gemtext is used for precisely that in CommonMark - relaying to the renderer that this block should be rendered as code. I agree that this shouldn't be done in Gemtext though, because that bit of info should be reserved for those using screen readers with ansi art.
I'm not even sure it's something that I'll ever get around to implementing, but it has been in the back of my brain for a long time. I have some idea how I could automate adding all of those escapes when building the capsule already, just too many projects going at once.
The colours you added to the word “colour” made it hard to read, therefore I would like for my browser to strip them.
I’m not sure about syntax highlighting case too, because the author can’t control the background that a browser/terminal is providing. It is hard to find colors that work on both light and dark backgrounds and most authors falsely assume everyone is using their mode of choice. I notice this quite often, because I use a light terminal background.
I want to be able to use it in some of my notes, but I haven't been able to get it to display in amfora.
I don't like it. I don't think it should be banned because then we would have to explicitely ban countless formats being thrown in preformatted blocks but I don't think clients should be forced to process them. It breaks accesibility and my choice of having any background color I like.
@emilis @lufte re background colour: a terminal client could be more clever about how it renders ANSI-coloured text than just passing the escape codes through to the terminal, it could munge them to account for a configured background colour. @lufte: Banning it (prohibiting it in the spec) would be straightforward, and I don't think there's any slippery slope there. It's certainly the cleanest option. I'm surprised there isn't more support for it in the poll...
@mbays I think I understood option 4 as "Ban capsule owners from writing special codes in their document" instead of "force clients to not do any special handling with the text in pre blocks", which makes more sense. In that case I'm all for option 4.
@mbays I agree it's SGR that makes most sense here, but I think because actually adding support for these codes is highly implementation dependent (for instance, can be much easier for a TUI app), there should be no common baseline of expected support. The only common denominator should be that clients strip out the sequences, if they can't parse and apply them properly.
But IMO even that is too complicated a requirement for implementing a Gemtext parser. My speccing suggestion is to simply not pass control characters like <ESC> through to disable these sequences, even when the client just dumps the source to a terminal.
Allowing SGR in preformatted blocks makes some sense because there one might reasonably expect a client to take the part of the source between the ``` markers and show it as-is (inside a terminal emulator).
The way GUI clients would render the codes depends greatly on the underlying display method. A web view has powerful CSS styling features, so once you parse the sequence, you can display it easily. Other GUI controls might be more limited in what they can render. In any case, the client would have to be smart about the presentation, by choosing colors and fonts that remain legible.
It's all a surprising amount of complexity when implemented properly, however I think it's still compatible with the idea that the client is empowered to present the Gemtext source as it sees fit.
I believed this topic was already settled down, and we eventually agreed it was a bad idea especially because text-readers read the full text...
@skyjake Right yes, it's best to have the baseline behaviour lead to something unreadable when escape sequences are used, discouraging their use except in dynamic systems where the user has specifically opted in to receiving them.
That doesn't mean we can just leave optional use of escape sequences unspecced and let conventions around them build up, because that's a definite loophole for extending the capabilities of gemini. So I think we have to tightly constrain what's permitted. Hopefully Solderpunk will pronounce on it one day.
There is a 𝘥𝘦 𝘧𝘢𝘤𝘵𝘰 standard ANSI sequence that provides a little bit more utility than SGR: VTE ([and a bunch of other terminals]) support inline hyperlinks with OSC 8. There’s a [rough spec] available as a Github Gist. I’m not sure how widely used it is, but I have noticed GCC using it to link to documentation about warnings (for example).
I’m not really advocating that ANSI sequences in general and OSC 8 in particular be widely adopted so we can have inline links, I just thought I would mention it because it’s kinda neat (and it tickles that “how can I exploit this to do something interesting” itch 🙂).
@totroptof Oof... thanks. That's a serious extensibility hole which I wasn't aware of at all. OK, so this is a great argument for making sure terminal gemini clients strip out most (at least all non-CSI) escape sequences, and for having the spec tightly constrain which, if any, sequences may not be stripped.
By the way, after the discussion in this thread, I tweaked how my terminal client diohsc handles this: as of the next version, escape characters in gemtext are filtered out except where they introduce CSI sequences ('[') within a preformatted block.
-- Response ended
-- Page fetched on Sun May 19 20:37:32 2024