Richard Russon [Fri, 7 Jun 2019 11:20:03 +0000 (12:20 +0100)]
merge: trivial fixes
* fix folder use in mx_path_canon()
* doxy: fix typos
* rename local variable for clarity
* test: tidy code
* refactor #ifdef'd conditional
* check includes with iwyu
Richard Russon [Fri, 7 Jun 2019 00:21:45 +0000 (01:21 +0100)]
merge: upstream fixes
* Turn on $ssl_force_tls by default
* Change mutt_addr_is_user() to no for a NULL address
* Minor documentation correction
* Fix dropped new mail notifications when an EXPUNGE_PENDING is set
* Improve robustness of imap_append_message()
* Enable the idata->check_status using bit operations
Kevin McCarthy [Thu, 6 Jun 2019 23:03:42 +0000 (16:03 -0700)]
Enable the idata->check_status using bit operations
Commit e3f66d7e fixed dropped new mail notications, removing the
unsetting of idata->reopen IMAP_NEWMAIL_PENDING in imap_cmd_finish()
when an EXPUNGE was processed.
However, imap_cmd_finish() can be called twice by
imap_check_mailbox(). First as part of the imap_exec(), and manually
again just below.
Now that the IMAP_NEWMAIL_PENDING still exists, a second call could
overwrite idata->check_status if both reopen flags were set.
This unfortunately affects update_index(), which behaves differently
for MUTT_REOPENED.
I need to change the return value of mx_check_mailbox() in master to
preserve all the bits, so the index can both notify of new mail and
update_index() properly.
For stable, the best fix is to use bit operators to enable the
check_status flags in imap_cmd_finish() (and cmd_parse_fetch for
flags), and keep the imap_check_mailbox() priority of setting its
return value (it prioritizes IMAP_EXCHANGE_PENDING).
Kevin McCarthy [Thu, 6 Jun 2019 20:38:03 +0000 (13:38 -0700)]
Improve robustness of imap_append_message()
First, check the imap_cmd_step() return value instead of looking at
idata->buf for "OK". If the connection bombed and imap_cmd_step()
returned IMAP_CMD_BAD, the value of idata->buf is stale.
If the server returned "+ OK" for the command continuation request
response, the call to imap_code(idata->buf) would even end up
returning true, despite that the append failed! (See #110, although
at the time of commit I can only hypothesize this is what is
happening.)
Second, check the status of the writes. flush_buffer() was not
passing the rc from mutt_socket_write_n(), which was further making
the above disaster scenerio possible.
Kevin McCarthy [Wed, 5 Jun 2019 21:04:55 +0000 (14:04 -0700)]
Fix dropped new mail notifications when an EXPUNGE_PENDING is set
Prior to the fetch_headers rework and introduction of
idata->max_msn (starting around e0376c75), cmd_handle_untagged() was
looking directly at ctx->msgcount, which isn't fixed up until
imap_expunge_mailbox(). At that time, more care had to be taken
inbetween handling the EXPUNGE message and the actual expunge of the
mailbox because of the discrepency between server state and mailbox
context state.
idata->max_msn is now decremented during the processing of EXPUNGE and
VANISHED notices from the server, so reflect "current" state. So,
when we receive an EXISTS notice, we no longer need the checks for
expunge state and can always set the NEWMAIL_PENDING flag.
Additionally, fix imap_cmd_finish() to retain the IMAP_NEWMAIL_PENDING
flag after handling an expunge. The expunge does not grab new
messages so dropping the flag would cause mutt to forget the new mail
status until another EXISTS command.
Since this is a stable branch fix, I'm leaving the either/or
processing of expunge versus new mail in imap_cmd_finish(). However,
I don't see why this has to be done in two calls. I may rework that
in master to process an expunge and then the new mail one after the
other.
Kevin McCarthy [Sun, 26 May 2019 21:34:42 +0000 (14:34 -0700)]
Turn on $ssl_force_tls by default
Ticket #135 suggests that these days, it's better to force encryption
over all connections. RFC8314 is recommending MUA's move in that
direction (actually even directing towards implicit TLS over
STARTTLS).
I'm enabling this at the beginning of the 1.13 development cycle to
give others time to chime in with any objections. Personally, I've
had this option set myself for years. The only place it could become
an issue is for a localhost IMAP server with no cert. In that case,
it's easy enough to have an account hook unset if needed, and I think
a better idea that the user be forced to turn it off.
David Harrigan [Thu, 6 Jun 2019 12:09:25 +0000 (13:09 +0100)]
Save attachments without prompting.
If the 'attach_save_without_prompting' variable is set (to true), then on
saving a list of tagged attachments the user will not be prompted each time
for the name of file.
Conflicting filenames during save are also handled.
Sebastian Stark [Sun, 26 May 2019 08:04:58 +0000 (10:04 +0200)]
make OP_HALF_{UP,DOWN} behave symmetric.
- the calculation of number of lines to scroll up/down should not
depend on whether the number of rows in the pager/index/terminal is
odd or even.
- this patch will make the behaviour symmetric such that in both cases
(even/odd number of rows) scrolling up and down by half a page (or the
other way round) will get you back to the exact same line as before.