emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two errors in 27.* with Windows


From: Juan José García-Ripoll
Subject: Re: Two errors in 27.* with Windows
Date: Thu, 26 Mar 2020 20:01:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:
> Please report each problem separately using "M-x report-emacs-bug".
> That will allow to deal with each one in a separate thread.  Also, the
> bug tracker is the proper place for discussing bugs and looking for
> their solutions.

Sorry, being so close to release I wasn't sure whether that would be the
right place.

> What does gpg.exe output in this case?  Does it output human-readable
> text, or does it output binary byte stream?  If the latter, how come
> ^M corruption is an issue?

The problem is not gpg's output. That is parsed properly if I invoke
epg's routines before Gnus: they are parsed in a text buffer (not
binary) and the version number is identified (x.x.x). The problem is
that, because package.el now does not trigger the identification of gpg,
this happens in a binary buffer. The routines parse the output
correctly, but the protocols, version numbers and everything else get
parsed with an ending ^M -> "x.x.x^M" which breaks the identification of
version number. If I run epg-find-configuration _after_ or _before_
Gnus, the parsing is done in a text buffer and the ^M is not
appended. Everything is fine. I am unable to find where the switch from
'nil to 'binary happens in the new code.

Hope this is clear. I will report the bugs separately later on.

Cheers,

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es




reply via email to

[Prev in Thread] Current Thread [Next in Thread]