The inability to show UTF-8 in Gopherspace makes me want to cry. Perhaps a simple heuristic will suffice for most uses? Anyway, I managed to rewrite my #gopher #wiki server once more and now it knows how to properly daemonize and drop privileges and all that, so now it runs on port 70 instead of 7070.
And with that I think I’m going to take a break from gopher tooting and gopher server development. Time to do other things.
Also, this toot will be interesting to see if this kind of technological #w̧̡̜͓̮͕͖͇̙̽̈́̊̈͑̾̓̔͠i̴̡̛̺͔̮̙̟̳̖̿̾̓̒͜ţ̵̡̗͓̝̱̰̉͑͆͐̽̌̚c̨̝̯̹̠̲͙̱͔̠̄͆͑̄̃͒h̡̥͚̪̭̭̥̱͖́̆͌̕̚e̡̡̬̞̩̞̞̐͂̉̑̚͟ͅͅř̷̖̪͎̙̠͖̮̦̾̈́̄̿̇͘͘ͅy̳̪̘̩̟͛͌̄̒̂͡ͅ applies to hashtags. Or if it gets applied to the normal #witchery tag.
(No elephants were harmed in the making of this toot).
Hum, using the #emacs #gopher client seems to work for UTF-8 gopher sites like my gopher wiki. But not for lynx. Hrm.
@ckeen Actually my gopher server double encoded the UTF-8 upon printing. Today I just removed some encoding and decoding statements on the server side and suddenly gopher.el started to work correctly, no change required. But for Lynx, I'm not sure. Perhaps Lynx expects URL-encoded selectors? Right now I have no time to investigate, sadly.
Not sure if this helps, but the Lynx documentation on Gopher URL handlong says:
"Any reserved characters in the selector should be hex escaped (%hh), including slashes, although hex escaping of slashes is not required by Lynx in gopher URLs." (from http://lynx.invisible-island.net/lynx2.8.8/lynx_help/lynx_url_support.html)