Re: OT: rude behaviour
glad you asked!
phetch (CLI)
https://github.com/xvxx/phetch
this client will render it as I intended without fail.
VF-1 (CLI)
https://sr.ht/~solderpunk/VF-1/
this client will render it as I intended without fail.
cgo (CLI)
https://github.com/kieselsteini/cgo
will render it almost perfectly, one minor glitch.
Lagrange (GUI)
https://gmi.skyjake.fi/lagrange/
ostensibly a Gemini protocol browser but it handles Gopher sites pretty well, including mine mostly successfully.
there's probably more out there but why am I doing the legwork for you? you are the Gopher users, this is the Gopher list, I only subscribed a couple days ago. if you didn't know any of this what were you using Gopher for aside from kicking the tires to confirm that yes indeed your server is still up even if no one remembers why.
regards
█▄▀▄▀ cat K.
█▀▄▀▄ B 4 U D W 3 R K 5 _
▄▄▀▀▀ +1 (929) 601-BAUD
> On 15 Nov 2025, at 10:11 AM, Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great cat K. once stated:
>>
>> I wouldn't expect a DEC vt510 from 1993 to render my Gopher hole as I
>> intended in 2025 any more than I would expect Mosaic to properly render
>> YouTube.
>
> Do you expect any modern Gopher client to properly render your page? The
> gopher browser I use (which I wrote) strips out ANSI escape codes as I
> consider them a security threat [1]. I still see the art, but it's not as
> colorful. It was also easier to strip them out than to attempt to support
> ANSI escape codes [2].
>
> -spc
>
> [1] There are defined escape sequences to issue application and
> operating system level commands. There are also escape sequences
> (in the "privately defined" areas) that can load the cut buffers
> that could be problematic. Not all terminals or terminal emulators
> support such sequences, but some. And at the very least, malicious
> pages could set the terminal into a useless state (say, setting the
> foreground and background colors the same).
>
> [2] Technically, ECMA-48 (a European standard) as ANSI withdrew their
> version in favor of ECMA-48.
>
Reply to: