~aiwein
_ _
__ _(_)_ _____(_)_ __
/ _` | \ \ /\ / / _ \ | '_ \
| (_| | |\ V V / __/ | | | |
\__,_|_| \_/\_/ \___|_|_| |_| last updated on 2022-08-15
== About ==
[TBD]
== Miscellaneous ==
HTML Gemlog <sdf.org/aiwein/>
HTML HTTP website <aiwein.sdf.org>
DIR 2019-06-27 projects/ -- Assorted hacks
DIR 2019-08-09 files/ -- Interesting files
DIR 2019-07-10 notes/ -- Assorted notes
TEXT 2022-08-01 tw.txt -- TwTXT feed
== Phlog ==
DIR 2022-08-15 Dillo's quirks & DPIs for gopher & gemini
Dillo's website has been parked since ~May of this year, its
development had slowed down considerably and it is probably as
dead a browser can be, so I'm not sure how many people are
actually going to write - or bother using - new plugins (DPI)
for it, but, just in case:
- it already looks into =~/.dillo/dpi= by default, so there is
no need to add another =dpi_dir= entry into =~/.dillo/dpidrc=
(in fact, I'm pretty sure it just reads the first one)
- it doesn't seem to cope too well with multiple .dpi files in
any given DPI subdirectory.
I learned of this when, having installed a second DPI to handle
=gemini:= links, I decided to not bother with deleting the
executable, and to just rename it by giving it an =old.= prefix.
It worked, until I tried using it two days later and it suddenly
didn't: having closed the dillo instance, dpid - and the
association between the protocol and the executable - presumably
went with it, with the error manifesting itself as a series of
Dpi_get_server_port: can't read server port from dpid.
lines in the dillo output.
Fixing it was trivial; figuring out /how/ to fix it, slightly
less so.
Incidentally, the DPIs I have been using are Charles E. Lehner's
=dillo-gopher= and =dillo-gemini=, licensed with GPLv3 and FSF
All-Permissive License respectively, and available as Git repos
through Secure Scuttlebutt:
HTML cel/dillo-gopher
HTML cel/dillo-gemini
- - -
On a slightly different note, I took a stab at revising the
troff macros I use to generate this phlog (and that I'd also
like to use to generate a blog/gemlog): I spent five minutes
adding inline formatting, and wasted the whole afternoon trying
to figure out how to stop =grohtml= from wrapping its output at
~64 columns. It's /mostly/ a non-issue, but as I am likely to
use preformatted text, I'd like to avoid messing *that*up.
I ended up settling on mangling the HTML in post-processing -
awk to the rescue! - but that's just an ugly hack, one I figure
I'll have to dig into the grohtml code to fix.
Or I might just stop forcing troff to do the text formatting.
Decisions, decisions.
DIR Older entries