We have a confusing array of nearly-identical CFLAGS/LIBS definitions in
configure.ac. Time to simplify. Instead let's just have one definition
that includes all the libraries provided by Evolution-Data-Server (incl.
Camel). That, in combination with GNOME_PLATFORM, gives us most of what
we need for compliation and linking, and we can sprinkle definitions for
additional library dependencies in Makefile.am's as needed.
camel_stream_printf() is next on the chopping block.
Use g_strdup_printf() or a GString to construct a formatted string in
memory, pass it to camel_stream_write() in one go, and then check for
errors (unless it's a memory stream).
When a stream is obviously a file or memory stream (both of which
implement the GSeekable interface), use g_seekable_seek() instead of
camel_stream_reset().
This is helping me discover if it's safe to remove camel_stream_reset().
We want to eventually move to GIO streams, which have no reset method.
This changes the behavior of the function: instead of redrawing
immediately it schedules the redraw from an idle callback. This
allows us to make multiple changes to EMFormat before redrawing.
1: em_utils_reply_to_message() can be passed a newly-created message (from
a current selection. It needs to unref it. Which means that when we pass it
a message which *isn't* newly-created, we have to obtain a ref of our own.
It was that or add a boolean parameter to tell it whether to unref or not.
2: emf_finalize() wasn't unreferencing emf->message -- so when we clone
the EMFormat in em_utils_message_to_html() and immediately unreference the
clone, a refcount on the message got leaked. Fix emf_finalize() to unref
emf->message as presumably it should.
Matthew Barnes