Re: allout encryption and non-ascii characters

[Ken Manheimer]

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.
--
ken
address@hidden
http://myriadicity.net

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

        * allout.el (allout-doublecheck-at-and-shallower): Clarify
        docstring.
        (allout-inhibit-aberrance-doublecheck): Rename from
        allout-during-yank-processing.
        (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.
>
> thanks!
>
> 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.

ChangeLog-entry.txt
Description: Text document

allout-patch.txt
Description: Text document