Patches from OpenBSD ports tree

I don't need to waste time looking at this message every startup,
just proceed as quickly as possible.

makes cache dirs get recognized as Maildirs to enable reading them
as offline backups

allows control+c to nicely interrupt hung socket reads, useful for
laptops where network connections change a lot

imap_sync_mailbox() and imap_exec_msgset() make a copy of the headers
before resorting them to generate a message-set, to avoid context
changes. I noticed the oddity in the past but didn't investigate
deeply enough at the time. :-/

The code in imap_sync_mailbox() was wrong for four reasons:
1) Because IMAP_REOPEN_ALLOW is set, sync_helper() can trigger
an imap_exec if the queue fills up, resulting in new messages
being downloaded or expunges being triggered.

2) The copy was only allocating msgcount headers, instead of hdrmax.
Downloading new messages could then attempt to append beyond the end
of the array if hdrmax > msgcount.

3) New messages or expunges would disappear when the copy was restored
afterwards.

4) The callers of mx_sync_mailbox() are prepared for context changes,
and will adjust the cursor properly to avoid jumps.

The same problems can occur in imap_exec_msgset() when reopen is set.
Not all of its callers enable reopen, or are prepared to deal with
context changes though, so the copy is needed when reopen is not set.

An alternative solution tried converting to call mutt_sort_headers()
when possible. However that solution turned out to visibly slow down
syncs due to the double sorting.

This commit instead turns off reopen for the duration of the msgset
operations.

While verifying all queued operations are flushed, I noticed the
initial "quick delete" in imap_sync_mailbox() did not seem to be
guaranteed to flush. Ensure the imap_exec() further below is
triggered if either the quick delete or sync_helper calls generate
changes. Change the quick delete to assign to "quickdel_rc" to make
it clear the flush below is for both.

Change the post sync/msgset check to look for both ((oldsort != Sort)
|| hdrs), just to make sure a memory leak doesn't occur.

Merge request !75 reported a massive slowdown opening a mailbox with
many long threads: on the order of an hour.

This is because mutt_set_virtual() was iterating through the whole
thread for each message.

After taking a closer look at current Mutt behavior, it seems the
num_hidden count is only needed in the root thread. Quoting my
comment in the merge request:

The index-format expando %M only applies to root level headers, so
there are no issues there.

The only concern is the pattern ~v. Limiting always resets collapsed
and num_hidden, so there also can't be any issues there. Tagging and
other pattern operators only work on visible messages. So tagging
while threads are sorted will only tag the root messages of
collapsed threads.

However, if you sort by thread, collapse a thread, and then sort by
date, the collapsed and num_hidden fields are not reset for each
header. In theory this would allow us to tag ~v with date
ordering. However, in master the num_hidden is only set (by
mutt_set_virtual()) for visible messages with a virtual number.

So even in master, switching to date-order and tagging ~v will only
tag the root messages of each collapsed thread.

This commit removes the num_hidden setting in mutt_set_virtual(),
instead directly assigning that value in the roothdr during a collapse
operation.

A subsequent commit will fix the behavior of ~v, when switching
sorting from threaded to something else, by putting num_hidden in
every header in the thread. This is technically a change in behavior,
so I will make that commit in the master branch.

Thanks to Score_Under for the pull request and for testing my
alternate solutions.

In theory it's a good idea encourage SSL usage everywhere.

However ticket #210 showed that, in reality, that kind of change
breaks configs and so is still not a good idea.

$ssl_startls defaults set and will use STARTTLS if the server
advertises it.

Use mutt_addwch instead of addch to draw the replacement_char in
pager.c. The line to draw the replacement char was
addch (replacement_char ())
However, if Charset_is_utf8 is true, replacement_char returns 0xfffd,
which is outside the range that addch can handle. Use mutt_addwch
instead so that the pager displays the replacement char properly.

Commit 8353407c enabled checking for buffered OpenSSL/GnuTLS data when
polling, but neglected to check if the connection was already closed.

This can be triggered during imap_logout() if the connection write of
"LOGOUT" fails and closes the connection, before the poll. It's a bit
tricky to trigger because imap_logout_all() checks for a closed
connection, so the failure needs to take place at that last write.

Thanks to Stefan Sperling for pointing out the problem, complete with
a backtrace and patch. (This commit takes a different approach for a
stable-branch fix.)

The auto-clearing code was added in commit 01bc088c, for autocrypt
initial prompting. It removed having to keep track of every place a
browser or other menu might be displayed and having to remember to
clear it out.

However, clearing when mutt exits is a change of behavior for those
who have turned off alternative screens.

This reverts commit 317b7f6b53d8a4272acf8ef1b56f3406e9bc2691.

imap_open_mailbox() leaves IMAP_REOPEN_ALLOW set for the connection.
I noticed this previously but didn't bother untangling the logic yet
because the index always calls mx_check_mailbox() right away, which
unsets the flag.

However, when debugging the segv for commit 51729d8d I realized the
postponed menu/context also suffers from the problem, leaving the menu
ripe for segvs due to unmanaged expunges.

I believe imap_read_headers() turns it off and back on to avoid
goofing up imap_cmd_finish() when a reopen *is* allowed.

The logic needs to be cleaned up and fixed. However for a stable
branch fix, I'm am taking a conservative approach and just calling
mx_check_mailbox() to turn it back off.

mutt_get_postponed() was calling mx_close_mailbox(), but not checking
the return value. Because the postponed context is an actual
read-write, selected mailbox in a new connection, a failed close left
a dangling pointer in connection->idata->ctx.

imap_keepalive() traversed the connection list, finding the Postponed
connection still there, and passed the dangling pointer to
imap_check_mailbox.

Change an empty postponed mailbox to just call fastclose. Change the
other closes to retry on a postive return code "reopen" event and then
finally just call fastclose.

Outside the index and postponed menu, Mutt's code only uses append or
readonly temporary contexts. Those are guaranteed to call
mx_fastclose_mailbox() and return 0.

Rename to $sidebar_use_mailbox_shortcuts. The shortening wasn't that
much shorter and made the name confusing.

To prevent complaints in the future as others transition to 1.13,
default off.

In actuality, the parent_depth and indent_width won't ever be
negative.

But the new code for unset $sidebar_relative_shortpath_indent makes
this much less obvious. Better to be explicit than have some small
future code change result in a bug.

When unset this option provides the pre-1.13.0 sidebar indentation and
shortpath behavior.

Setting the option will enable the new (relative to previous entries)
indentation and shortening behavior.

Note the mailbox shortcuts are controlled by
$sidebar_use_mb_shortcuts, which defaults set.

I actually intended to push commit abfaa0e0 to a remote branch, but
accidentally ended up pushing it to stable. :-O

Anyway, I think the option is okay, but may have to tweek it a bit.
This fixes a mistake where it was placed out of order in init.h.

If unset, Mutt will revert to pre-1.13 display behavior, matching and
removing a literal $folder prefix, without using mailbox shortcuts.

Make the abbreviation a bit clearer, that it means Encryption instead
of Encoding.

Thanks to Morten Bo Johansen for the suggestion.

Sync from mutt.pot after 'make update-po'

Signed-off-by: Olaf Hering <olaf@aepfle.de>

The wording was ambiguous, and could give the impression that a
message, if fcc'ed, would contain the Bcc header when sent too.

Although the behavior has now been fixed, add $write_bcc references to
$record, $sendmail, and $smtp_url to make users more aware of the
behavior.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

This is just an initial version, complete with typos and other
mistakes. Committing now so translators can refer to it.

Include attachments if it is 'yes' or 'ask-yes', like $copy and
$send_multipart_alternative.

Emulate the behavior of $copy, which performs fcc for 'yes' or
'ask-yes' values.

add view-alt function, so now we have
* view-alt "v"
* view-alt-text "Esc v"
* view-alt-mailcap "V"

Changing to mutt_read_line() avoids -Wunused-result warning while
reading the ignored line in query protocol response.

Most of these were already commented. Change a few of them to
a format gcc will recognize. In the future, we'll want to change to
whatever is standardized.

Some mail clients (*cough* Apple Mail) have started to put email
attachments in one of the multipart/alternative branches.

The config changes the searching to recurse inside alternatives when
performing attachment counting.

_() can invoke malloc, so remove l10n translations.

printf() is not safe either, so use write().

I'm not sure at this point about curs_set() and endwin(), but they
seem important enough for proper terminal cleanup to risk leaving in.

Thanks to Oswald Buddenhagen for pointing out the problem, and the old
trac ticket from Vincent at:
<https://gitlab.com/muttmua/trac-tickets/raw/master/tickets/open/3791-SIGQUIT_Ctrl_while_opening_mailbox_made_Mutt_hang.txt>

This was contributed by martin f. kraft, to give an example script for
the new $send_multipart_alternative_filter funtionality.

I recall seeing a message on IRC, where someone reported their macro
suddenly aborting after invoking an editor or something similar. At
the time, I wasn't sure of the problem, but this seems a likely
culprit, if the event caused a sigwinch.

Neither the menu.c nor the pager.c SigWinch handlers do such a thing.
The line was part of the initial import 21 years ago, so there is no
justification given.