emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: existing work on TODO items


From: Ken Manheimer
Subject: Re: existing work on TODO items
Date: Thu, 12 Jan 2006 19:53:45 -0500

i missed the example until your recent message.  as far as i can tell,
the problem you're describing is one of configuration management -
it's the versions of the stuff you're using.  we need to guard against
that - but claiming that it "just doesn't work" is unnecessarily
incindiary!  specifics below...

On 1/9/06, Dave Love <address@hidden> wrote:
> Ken Manheimer <address@hidden> writes:
>
> > it would be helpful to me to find out how to repeat that bug, so i
> > could repair it.
>
> Find allout.el, go to the first heading (e.g. with the menu), use
> Headings -> Toggle Topic Encryption from the menu, type `foo' as
> passphrase and `bar' as the hint to get:
>
>   ;;;_~* Provide
>   -----BEGIN PGP MESSAGE-----
>   Version: GnuPG v1.4.1 (GNU/Linux)
>
>   jA0EAwMC4k9RaxuRboJgyRabxt2CW0in+vaRHnZ6jysmkDfz1KQ7
>   =TImu
>   -----END PGP MESSAGE-----
>
> Use the toggle menu item again, and entering `foo' as the passphrase,
> it says `Passphrase differs from established' and fails to decrypt
> when I try again.  I did that test in Emacs 21 on Debian stable(-ish),
> `gpg (GnuPG) 1.4.1'.  It was the same when I originally tried with the
> development Emacs on Debian testing.

i did this in emacs 22.0.50, with no problems.

i tried to do it in emacs 21.4.1 with a special version of allout, and
was refused due to the version of pgg.

i tried it in that same 21.4.1 but added the load path for the new
version of pgg, and it worked fine.

i certainly can't control every aspect of the environment.  perhaps i
can add something that refuses to do the encryption operations with
versions of pgg prior to some proven-ok one.  i wish you would qualify
your objections a bit more carefully, though - i thought this new
version of allout was targeted solely to the new version of emacs!

> > it defaults to using symmetric-mode encoding.  describe-key (`C-h k
> > C-c x') will tell you that a single universal argument (ie, C-u) will
> > use key-pair encryption, and a doubled universal argument will do the
> > symmetric-mode encryption but disregard the cache.
>
> Oh.  I hadn't examined the keymap, but C-c x is reserved for users
> according to the Lisp manual.  `allout-passphrase-verifier-handling'
> appeared to be documented as controlling the behaviour.

several people have mentioned this.  i'm trying to figure out what
best to do - but do note that the standard outline-mode uses \C-c
bindings, also.  (i will probably make the key prefix a customizable
setting and default it to something not \C-c, but need to find out
whether the outline-mode precedent justifies leaving it the way it
is.)

> >> with non-ASCII, potentially also causing data loss, though I don't
> >> know what's actually done.
> >
> > this is something i need to understand better.  it's a responsibility
> > of the pgg routines, but my changes may have left that off.
>
> No.  What, say, pgg-encode tries to do for an interactive call (which
> is tested wrongly) can lead to data loss anyway since it doesn't check
> that it's valid.  Check that with handa, since people accept what he
> says.

could you spell out the details a bit here?  i'm losing track of your
prepositions - "since it doesn't check that it's valid" - what the
heck (pardon my french) does the second "it" refer to?

> > allout doesn't handle whitespace-delimited outlines.  (i also have an
> > unreleased minor-mode block-wise outlining package - outdent.el -
> > which i use for python programming.)  i don't know about the outline
> > variables that major modes set.  can you tell me about them?
>
> See python.el for the example.  If it's not done in the installed
> version, try <URL:http://www.loveshack.ukfsn.org/emacs/python.el>.  I
> don't recall if I contributed that for the old python-mode.el, but I
> couldn't get even the bugs in that fixed for use with Emacs.
>
> > i agree.  there are some provisions of which you might not be aware -
> > the allout-mode function has substantial documentation,
>
> I don't understand why the help text for allout-mode looks different
> from what I remember before, but I don't have time or inclination to
> understand it all, I'm afraid.  This was just an aside.

i don't mean to waste your time.  you're raising serious objections,
though, and i'm trying to address them.  i expect it will not be hard
to have allout refuse to do encryption with pgg versions prior to some
reasonable baseline.  i would love to get the attention of People Who
Know to pgg, to iron out whatever coding-system flaws there are.

ken manheimer
address@hidden




reply via email to

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