Re: pgg-gpg.el - pgg-gpg-process-region timing problem

[ken manheimer]

i've got some more datapoints, and they suggest that i'm experiencing
a local OS installation/incidentals problem.

first, as suggested by yidong, i've tested and reproduced the problemi
identically in an emacs 22 build from a CVS EMACS_22_2 tagged
checkout.  i need not refer to anything external but my pggprob.el
tester.  (i also noticed that i the first attempt in each session to
evoke the error does not demonstrate the problem.  it only shows on
the second and subsequent tries.)

conversely, i am unable to reproduce the problem on any other hosts
with much of my operating environment, but various instances of emacs
22 and 23 and different OS and gpg installations (including gentoo
under vmware, rhel 4, fedora 1).  in general there are too many
variables to draw any conclusions, unfortunately, but it's important
info.

all this kinda explains why i haven't heard any complaints from any
other allout encrypted-topics users, and why i may be unlikely to hear
such.  i still don't know what it is about my system that's causing
the problem.
-- 
ken
http://myriadicity.net

On Fri, Jun 27, 2008 at 10:01 AM, ken manheimer <address@hidden> wrote:
> [i've removed emacs-pretest-bug@ from the recipients - it was my
> mistake to continue to cc that address in my correspondence about this
> problem...]
>
> On Thu, Jun 26, 2008 at 12:32 PM, Chong Yidong <address@hidden> wrote:
>
>>> i am not sure how to proceed with this problem.  as demonstrated by
>>> the pggprob.el script, i consistently get encryption and decryption
>>> problems without the contrived delay in my pgg-gpg-process-region
>>> patch.  (the problem does not happen if i just do a regular
>>> pgg-decrypt - i think the crucial thing is that a symmetric passphrase
>>> is being passed into pgg-gpg-process-region.)
>>
>> Here's one suggestion, though I don't know how useful it is: if it's
>> possible to run the same or similar version of pgg in Emacs 22, you
>> could and see if it appears there.  If not, we could narrow the problem
>> down to a change in Emacs' process code during Emacs 23 (though OTOH I
>> don't know of any that could lead to this).
>
> this is certainly worth trying.
>
> it brings me to a feeble question - is there a stable CVS tag for
> checkout of the currently released emacs version?  i see MAIN and
> EMACS_22_BASE, neither of which is very descriptive.  (MAIN is too
> generic to draw any conclusions, and EMACS_22_BASE sounds like
> something that is built upon, not a destination in itself.)  have i
> missed one?
>
> (i know this is a digression, but i feel lost in a twisty maze of
> passages, trying to find an authoritative listing of the most
> significant emacs CVS repository tags.  i couldn't find anything in
> the emacs project site on savannah or in the emacs wiki.  seems like
> it would be useful to have such a listing associated with the
> project!)
> --
> ken
> http://myriadicity.net