| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
If there was a known formatter for the attachment's mime type, the attachment
content was shown inline, without the attachment button, instead of it being
shown collapsed and with the corresponding button. All that caused by a variable
overwrite and a related memory leak.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GFilterOutputStream, from which CamelFilterOutputStream is derived,
defaults to closing its base stream when the instance is finalized.
That makes sense in the general case, but CamelFilterOutputStreams are
usually temporary wrappers on a more permanent base stream, so we need
to remember to override the default "close-base-stream" property value.
I was tempted to just make CamelFilterOutputStream override the default
automatically, but I decided against it because my long term plan is to
drop CamelFilterOutputStream for GConverterOutputStream which also does
not override the "close-base-stream" default. The closer the semantics
of the two classes match, the easier porting will be in the future.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Win32 headers have a #define for 'interface', which breaks the build
when this word is used in the code, thus replace it to 'iface',
the same way as GLib or GTK+ code use to have it. (See bug #722068.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Any GtkWidget creation or manipulation should be done exclusively
from the main/UI thread, thus make sure it is done that way.
Of course, evolution can freeze for a little time (depends on the message
size), until its formatting is done. It's unnoticeable with usual messages.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Drop our explicit gstreamer requirement and merge audio support directly
into libevolution-mail-formatter. We now use the HTML5 <audio> tag and
let WebKit show much nicer playback controls, with volume and seeking.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes the code free of Coverity scan issues.
It is sometimes quite pedantic and expects/suggests some
coding habits, thus certain changes may look weird, but for a good
thing, I hope. The code is also tagged with Coverity scan
suppressions, to keep the code as is and hide the warning too.
Also note that Coverity treats g_return_if_fail(), g_assert() and
similar macros as unreliable, and it's true these can be disabled
during the compile time, thus it brings in other set of 'weird'
changes.
|
| |
|
|
| |
Use: #include <libemail-engine/libemail-engine.h>
|
| |
|
|
| |
libemail-engine doesn't need to know about this enum.
|
| | |
|
| |
|
|
|
| |
Content-Disposition of the test case is honored now, but still not the
Content-Transfer-Encoding.
|
| |
|
|
|
|
| |
This is only a partial solution for the test case the bug report.
The message/news part of the test case is also Base64-encoded, but
Evolution (or Camel) is not decoding it properly. Still digging.
|
| | |
|
| |
|
|
|
|
|
| |
The "signature bar" overrides background color, thus it should
override also text color, to make sure the text will be always
readable. This could break with dark theme, which uses light
text color.
|
| |
|
|
|
| |
CamelMultipartSigned no longer has a public 'protocol' member. Obtain
it instead by checking the CamelContentType for a 'protocol' parameter.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
works
When we were collecting the elements for adding the onclick event
listeners, we were using the webkit_dom_document_get_element_by_id
method, but when email had multiple TO, CC or BCC headers it was
returning just the first elements with given id. To fix this we moved
to webkit_dom_*_query_selector methods that give us more powerfull
element extraction from document.
When toggling the visibility of header row, we are now operating just
in the row that contains the clicked element.
This patch also remove the suffixes from all __evo-moreaddr ids.
|
| |
|
|
|
|
|
| |
Avoid redrawing (thus loosing the selection and scroll position) of
preview window on style change by defining the colors through CSS styles.
On style change we just update the CSS color definitions and preview will
update itself without redraw.
|
| |
|
|
|
|
|
| |
Commit 514736f27efeac6d5ad42e055ebabb423d243fb2 in 3.9.5 broke inline
PGP encrypted messages, because the parser was treating the encrypted
message content as an attachment even though the content type is just
text/plain. This ensures the message content is treated correctly.
|
| |
|
|
| |
Return type is a boolean, not an integer count.
|
| |
|
|
|
|
|
|
|
|
| |
Simo Sorce sent me an interesting case where the MIME type of the
message itself was image/gif, but the image was not being shown.
If the EMailPart representing the message body is marked as an
attachment, wrap it as such so it gets added to the attachment
bar but also set the "force_inline" flag since it doesn't make
sense to collapse the message body if we can render it. */
|
| |
|
|
|
| |
Declare the instance and class structs normally so Gtk-Doc can make
sense of it.
|
| |
|
|
|
| |
Declare the instance and class structs normally so Gtk-Doc can make
sense of it.
|
| | |
|
| |
|
|
| |
Use the EMailPartHeaders API instead.
|
| |
|
|
|
| |
Use e_mail_part_headers_dup_default_headers() to extract specific
headers to show in the desired order.
|
| |
|
|
|
| |
Use e_mail_part_headers_dup_default_headers() to extract specific
headers to show in the desired order.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the print dialog's "Headers" tab into a separate widget.
EMailPrintConfigHeaders takes an EMailPartHeaders and displays its print
model, which is a representation of all message headers (except subject)
with an on/off flag for each. The headers can be toggled and reordered,
and the changes are written back to the print model.
During printing, EMailFormatterPrintHeaders uses the same print model
to determine which headers to show and in what order (except subject).
This approach is much saner than the old method, which was trying to
manipulate WebKitWebView DOM directly to toggle and reorder headers.
This approach also happens to work, whereas the old method did not.
|
| |
|
|
|
|
|
|
| |
Returns a GtkTreeModel of header names and values and visibility flags,
built from the CamelMimeMessage. The tree model rows can be reordered
and toggled prior to printing.
Also add e_mail_part_headers_is_default() as a handy helper.
|
| |
|
|
|
|
|
|
|
| |
This will replace the headers API in EMailFormatter. Need a more
permanent place for headers since EMailFormatter is too disposable.
Also add an ESettingsMailPartHeaders class, which binds the new property
to the "show-headers" setting with a suitable mapping function to filter
out disabled header names.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Split the _camel_header_raw struct parameter into separate "header_name"
and "header_value" string parameters, which is all the function actually
needs to work.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is a weak reference to the EMailPartList to which the EMailPart
has been added. The property is set by e_mail_part_list_add_part().
New functions:
e_mail_part_ref_part_list()
e_mail_part_set_part_list()
|
| | |
|
| |
|
|
|
| |
We don't show an icon for other mailers, and the tiny 16x16 pixel
icon looks stupid next to the much larger contact/gravatar image.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HTML for attachments always has the following form:
<div class="attachment-wrapper" id="something" style="display: block;">
<actual attachment element>
</div>
The <div> element controls attachment visibility through its "display"
style attribute, which is either "block" or "none".
Problem is the <actual attachment element> was getting the same ID as
its parent <div> element. So when either element was requested by ID,
in certain cases the wrong element was returned and caused misbehavior
and console warnings.
Solve this by adding a "wrapper" suffix to the <div> element ID. So in
the example above, id="something" gets the <actual attachment element>,
whereas id="something.wrapper" gets the <div> element.
|
| | |
|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also add an evolution-mail-formatter documentation module.
|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also rename the documentation module to evolution-shell.
|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also rename the documentation module to evolution-util.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EAttachment is now used from worker threads by EMailFormatterAttachment,
so add some thread-safe accessor functions to eliminate potential races.
Added thread-safe functions:
e_attachment_dup_disposition()
e_attachment_ref_file()
e_attachment_ref_file_info()
e_attachment_ref_icon()
e_attachment_ref_mime_part()
e_attachment_dup_description()
e_attachment_dup_thumbnail_path()
Renamed functions:
e_attachment_get_mime_type() -> e_attachment_dup_mime_type()
Removed non-thread-safe functions:
e_attachment_get_file()
e_attachment_get_file_info()
e_attachment_get_icon()
e_attachment_get_mime_part()
e_attachment_get_description()
e_attachment_get_thumbnail_path()
|
| | |
|
| |
|
|
|
| |
EMailPart is reference-counted, subclassed, and allows a custom
finalize function. There's no excuse for it not to use GObject.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Not thread-safe. Use e_mail_formatter_dup_headers() instead.
|
| |
|
|
| |
Duplicates an EMailFormatterHeader struct.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We used to do this before WebKit and it looked better.
Also fix up the header section for right-to-left locales:
put the collapse button on the right, and images on the left.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It could happen that header text color had been picked white one time,
but the other time black as expected (for me usually when I started
Evolution in Calendar and moved to Mail view, the header text color
was white, while when starting in Mail view it was black). The change
to use GtkStyleContext is there only as a cleanup from deprecated
GtkStyle, and to make things easier too, because both GtkStyle
and the GtkStyleContext had set white color for some reason.
|
| |
|
|
|
|
|
| |
The multipart/mixed should behave differently than multipart/related,
because subparts of multipart/mixed are not meant to reference each
other by default, thus the subparts should be shown as attachments.
This was reported at https://bugzilla.redhat.com/show_bug.cgi?id=947409
|
| |
|
|
|
|
|
|
| |
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
|
| | |
|
| |
|
|
| |
EPhotoCache already handles this setting.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
GTK+ uses (G_PRIORITY_HIGH_IDLE + 20) for redrawing operations, which is
actually a slightly lower priority than G_PRIORITY_HIGH_IDLE. Therefore
for our purpose, G_PRIORITY_HIGH_IDLE is sufficient.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 2b507716b257e6ef98dae8463180dbe718eb7b64.
The commit contains not a single comment as to why these custom priority
values are being used. The rationale needs to be documented in the code,
either at each call point or preferrably at a centralized priority value
definition.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a priority field to EMailFormatterExtension and EMailParserExtension
class structs. Extension classes can then explicitly specify a priority
with respect to other extension classes with the same MIME type, so that
the order of extension registration doesn't matter.
Priority field defaults to G_PRIORITY_DEFAULT. Built-in formatters and
extensions will use G_PRIORITY_LOW. We can get more sophisticated with
priority values if we need to, but this should suffice for now.
|
| |
|
|
| |
Restore this commit with a proper bug fix to follow.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit bf30024dd7973006bf99d0ae509a7f0022368a41, because
it breaks EMailFormatter/Parser extensions, like the prefer-plain.
The thing is that the internal formatters/parsers (also extensions)
should be always added first, and only after then can be added extended
extensions, which are used before those internal. This constraint was not
satisfied with the reverted commit, the order of extension registration
was unpredictable, depended on GType.
|
| |
|
|
|
|
|
| |
Might be the final change for this bug, the two previous commits
were not using the right approach, causing regression in rendering
of text/* parts which were not named in the list of excluded content
types for a 'raw' formatting.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move the supporting widgets for the contact maps feature alongside
EABContactDisplay. Removing them from libeutil helps isolate our usage
of libchamplain so it's not imposed on the entire application, and even
3rd party software. That libchamplain is an optional dependency only
further complicates the matter.
Ideally I'd like to somehow isolate this feature in an extension module,
but we currently lack sufficient hooks for such an extension. So this
arrangement will have to suffice for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Evolution consists of entirely too many small utility libraries, which
increases linking and loading time, places a burden on higher layers of
the application (e.g. modules) which has to remember to link to all the
small in-tree utility libraries, and makes it difficult to generate API
documentation for these utility libraries in one Gtk-Doc module.
Merge the following utility libraries under the umbrella of libeutil,
and enforce a single-include policy on libeutil so we can reorganize
the files as desired without disrupting its pseudo-public API.
libemail-utils/libemail-utils.la
libevolution-utils/libevolution-utils.la
filter/libfilter.la
widgets/e-timezone-dialog/libetimezonedialog.la
widgets/menus/libmenus.la
widgets/misc/libemiscwidgets.la
widgets/table/libetable.la
widgets/text/libetext.la
This also merges libedataserverui from the Evolution-Data-Server module,
since Evolution is its only consumer nowadays, and I'd like to make some
improvements to those APIs without concern for backward-compatibility.
And finally, start a Gtk-Doc module for libeutil. It's going to be a
project just getting all the symbols _listed_ much less _documented_.
But the skeletal structure is in place and I'm off to a good start.
|
| |
|
|
|
|
| |
This way it'll be possible to copy whole files if change in one
of them will be done. A real code reuse, rather than copy, would be
ideal, but the trust-prompt is just a module for evolution-user-prompter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have the following extension points in the GType hierarchy:
E_TYPE_MAIL_FORMATTER_EXTENSION
E_TYPE_MAIL_FORMATTER_PRINT_EXTENSION
E_TYPE_MAIL_FORMATTER_QUOTE_EXTENSION
E_TYPE_MAIL_PARSER_EXTENSION
A registry just needs to be given one of these extension points, and it
can use g_type_children() to find and load all registered extensions.
This eliminates e-mail-format-extensions.[ch] as well as the dynamic
loaders I added a few commits back. Dynamically loaded extensions are
now easier to register, at the cost of internal extensions being a tad
more cumbersome to register. Fair tradeoff, imo.
This also makes e_mail_extension_registry_add_extension() a private
function used only by e_mail_formatter_extension_registry_load() and
e_mail_parser_extension_registry_load().
|
| | |
|
| |
|
|
|
| |
This is an abstract base type for formatter extensions which are
intended only for use by EMailFormatterQuote.
|
| |
|
|
|
| |
This is an abstract base type for formatter extensions which are
intended only for use by EMailFormatterPrint.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We define the header flags as an enum type, so use the enum type.
|
| |
|
|
| |
We define the header flags as an enum type, so use the enum type.
|
| | |
|
| |
|
|
|
|
|
| |
Of the parser extensions that override get_flags(), they all return a
fixed set of flags. So we don't need an instance of the extension to
obtain its flags. Just make it an EMailParserExtensionFlags field in
the class structure.
|
| |
|
|
|
|
|
|
|
| |
With the previous changes, all parser extensions derive from
GObjectClass and implement the EMailParserExtensionInterface.
Simplify things further by making EMailParserExtension an abstract base
class so parser extensions are now just direct subclasses and need not
bother with implementing GObject interfaces.
|
| | |
|
| |
|
|
|
|
| |
Of the formatter extensions that provide a description, they all use a
static string. So we don't need an instance of the extension to obtain
its description. Just make it a string field in the class structure.
|
| |
|
|
|
|
| |
Of the formatter extensions that provide a display name, they all use a
static string. So we don't need an instance of the extension to obtain
its display name. Just make it a string field in the class structure.
|
| |
|
|
|
|
|
|
|
| |
With the previous changes, all formatter extensions derive from
GObjectClass and implement the EMailFormatterExtensionInterface.
Simplify things further by making EMailFormatterExtension an abstract
base class so formatter extensions are now just direct subclasses and
need not bother with implementing GObject interfaces.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
EMailExtension is now too trivial to keep as a standalone interface.
Add a 'mime_types' string array to the EMailFormatterExtension and
EMailFormatterParser interface structs.
Alter e_mail_extension_registry_add_extension() to take a 'mime_types'
string array and the GType of an extension to instantiate, rather than
the extension instance directly.
e_mail_extension_registry_remove_extension() is no longer needed.
|
| |
|
|
|
|
|
|
|
|
|
| |
In all implementations for EMailExtension, the MIME type list is a
static string array -- with the single exception of the text-highlight
module, where the MIME type list is dynamically assembled once.
Replace the mime_types() method with a "mime_types" string array in the
EMailExtensionInterface struct. Then the list of MIME types supported
by the class implementing the EMailExtensionInterface can be obtained
without requiring an instance of the class.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collect EMailParts in a GQueue provided to the EMailParserExtension,
and change the return type of parse() to gboolean to indicate whether
the given CamelMimePart was handled (even if no parts were added to
the output GQueue).
This avoids the awkward corner case of a parser extension returning a
linked list node with a NULL data member to indicate the CamelMimePart
was handled but no EMailParts produced, and then having to watch out
for that NULL data member corner case throughout the application.
Also, remove the GCancellable parameter from e_mail_parser_error() and
e_mail_parser_wrap_as_attachment() since neither function blocks.
|
| | |
|
| |
|
|
|
|
| |
Exposing data members in the public struct is unwise, especially when
EMailPartList is used from multiple threads. Instead keep the members
private and provide a set of thread-safe functions to manipulate them.
|
| |
|
|
|
| |
Replace the individual components of an EMailPartList with a reference
on the EMailPartList itself in EMailFormatContext. Easier to manage.
|
| |
|
|
|
|
|
|
|
|
| |
Replace the create_context() and free_context() class methods with a
"context_size" class member defaulting to sizeof(EMailFormatterContext).
EMailFormatter will use "context_size" to allocate a zero-filled slab of
heap memory. Since EMailFormatterQuote is currently the only thing that
overrides the "context_size" (to append a "qf_flags" member), let's keep
this simple.
|
| | |
|
| | |
|
| |
|
|
|
| |
There's no need to check whether the 'parsers' GQueue is NULL since we
assert that it's non-NULL just a few lines above.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This reverts commit 7050a1286825, which broke opening of IMAP message.
It's also the correct solution for the initial issue, because
the message_uid can contain letters which should be encoded in the URI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the highlight program cannot be found width AC_PATH_PROGS,
configure will abort with an error message.
You can either
a) install highlight
b) specify the patch with HIGHLIGHT=/path/to/highlight
c) pass --disable-text-highlight to configure to exclude the module
This also makes text-highlight module to fallback to text/plain
formatter when highlight program would crash or fail to ensure
the content is delivered to user.
|
| |
|
|
|
|
|
| |
This way the view corresponds to the original part properties,
not those stripped by the inline filter. Also initialize
EMailInlineFilter::filename on creation of the structure, thus
the value is actually used on the subparts, if needed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is leftover from the WebKit port and it didn't work
properly. Most of the code was removed, some was moved
to a better place.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This adds 'Format as' submenu to the preview pane context menu.
The submenu is available only for text/plain parts or parts
with a source code (we support about 40 various types). Using
the 'highlight' utility, the formatter processes the part and
highlights the source code it contains.
(discussion in bug #680026)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Regression from commit 99a875ed
|
| | |
|
| | |
|
| |
|
|
| |
Private header, but still need to distribute it.
|
| |
|
|
| |
This variable is not defined anywhere.
|
| | |
|
| | |
|
| |
|
|
| |
G_DEFINE_TYPE macros define a static "parent_class" variable.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The new formatter was ignoring selected headers, always displaying
only From, To, Subject and Date (default headers).
Handling of the currently displayed headers has been moved to
EMailConfigFormatHTML extension, because it is related to
configuration of EMailFormatter, rather then EMailReader.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
|
| | |
|
| | |
|
| |
|
|
| |
Always call it immediately after g_simple_async_result_new().
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Replace 8-space indentation with tab characters, and various other
automated cleanups.
|
| |
|
|
| |
Pass it in instead of digging it out of EShellSettings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Move public members to the private struct.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
GCC learned how to find dead assignments.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Includes some minor code cleanups related to this investigation.
|
