On Thu, Feb 11, 2016 at 09:13:42AM -0800, Kevin J. McCarthy wrote:
> Thanks for the suggestion - that was the problem: I forgot to try it
> with gpgme! With gpgme, I can reproduce "Invoking PGP..." being stuck
> in the message after decryption. I'll get a patch in for that. Please
> let me know if there are other issues you see.
Here's another problem I'm seeing:
(without passphrase already cached by GPG), use 'limit' to find an
encrypted, *traditional* (not pgp-MIME) message in a folder. In some
cases, not completely reproducible, I then only see the 'S' in the index
lines that show up (when $pager_index_lines is set), and I see artifacts
of the pinentry page, sometimes sticking around for a while. The
screenshot here should show the behavior.
Additionally, after this problem comes up, the up arrow in the 'limit'
pattern doesn't work (I get, e.g., [A for up-arrow), though I can still
type in there Ok.
One other question -- it looks like $pgp_create_traditional doesn't work
with the $crypt_use_gpgme backend. The docs do kind of imply that, but
maybe it should also generate a startup warning if you have
$crypt_use_gpgme and $pgp_create_traditional both set?,
Specifically, it says:
# If it is set and Mutt was built with gpgme support, the gpgme code
# for S/MIME and PGP will be used instead of the classic code.
but maybe there should be at least a stronger warning that non-MIME
("traditional") PGP won't be generated at all with this option?
w
