The GNU project does not list proprietary software as GPG-Shell

That is not a bug - but a feature. For PGP/MIME messages GPGol uses its own
MIME machinery. Running this for the preview window would be too cumbersome.1

The first is a problem of the distribution. Distributing gpg2 without a
properly installed pinentry is just stupid.

That is very likely a matter on how the passphrase has been created. It is
known that WinPT at some point changed how it encoded passphrases.

Oh, interesting. How do you plan to handle common problems like no pinentry
configured (or even installed because distros don't make gnupg depend on it) ?

gpg2 can't use that as the agent is a hard requirement. The only reason for
keeping the passphrase callback is for symmetric encryption.

I understand your conclusion. I know nothing of GnuPG's demographics other
than what I might guess. If there are a number of users who may be unaware,
then I think that it might be helpful information to include somewhere. I do
think however that to introduce change in the software because of a lack of
knowledge would only contribute to the continued lack of knowledge.

x: Do you agree with my conclusion?

Ok. Thanks for your attention and patience.

Latin-1 defines those as application specific. Some terminals actually use them
as control characters. Thus when filtering any output to do no harm it is
better to escape them too.

Because --with-colons is not for humans.
The specification says that the output is utf-8.
Haveing this variable would add an additional burden
to each consumer of --with-colons output to convert it.

Ok. I see.

We install all the documentaion we consider as useful. If you do not like that,
delete these files after installation.

Because --with-colons is not for humans. The specification says that the output
is utf-8. Haveing this variable would add an additional burden to each consumer
of --with-colons output to convert it.

I think whether --disable-nls is exclusively related to the software may be a
matter of interpretation.

Why? Why not to use --charset to set encoding? Why escaping is needed if this
mode (with-colons) is not appointed to diplay( isn't it?) but to get keys
information to applications?

Your keyring is corrupted. You better get a backup.

we don't have any tr directory. It is anyway planned to switch the whole site
over to only use utf-8.

I tried to descrypt with different versions of gpg. But all failed. The only one
working is 1.4.2.1 from the cygwin package. Then I reinstalled version 1.4.5
from gpg4win 1.0.6 package. Typing in the passphrase constantly fails, but when
the passphrase is stored in an environment variable and piped into gpg (called
with --passphrase-fd 0) then decryption works fine. My passphrase contains some
special characters of the iso88591 characterset for security reasons. But this
should not make any difference. But I suspect it's a matter of charactersets
when reading the passphrase. I suppose it's not being read from stdin (fd 0)...

I had no other idea how to narrow down the problem. Decryption used to work with
WinPT. Because it no longer worked as of version 1.0 I tried to decrypt directly
calling gpg that came along with gpg4win (which didn't work either). So I tried
to use an older version of gpg in order to proof if the keyrings are ok and working.
I had no copy of gpg version 1.4.4. As far as I remember it worked up to and
including gpg 1.4.4. Cygwin's gpg proved that the keyring's and the passphrase
are working.
Hence I concluded that it must be a problem of gpg 1.4.5