[Top][All Lists]

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

Re: allout encryption and non-ascii characters

From: Ken Manheimer
Subject: Re: allout encryption and non-ascii characters
Date: Mon, 6 Nov 2006 10:56:18 -0500

though i haven't heard that anyone else has tested it, i would hate
for this allout patch to miss the release, and am confident enough
about its merits to ask that it be applied.

the crucial thing the patch does is enable topic encryption of
non-ascii encodings.  the encoding fix is only a few lines, but the
patch also eliminates a tradeoff in the last fix i submitted,
clarifies a variable name and some docstrings in the process, and
rectifies some assorted boundary-condition behaviors, as well.

2006-11-05  Ken Manheimer  <address@hidden>

        * allout.el (allout-doublecheck-at-and-shallower): Clarify
        (allout-inhibit-aberrance-doublecheck): Rename from
        (allout-do-doublecheck): Track allout-inhibit-aberrance-doublecheck
        name change.
        (allout-ascend): Provide for unusual case where some topic after
        the first in file is at lower depth than the first.
        (allout-shift-in): Ensure the offspring of the new containing
        topic are exposed.
        (allout-encrypt-string): Preserve the coding-system of the text,
        according to that of the containing buffer.

On 11/4/06, Ken Manheimer <address@hidden> wrote:
i have had some success with getting allout topic encryption to
encrypt text so that characters in an alternate coding set are
preserved.  i am looking for people to test it - i am so unfamiliar
with coding sets in general that i don't really know how to be sure it
works generally!  (i am excited, though, that i was able to round-trip
some text with an elaborate <'> apostrophe that isn't preserved in the
ascii character set, but is preserved in iso-2022-7bit.)

i'm attaching a full copy of the revised allout.el for testing - make
sure you're not getting byte code from an old version when giving it a
go.  and when you do test it, be sure that the file you're working
with has a coding set which preserves the characters on rereading -
the encryption depends on the buffer being in the right coding set.

let me know whether or not it works for you, and if possible, the
coding set of the trial ('Esc-x buffer-file-coding-set' will tell
you).  if i get good confirmation that this works, i'll submit a
proper patch.


On 11/1/06, Ken Manheimer <address@hidden> wrote:
> allout's use of pgg for encryption doesn't provide for non-ascii text,
> and encoding is a realm where i seem to have less than zero
> cluefulness.  can anyone help me solve the problem posed below?
> ken
> On 11/1/06, an david smith wrote:
> > Hi Ken,
> >
> > I've been an allout user for a very long time. It's wonderful
> > software. Thank you.
> >
> > Today I thought I'd try out the encryption support as I finally
> > have a need for it but it doesn't properly handle non-ascii
> > characters. pgg-output-buffer is created inside of pgg-gpg with
> > mode of raw-text or binary and that is never converted back
> > into the charset of the original cleartext. I do a lot of work
> > in Japanese and so this is critical.
> >
> > I look at how gnus uses pgg and its charset handling but even
> > in edebug I couldn't quite see how it was doing it correctly
> > compared to how allout's method.
> >
> > If you have any insight I would really appreciate it. I will
> > try to debug this in my own time but as you are the
> > maintainer/author of the software involved, I hope you can at
> > least nudge in me the right direction towards a fix.

Attachment: ChangeLog-entry.txt
Description: Text document

Attachment: allout-patch.txt
Description: Text document

reply via email to

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