For rendering HTML emails I use either shr or w3m. To get it more readable I make the text area smaller with writeroom-mode/olivetti-mode in the mu4e-view-mode-hook. But both modes apply just after opening an email a second time.
One big item is that that Emacs' internal string/buffer representation supports things like loading weirdly (or even erroneously) encoded data, and saving this unchanged; this is sometimes quite useful.
Guile's strings (gnulib's) do not support that, and adding the support is quite a bit of works for all the corner-cases that emacs supports.
Now, emacs and guile do not necessarily have to use the same underlying string/buffer implementation, but it would definitely be a big plus, and I wouldn't be surprised the emacs maintainers would require it.
Mu4e has a few different options for displaying rich-text messages. In recent emacsen, it defaults to a shr/eww based display; it's not perfect, but it reduces the set of problem cases.
For those, there are the view-in-browser action, and with (as of yet unreleased) emacs-25 you can use a webkit-based display embedded in emacs.
With those, I'm able to view just about any message; even the ones I get from airlines etc., which tend to be html-only.
Anyway - to get back to the top-level subject: congratulations to mutt, which is a great e-mail client, and a big influence on mu/mu4e.
In the same spirit, I wrote some functionally-flavored extensions for GLib a few months back. https://github.com/djcb/gxlib, taking a bit of inspiration from Rust and SRFI-1.
It's fun to get some of the functional flavor, while still being very near the bare pointers.
There are also gdb and make, which are probably a bit more prominent examples of guile-integration. Perhaps one day, emacs will do so as well.
I've embedded Guile into some of my own projects, and it's a great and fun way to bring a bit of life in "dead" compiled code. Many more projects would benefit from this.
And, for completeness, Chong Yidong, how co-maintained together with Stefan for quite a while (and did a great job as well). I think both of them were quite a big part of the "emacs renaissance" of the last few years.
Agreed -- I remember some of the alternative ways to solve the same
problems, such as CORBA and various custom protocols, but they were
painful to use...
Now, early DBus was a bit lacking in that respect as well, but with
GDBus (GLib's DBus implementation) it's become as straightforward as
IPC can be, even in plain C; I've seen quite a few people new to the
technology that were able to get up to speed with it quickly.
It'll be interesting to see how people are taking DBus and pushing the
boundaries of what it can be used for, such as kdbus.
Interesting perspective. I thought I read somewhere that ZeroMQ was championing becoming apart of the Kernel. I work in the embedded space and not knowing much about DBUS other than it's some fancy IPC and ZeroMQ, we went with ZeroMQ just because we saw a clear path for what we needed get done. Granted all our IPC communication was between our own apps. but after reading your post I keep wondering what REAL problems does DBUS solve besides having a standard messaging format? Could someone explain why a simple messaging format couldn't be deployed on top of something like ZeroMQ?
This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser.
dbus is not mostly about IPC.
Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process.
Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability.
Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces.
The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon.
Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.
dbus handles a lot of cases where you have an unprivileged process like a GUI widget communicating information to a root process like a network manager. Because it's centralized and everything flows through the dbus process, a lot of it is about policy enforcement— ie, these methods can be called by this user or group, these other ones by this other group, etc.
Examples of the configuration which controls this kind of thing:
Had a lot of (slightly masochistic) fun programming the Z80 back in the day on my MSX2 machine.
I didn't have an assembler, so I wrote my code by taking the opcodes from a table, calculating offsets etc., then turning them into DATA-lines in an MSX-Basic program, which POKEd the code into RAM, then CALL into the starting address.
Same here! And i'm not sure was is masochistic about it; I still write software for the MSX2 like that now ;) I only knew about Hisoft assembler and that was too expensive so I never learned anything different than opcodes.
allowed, after some short time without even looking at the table, to type the binary code directly in (our preferred way of the Forth words implementation back then, on Russian 8080 clone of course :).
When I got my MSX from the attic after almost 30 years I still remembered almost all the opcodes. Took me few days to relearn the rest; I was 8 when I memorised them...
My first intro to microprocessors was the Z80 book published by Howard Sams. I never actually tried using one, but the book was so well written that it gave me an excellent foundation.
I'd probably recommend one of the older uP's for anybody who is just getting started, as they are so much simpler.
Ah yes, so much power going the assembly code route, it took me a while to shake it. Started entering opcodes in the z80, and thought that Masm was as good as it could get. Was still doing Windows x86 assembly programming, until I found another way.
