Gbp-Dch: Ignore

and iso-codes

Gbp-Dch: Full

Update to upstream version '0.13.0'
with Debian dir 9fab5f36ddb816c801305c174bc60dfd41265cc8

When a conversation both has a message removed and eventually evaporates
or is dropped, it will be attempted to be removed from the conversation
set twice. This fixes the issue.

Fix sticky conversations in GMail

See merge request GNOME/geary!108

If a least one email in a conversation that is in the base folder but
also in another is removed from the base folder, the conversation may
not be removed from the monitor despite possibly not having any email
in the base folder, since the email may not have been completely removed
from the conversation.

This was particulary being seen with GMail accounts where even single
message conversations were not disappering when trashed because the
converation's email was still in All Mail.

This fix does a few things: Avoids hitting the database when checking
a conversation still has email in the base folder, when it does check
only ensures that email are in the base folder, not *any* folder, and
updates ConversationSet::remove_all_emails_by_identifier to do this
check iternally, clean up its API and implementation and avoids having
to use out args calling it.

Athough it was removed a while back, add it back since it is not only
needed when adding conversations, but also when removing email from
conversations to be able to detect when a conversation should be
dropped.

Email flag refinement redux

Closes #213

See merge request GNOME/geary!107

Updating the unread count after opening a folder and finding email that
has an unexpected unread status messes up the count obtained from the
server, which has already taken these messages into account.

Here, both the main normalisation process and the email flag updater are
prevented from adjusting the unread count for a folder when they
encounter email that are new and unread, or have an unread status
different from what was last seen by the engine.

See #213

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

This is especially needed since when moving a message from one folder to
another, the copy's flags are will un-flag it as deleted, so it actually
shows up again in conversations after the MoveEmailCommit op deletes the
original in the source folder.

This also has the extra benefit however of makig sure the engine knows
up-front what the uread state of all new mail is, and hence might
actaully get unread counts correct.

Refine composer shortcuts

See merge request GNOME/geary!106

Email flags not always updated

See merge request GNOME/geary!105

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

This should be handled at a per-window level.

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

This prevents losing a message if only a message body has been entered
and there is nothing has ever been undone.

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

This prevents something like Ctrl+I being typed in the subject line
triggering italic in the editor.

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

Rather than adding and removing shortcuts when the composer's web view
gains and loses focus to avoid invoking main window shortcuts, just
rely on standard GTK action scoping rules.

This fixes editing shortcuts like Ctrl+I breaking when clicking on
toolbar buttons, a crasher because the composer left the undo button
enabled after it was closed, and allows Escape to close the composer
from anywherre.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=774651,
https://bugzilla.gnome.org/show_bug.cgi?id=785187, and
https://bugzilla.gnome.org/show_bug.cgi?id=741741

Issue #45 Fix

See merge request GNOME/geary!103

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

This ensures that flag updates actually happen when doing a merge
with remote email instances obtained from the IMAP stack.

Michael Gratton authored 6 years ago and Michael Gratton committed 6 years ago

Even deleted email can have its flag updated, e.g. if undeleted from
another client. Especially important now we are observing the \Deleted
flag from the server.

It's probably a programmign error if an error is thrown, but bugs will
never be caught if they errors aren't thrown.