Re: existing work on TODO items

[Ken Manheimer]

On 1/12/06, Dave Love <address@hidden> wrote:
> Ken Manheimer <address@hidden> writes:
>
> > the TODO item describes something that will provide
> > encryption/decryption at the granularity of the entire file.  i
> > already had that (in the form of an addon elisp package, i think it's
> > crypt++),
>
> Maybe you did, but most of us didn't.  Crypt++ will _not_ handle file
> encoding issues correctly (amongst other things).  Regardless of naïve
> attitudes about it, most of us don't live in an ASCII world.  [Also
> compare the extent of the changes to generalize jka-compr with
> crypt++.el]

I did not mean to suggest that we don't need standard whole-file
encryption, but the capability that allout intends to provide is
different.  If the implementation is flawed, I would like to fix it.

> > but i am finding allout's easy articulation of encrypted
> > _portions_ of a file, in the form of encrypted topics, to be as useful
> > as i hoped - way way more useful for  the kinds of things i need.
>
> Presumably it would be equally useful in Org mode, for instance.
> However, _what's installed just doesn't work_ as far as I can tell.
> If the example didn't get through, I'll send it again.

Ah, I see the example now.

I'll reply in that message.

> (I wrote the whole-file support for sharing files of password lists &c
> using public keys in a foolproof way that didn't require everyone use
> Emacs.  If I wanted multi-part data in the same file, I'd probably use
> MIME, which provides encoding information as well as potentially
> associating it with public keys via a recipients list.  In fact, I
> originally just used encrypted articles in Gnus.  I don't want to
> dictate how people work, but I don't want users to be screwed by not
> being able to recover their non-ASCII text, for instance.)

Thanks.

> By the way, check out
> <URL:http://www.loveshack.ukfsn.org/emacs/autocap.el>.

Ah.

ken
address@hidden