Thanks very much for working on the coding-system related
bug. Unfortunately, with the attached test file, it still
fails. I've attached my test file; it's encoded with
mule-utf-8, I'm using GNU Emacs 22.0.50.1 (i486-pc-linux-gnu,
GTK+ Version 2.8.20) of 2006-10-23 on pacem, modified by Debian.
Any pgg hackers with a clue on this?
David
"Ken Manheimer" <address@hidden> writes:
> 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.
>
>
--
David D. Smith
Test Text
//_. Encrypt This
筆は剣より強い。
allout.el