💾 Archived View for librehacker.com › gemlog › starlog › 20240408-0.gmi captured on 2024-05-26 at 14:44:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
I'm still doing some work on my Zeptoforth interface.
It is usable now, but I need to implement the "#include" pre-processing directive, which is often used in zeptoforth code files. Current you can send a line, a region, or a buffer to the zeptoforth process, but you can't automatically include other files.
Something that was vexing was deciding how to deal with ANSI codes, such as the ANSI escape codes the set a color when a compile error occurs. Dealing with ANSI escape codes and other ANSI commands is not a trivial project because it requires a lot of consideration of context and data buffering. The current system I using for implementing the serial connection is Emacs' built-in make-serial-process and associated functions. With that approach your output filter function gets a string containing whatever bytes you just received from upstream. So you might, e.g., get only half the bytes of some escape code. Coupling these challenges with the need to transform text appearance into Emacs faces and such, you quickly find yourself reimplementing your own terminal-emulator, which is not a small task.
An alternative approach would be to layer something on top of the term.el code. I.e., layer a special mode on top of the Emacs terminal emulator. But I don't want to dive into that now.
Where I landed in my code is to just filter out the flow control characters (ACK/NAK) and also the bell character (BEL) and let everything else simply show up in the output buffer, without any ANSI effects. Emacs will display any special characters with a caret. This looks nice most of the time, especially if you turn off zeptoforth's ANSI output, which can be done with some forth code like so:
: ansi-init false color-enabled ! false bel-enabled ! ; initializer ansi-init
Of course, you would need to connect using a real terminal emulator, if you wanted to run a forth program that interacts with you via an ANSI TUI.
I've used Mutt for my e-mail client for the last year or so. Mutt is a nice client and it and allows you to edit e-mails from Emacs, but ultimately Mutt is too limited as far as how far you can go with scripting and automation and such like. I've been longing to move my e-mail usage entirely inside of Emacs. So recently I stepped out and gave Gnus a try.
Connecting Gnus to my Kolabnow IMAP service was not too difficult, with Gnus nnimap backend being fairly well documented and simple to use. So now I can read e-mails inside Gnus, though I have some ways to go as far as understand the nuances of how e-mails are viewed and treated in Gnus. This is due to Gnus "newsreader" approach and not being familiar with that yet.
Figuring out how to connect to my SMTP service, i.e. how send e-mail, was initially very frustrating. I hoped this would be well covered in the Gnus manual but only a few pages briefly touch on it. Eventually, though, I realized that SMTP is not handled by Gnus, but rather a mostly separate built-in Emacs library called the Emacs SMTP Library (smtpmail.el). This library has its own separate Info manual, which is very helpful. Now I am able to send e-mails as well.
I'm hoping Gnus + smtpmail works well for me over the long haul, but it is too early to know for sure. I'll aim to make another post about this later.
This work © 2024 by Christopher Howard is licensed under Attribution-ShareAlike 4.0 International.