πŸ’Ύ Archived View for bbs.geminispace.org β€Ί u β€Ί freezr β€Ί 1581 captured on 2023-12-28 at 18:02:52. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-14)

➑️ Next capture (2024-02-05)

🚧 View Differences

-=-=-=-=-=-=-

Comment by ❄ freezr

Re: "ANSI formatting What do you think of the use of ANSI..."

In: s/Gemini

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...

❄ freezr

Jun 05 Β· 7 months ago

Poll Results

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.

3 Later Comments ↓

πŸš€ mbays Β· 2023-06-06 at 23:01:

@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.

πŸš€ totroptof Β· 2023-06-25 at 01:17:

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 πŸ™‚).

β€” and a bunch of other terminals

β€” rough spec

πŸš€ mbays Β· 2023-06-25 at 07:50:

@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.

Original Post

πŸŒ’ s/Gemini

ANSI formatting What do you think of the use of ANSI formatting (for colour and emphasis) 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...

πŸ’¬ mbays Β· 19 comments Β· 1 like Β· Jun 04 Β· 7 months ago Β· πŸ—³οΈ