💾 Archived View for thrig.me › tech › gemini › clients.gmi captured on 2023-04-19 at 23:31:35. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
"We'll need a search running ..."
Problematic in my usual no-color terminals as the active button in the prompts cannot be distinguished from the inactive buttons. Also the terminal cursor is hidden; this makes it more difficult to identify the active terminal of my usual four. The code does not look easy to search or modify without learning the text library (tcell?) being used: a few searches turned up nothing related to the cursor or pointer. Perhaps it is hidden by default, or I don't know.
amfora uses perhaps too many prompts or pop-up that mandate extra keystrokes to clear. Some of these probably could be replaced with brief notes in the lower status line, or maybe hidden off on a downloads tab like in w3m?
Moving back in history takes you to the top of the page; this can make it difficult to resume reading from where some link was followed. Perhaps new tabs would avoid that problem?
A configuration option to always download, never ask, never prompt might be nice, which of course would be problematic with streaming media. Maybe one could toggle somehow between "download everything" and other behavior patterns?
There is no option to search within a page. The help menu departs from the documented interface; the d key does not page down, nor does u page up. The program is perhaps too easy to quit via q or control+c.
On the plus side amfora wraps text well, and has a option to show what the link is, and does not clutter the interface with "Hi! I'm amfora!!" or such noise like too much other softwares does.
Not sure how to scroll a page or follow links. Does not reset the terminal state on exit.
Always wastes space displaying a ((( Bombadillo ))) and does not appear to have an option to show what links point to. Bombadillo is also not good at wrapping text, perhaps due to gopher text always being wrapped back in the day while for gemini text long lines appear to be recommended for paragraphs such as this one.
gemini://gemini.circumlunar.space/docs/gemtext.gmi
Bombadillo is better about "just download everything you cannot display to a downloads directory", once I figured out showimages=false. Bombadillo may leave the terminal in a bad state if control+c is used to exit the program (you may not notice this if ZSH resets the terminal state afterwards, but ksh on OpenBSD does not perform any such cleanup).
Bombadillo not have prompts (always a good sign), does have an in-page search, and appears to work correctly in my no-color terminals. We probably should make an aside here to discuss
The typical blue on black is utterly unreadable, and so are many if not most color combinations. In the web article "Writing Small CLI Programs in Common Lisp" by Steve Losh, code to colorize text is presented, with a feature to exclude those combinations that are too dark or too light. When playing around with the code, the list of "these are readable and distinct colors" kept on getting shorter and shorter, to the point of "why bother? this list is too short".
Even if readable, colors are distracting: HI I AM YELLOW is all I see, and it takes too much mental effort to try to screen out ALL THE SHOUTY COLORS HEY LOOK AT ME and read, say, the actual code. Imagine if some well-meaning individual with a box of crayons did Shakespeare with every verb green, adjectives blue, etc. Yeah, how about no.
It is rare that I can find a terminal program that does not do a terrible job with colors: Dungeon Crawl Stone Soup, and, uh, let me get back to you. Silly games aside, no colors. (Besides black, white, and at present the cursor is red, which is easy to find, and the active window border is purple, also easy to find.)
Customizing the colors would take too long, assuming it were possible for each and every terminal program, and anyways most colors are unreadable and add no benefit; therefore, it is simpler to turn them off.
$ grep xterm.color ~/.Xdefaults
xterm*colorMode:false
$ echo $TERM
screen
$ infocmp | egrep 'color|pairs'
$
So now you know probably too much about why I do not use color terminals for anything productive.
https://stevelosh.com/blog/2021/03/small-common-lisp-cli-programs/
char **bookmarks = malloc(sizeof(char*));
size_t n = 0;
...
A codebase that only sometimes checks the return value of malloc does not inspire confidence. I guess you can maybe get away with that on Linux but not OpenBSD. Also Gemcurses would need to be modified for proper hjkl vi-key support. Nothing that cannot be fixed...
(Yes, I am still bitter about the Linux OOM killer nuking sshd at 4 AM in the morning and then I got woken up by a pager and golly gee the server was inaccessible from home. "Ooops! Tee-hee we'll whitelist sshd" and wash, rinse, repeat.)
$ make
CC src/certs.o
src/certs.c:2:10: fatal error: 'bearssl.h' file not found
#include <bearssl.h>
^~~~~~~~~~~
1 error generated.
*** Error 1 in .../cgmnlm/build (Makefile:42 'src/certs.o': @grep src/certs.c .build/cppcache >/dev/null || ...)
$ pkglocate include/bearssl.h
$
The docs indicate a lack of vi-keys, and "c" for color is generally a bad sign, if the bear of a compile were to be figured out on OpenBSD.
"h" to go back a page can be slow (is it not caching results locally?). An extra keypress is necessary to follow links 1..9 compared to amfora. Clean terminal exit on quit, unlike several other clients here.
Various source code changes have been made, in particular to enable pledge and unveil:
But gembro is throwing panics on some negative count something, even without the patch, so...