9:31 p.m.
hi, all!
attached is a new version of allout.el and a ChangeLog for a
substantial new revision of allout, emacs' alternative (and much more
extensive) outliner. i
think it's ready to replace the distributed version. (i'm the
original author of allout, and the maintainer of the gnu emacs
version.) this version adds topic encryption, using GPG. it also
includes several fixes and enhancements, described in the ChangeLog
entry
i've tested this version mostly in gnu emacs, but have tested (and
adjusted) it enough to establish that it works in xemacs 21.4.17,
including the new encryption capabilities.
i'm providing the .el file instead of a patch against the version that
comes with xemacs 21.4.7 because the version there is old, and the
patch is substantially larger than the elisp source (5740 lines for
the new source vs 6680 for the unified diff). i can provide the diff
if you prefer, however.
one important thing to note. the gnu emacs folk made some cosmetic
but extensive stylistic changes, including particularly migrating the
function name prefix from "outline-" to "allout-", and i adopted
those
changes. i'm hoping it won't be disruptive to adopt those conventions
in the xemacs version, too. (i'd like to see allout continue to be
available from in both true emacs, but want to do what i can to
maintain only a single version...)
another important thing - the source i'm sending is slightly different
than the one i used to generate the patch i submitted to
emacs-devel(a)gnu.org earlier today. i discovered an xemacs
compatibility problem after submitting that version, which i fixed in
the version i'm sending to you. i can make sure to revise the patch i
submitted to the gnu list sooner rather than later, if you think
that's important.
please let me know whether or not i'm submitting this update the right way!
below is the synopsis of just the new encryption features, from the
ChangeLog entry.
- new subsystem supporting easy gpg topic encryption/decryption.
salient features:
- both public- and symmetric-key modes are supported.
- encryption being on a per-topic basis means you can
intersperse encrypted and clear-text data in a single file
to your heart's content.
- user-provided symmetric-key hints, with consistency
verification to help user avoid confusion
- time-limited key reuse, a la (and using) mailcrypt's
mc-passwd-timeout
- write-file-hook and auto-save-hook activities to support auto
encryption of pending topics on save; provision to skip
currently-edited topic to avoid editing disturbance
topic encryption functionality depends on both mailcrypt and
crypt++ packages. (non-encryption allout functionality is not
disrupted if either mailcrypt or crypt++ are absent.)
`allout-toggle-current-subtree-encryption' is the central
routine.
there are a five new encryption customization variables:
- allout-topic-encryption-bullet
- allout-default-encryption-scheme
- allout-key-verifier-handling
- allout-key-hint-handling
- allout-encrypt-unencrypted-on-saves
topic encryption is included in mouse menu
docstring for `allout-toggle-current-subtree-encryption'
and customization variables provide detailed description.
ken manheimer
ken.manheimer(a)gmail.com
6:18 a.m.
>>>> "Ken" == Ken Manheimer
<ken.manheimer(a)gmail.com> writes:
Ken> attached is a new version of allout.el
Great! Thank you for your submission; the format is perfect and the
detailed explanation very helpful.
Ken> and a ChangeLog for a substantial new revision of allout,
Ken> emacs' alternative (and much more extensive) outliner.
I notice that there is no Texinfo documentation in your submission.
If you have Texinfo documentation in the GNU Emacs distribution *we
cannot legally use it* without *specific* permission from the FSF
because the documentation license we inherited from Emacs 19 is
incompatible with the GFDL, and rms denied our request for a blanket
dual licensing.
Ken> i think it's ready to replace the distributed version.
By distributed version, you mean the original outline.el, not the
version of allout.el we have in our packages, right? I don't think
there's a hurry about this, so we'll probably spend a bit of time to
discuss changing the default.
When you say "ready to replace" do you mean
a) provides nearly full backward compatible UI plus extensions
or
b) it's so good users won't complain about the backward
incompatibility?
If the former, I'd certainly be in favor of replacement sooner rather
than later.
Ken> i can provide the diff if you prefer, however.
CVS will do that for us, no problem.
Ken> i adopted those changes. i'm hoping it won't be disruptive
Ken> to adopt those conventions in the xemacs version, too.
No problem. In fact, in such cases we prefer that.
Ken> (i'd like to see allout continue to be available from in both
Ken> true emacs, but want to do what i can to maintain only a
Ken> single version...)
If you're willing to spend a little extra effort, we can make you the
listed maintainer of that library and give you commit privilege in our
repository. Since it's a single file, you won't even need to deal
with the packaging infrastructure. Just copy the GNU version over the
version in your checkout of our edit-utils package, add a change log,
and send us a patch (patcher.el in the xemacs-devel package is very
helpful) including a note to Norbert stating whether you'd like this
released quickly or whether there is more work to come and he probably
should wait. Then commit (you can do that on your authority as the
listed maintainer), and we're synched. This also gives you a veto
over any changes _we_ might try to make to our version of the package.
For committers with review authority (XEmacs Review Board members and
listed maintainers of packages) we plan to eliminate the patch
requirement, since our automated CVS log (aka the xemacs-cvs mailing
list) already generates patches. We haven't worked that out quite
yet, but I hope soon.
You could also make the XEmacs repository the primary home of the
allout.el library if you wanted too, but if it's already in the GNU
Emacs distribution, it's much easier to synch from GNU to XEmacs than
the other way around.
Ken> i can make sure to revise the patch i submitted to the gnu
Ken> list sooner rather than later, if you think that's important.
I think that's an issue for you to coordinate with the GNU people.
The question is mostly your administrative effort in keeping the two
versions synched, it seems to me.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:32 p.m.
On 10/1/05, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
>>>>> "Ken" == Ken Manheimer
<ken.manheimer(a)gmail.com> writes:
Ken> attached is a new version of allout.el
Great! Thank you for your submission; the format is perfect and the
detailed explanation very helpful.
excellent.
Ken> and a ChangeLog for a substantial new revision of
allout,
Ken> emacs' alternative (and much more extensive) outliner.
I notice that there is no Texinfo documentation in your submission.
If you have Texinfo documentation in the GNU Emacs distribution *we
cannot legally use it* without *specific* permission from the FSF
because the documentation license we inherited from Emacs 19 is
incompatible with the GFDL, and rms denied our request for a blanket
dual licensing.
in fact, i have no texinfo documentation for allout. i'm not happy
about that, but i won't have time to change it any time soon. (i
would like to create an outline of notes about using allout, but doubt
it could get comprehensive any time soon.)
Ken> i think it's ready to replace the distributed
version.
By distributed version, you mean the original outline.el, not the
version of allout.el we have in our packages, right? I don't think
there's a hurry about this, so we'll probably spend a bit of time to
discuss changing the default.
actually, i was only thinking about replacement of the old allout.
though i wasn't suggesting it, i see no obstacle to replacing the
standard outline mode. i believe allout will handle standard emacs
outlines fine. and allout is not just a navigation tool, it's for
authoring outlines, including things like topic creation, promotion
and demotion, cut-and-paste, dynamic exposure during isearch, and lots
more. check the docstring for the allout-mode function for some
details.
When you say "ready to replace" do you mean
a) provides nearly full backward compatible UI plus extensions
i believe that allout will handle standard outlines with all the
functionality of the standard outliner - though i haven't looked at
the standard in a good while. (allout-mode is a minor mode, i see
that the standard outline mode now offers a major and a minor mode, at
least in gnu emacs.)
or
b) it's so good users won't complain about the backward
incompatibility?
i'm biased, but, yes, i think there's much to be preferred about
allout. the standard outline mode offers no authoring facility at
all. allout offers a credible range of features, with lots of nuances
that help you do what you want to do, and some downright wins that are
hard to do as nicely with anything else. (it also makes a fine
folding programming editor, when you set the topic prefix to a comment
in your programming language. to experience that, load allout, run
(allout-init), and then visit the file. if you have file variables
enabled you'll be able to navigate the allout code as an outline...)
If the former, I'd certainly be in favor of replacement sooner
rather
than later.
i'd be for it, too. it would love it if some folks could confirm that
they can get the encryption functionality going - it requires gpg,
crypt++, and mailcrypt, and the setup may require shaking out in other
environments than my own.
there's also an incidental development - the gnu folk are heading
towards adopting pgg, a replacement for mailcrypt, in their
distribution, and may arrange to have added an interface for
encrypting with symmetric keys. if that happens i'll probabl revise
allout to use pgg instead of the combination of crypt++ and mailcrypt.
dunno whether there's a reason for that to get settled before
instituting allout further.
[...]
If you're willing to spend a little extra effort, we can make you the
listed maintainer of that library and give you commit privilege in our
repository. Since it's a single file, you won't even need to deal
with the packaging infrastructure. Just copy the GNU version over the
version in your checkout of our edit-utils package, add a change log,
and send us a patch (patcher.el in the xemacs-devel package is very
helpful) including a note to Norbert stating whether you'd like this
released quickly or whether there is more work to come and he probably
should wait. Then commit (you can do that on your authority as the
listed maintainer), and we're synched. This also gives you a veto
over any changes _we_ might try to make to our version of the package.
i'd be happy to be the maintainer, with direct commit privileges. (do
you use cvs over ssh? if so, i'll need an account on some system...)
For committers with review authority (XEmacs Review Board members
and
listed maintainers of packages) we plan to eliminate the patch
requirement, since our automated CVS log (aka the xemacs-cvs mailing
list) already generates patches. We haven't worked that out quite
yet, but I hope soon.
generating and sending in an additional patch seems easy enough.
You could also make the XEmacs repository the primary home of the
allout.el library if you wanted too, but if it's already in the GNU
Emacs distribution, it's much easier to synch from GNU to XEmacs than
the other way around.
i'm comfortable copying it over as i go. i have a cvs repository of
my own, where i'll probably continue to develop the fine increments,
and then copy it over and check in to the xemacs repository when
substantial release points warrant.
Ken> i can make sure to revise the patch i submitted to the
gnu
Ken> list sooner rather than later, if you think that's important.
I think that's an issue for you to coordinate with the GNU people.
The question is mostly your administrative effort in keeping the two
versions synched, it seems to me.
i'm continuing to discover niggles ("wait, this is the last one...":-)
as i discuss it, so i think i'm going to be going back and forth a
bit. it seems like neither you guys nor the gnu folk are all too
uptight about it, and having commit privileges in your repository will
probably make the process easier. (i have a CVS copy of my own, which
is probably where i'll continue doing the smaller development
increments.)
and it so happens that i'm including a new version of the code which
has some autoload hints and use of key substitution strings in
docstrings, rather than literals for the keys. along with that is a
NEWS snippet, in case you guys use them (i suspect not, if the
packages are all handled independently of the main distribution) and a
more detailed ChangeLog entry, since the gnu folk wanted function-name
specifics and so forth...
ken
ken.manheimer(a)gmail.com
11:45 p.m.
* Ken Manheimer <ken.manheimer(a)gmail.com> writes:
it would love it if some folks could confirm that they can get
the encryption functionality going - it requires gpg, crypt++,
and mailcrypt, and the setup may require shaking out in other
environments than my own.
That doesn't sound too promising. The crypt++.el that I found on the
'net a little while ago had this final ChangeLog entry...
,----
| 2004-04-02 <karl(a)u20.cs.umb.edu>
|
| * crypt++.el is no longer supported. Use crypt.el from XEmacs
| instead.
`----
The crypt.el in XEmacs packages is _very_ old and I don't think it
handles gpg very well (it is supposed to, but I'm pretty sure it's
broke).
And, from what I hear, it is very tricky and hairy to get crypt++ to
play nice when you want it for gpg encryption/decryption only, and not
for tar.gz stuff. Interesting comment in crypt.el...
,----
| ;;; NOTE: Apparently not being maintained by the author, who now
| ;;; uses jka-compr.el. --ben (1/26/96)
`----
there's also an incidental development - the gnu folk are
heading
towards adopting pgg,
A good move. PGG has been part of the XEmacs packages for quite some
time now and the Gnus XEmacs package has used it for just as long. :-)
i'd be happy to be the maintainer, with direct commit privileges.
(do
you use cvs over ssh? if so, i'll need an account on some system...)
Norbert Koch <viteno(a)xemacs.org> is the man to speak to about setting
it all up. I'm sure he'll be in touch.
i'm continuing to discover niggles ("wait, this is the last
one...":-)
I have a "niggle" :-) ...
(defun my-mark-marker (&optional force buffer)
"Accommodate the different signature for `mark-marker' across Emacsen.
XEmacs takes two optional args, while mainline GNU Emacs does not,
so pass them along when appropriate."
(if (string-match " XEmacs " emacs-version)
(mark-marker force buffer)
(mark-marker)))
I'd like to see that written as...
(defun allout-mark-marker (&optional force buffer)
"Accommodate the different signature for `mark-marker' across Emacsen.
XEmacs takes two optional args, while mainline GNU Emacs does not,
so pass them along when appropriate."
(if running-xemacs
(mark-marker force buffer)
(mark-marker)))
,----[ C-h v running-xemacs RET ]
| `running-xemacs' is a variable declared in Lisp.
|
| Value: t
|
| Documentation:
| Non-nil when the current emacs is XEmacs or SXEmacs.
`----
The value of the variable `emacs-version' might change one day,
whereas `running-xemacs' will _always_ be `t'. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve(a)sxemacs.org>---|
12:02 a.m.
On 10/2/05, Steve Youngs <steve(a)sxemacs.org> wrote:
* Ken Manheimer <ken.manheimer(a)gmail.com> writes:
> i'd be happy to be the maintainer, with direct commit
privileges. (do
> you use cvs over ssh? if so, i'll need an account on some system...)
Norbert Koch <viteno(a)xemacs.org> is the man to speak to about setting
it all up. I'm sure he'll be in touch.
haven't heard from him, but i'll post my revisions to xemacs patches
sometime next week, and reopen the issue of applying the changes
directly.
> i'm continuing to discover niggles ("wait, this is
the last one...":-)
I have a "niggle" :-) ...
(defun my-mark-marker (&optional force buffer)
"Accommodate the different signature for `mark-marker' across Emacsen.
XEmacs takes two optional args, while mainline GNU Emacs does not,
so pass them along when appropriate."
(if (string-match " XEmacs " emacs-version)
(mark-marker force buffer)
(mark-marker)))
I'd like to see that written as...
(defun allout-mark-marker (&optional force buffer)
"Accommodate the different signature for `mark-marker' across Emacsen.
XEmacs takes two optional args, while mainline GNU Emacs does not,
so pass them along when appropriate."
(if running-xemacs
(mark-marker force buffer)
(mark-marker)))
,----[ C-h v running-xemacs RET ]
| `running-xemacs' is a variable declared in Lisp.
|
| Value: t
|
| Documentation:
| Non-nil when the current emacs is XEmacs or SXEmacs.
`----
The value of the variable `emacs-version' might change one day,
whereas `running-xemacs' will _always_ be `t'. :-)
but it's not defined at all in gnu emacs, which makes for a very
limited compatibility provision...-)
i see recommendations for: (featurep 'xemacs)
i'll switch to that.
thanks for the hints!
ken
ken.manheimer(a)gmail.com
3:27 p.m.
here's an update on the status of my allout changes.
i have revised my new version of allout so the new encryption features
depend on pgg rather than mailcrypt/crypt++. it is a revised version
of pgg, however, based on a combination of patches developed by me and
a fellow named sascha wilde. all the pgg attention has also
precipitated a move of pgg out of the gnus package to be a package in
its own right. all that is happening in the gnu.org repository, but
pending copyright assignment for the pgg patches from me and sascha.
(i already have allout copyright assignment on file, from long ago.)
i'm sending the copyright assignment form in, now.
i'm not attaching here any patches, ChangeLog excerpts, or NEWS
entries here, figuring the xemacs changes can follow from changes in
the gnu.org repository - and that i may be executing the revisions for
allout, if i get committer privileges (haven't heard anything from
norbert koch). i won't be in a position to handle the application of
the pgg revisions, though - don't want to take on maintenance of
that...
seems like it'll be a bit of a dance to get all the adjustments in
place - allout, pgg revisions and resituation out of gnus, and
reflection between the gnu.org and xemacs repositories, which is why
i'm posting this heads-up...
ken
ken.manheimer(a)gmail.com
On 9/30/05, Ken Manheimer <ken.manheimer(a)gmail.com> wrote:
hi, all!
attached is a new version of allout.el and a ChangeLog for a
substantial new revision of allout, emacs' alternative (and much more
extensive) outliner. i
think it's ready to replace the distributed version. (i'm the
original author of allout, and the maintainer of the gnu emacs
version.) this version adds topic encryption, using GPG. it also
includes several fixes and enhancements, described in the ChangeLog
entry
i've tested this version mostly in gnu emacs, but have tested (and
adjusted) it enough to establish that it works in xemacs 21.4.17,
including the new encryption capabilities.
i'm providing the .el file instead of a patch against the version that
comes with xemacs 21.4.7 because the version there is old, and the
patch is substantially larger than the elisp source (5740 lines for
the new source vs 6680 for the unified diff). i can provide the diff
if you prefer, however.
one important thing to note. the gnu emacs folk made some cosmetic
but extensive stylistic changes, including particularly migrating the
function name prefix from "outline-" to "allout-", and i adopted
those
changes. i'm hoping it won't be disruptive to adopt those conventions
in the xemacs version, too. (i'd like to see allout continue to be
available from in both true emacs, but want to do what i can to
maintain only a single version...)
another important thing - the source i'm sending is slightly different
than the one i used to generate the patch i submitted to
emacs-devel(a)gnu.org earlier today. i discovered an xemacs
compatibility problem after submitting that version, which i fixed in
the version i'm sending to you. i can make sure to revise the patch i
submitted to the gnu list sooner rather than later, if you think
that's important.
please let me know whether or not i'm submitting this update the right way!
below is the synopsis of just the new encryption features, from the
ChangeLog entry.
- new subsystem supporting easy gpg topic encryption/decryption.
salient features:
- both public- and symmetric-key modes are supported.
- encryption being on a per-topic basis means you can
intersperse encrypted and clear-text data in a single file
to your heart's content.
- user-provided symmetric-key hints, with consistency
verification to help user avoid confusion
- time-limited key reuse, a la (and using) mailcrypt's
mc-passwd-timeout
- write-file-hook and auto-save-hook activities to support auto
encryption of pending topics on save; provision to skip
currently-edited topic to avoid editing disturbance
topic encryption functionality depends on both mailcrypt and
crypt++ packages. (non-encryption allout functionality is not
disrupted if either mailcrypt or crypt++ are absent.)
`allout-toggle-current-subtree-encryption' is the central
routine.
there are a five new encryption customization variables:
- allout-topic-encryption-bullet
- allout-default-encryption-scheme
- allout-key-verifier-handling
- allout-key-hint-handling
- allout-encrypt-unencrypted-on-saves
topic encryption is included in mouse menu
docstring for `allout-toggle-current-subtree-encryption'
and customization variables provide detailed description.
ken manheimer
ken.manheimer(a)gmail.com
10:42 p.m.
* Ken Manheimer <ken.manheimer(a)gmail.com> writes:
here's an update on the status of my allout changes.
i have revised my new version of allout so the new encryption features
depend on pgg rather than mailcrypt/crypt++. it is a revised version
of pgg, however, based on a combination of patches developed by me and
a fellow named sascha wilde.
Cool! Does Simon Josefsson <simon(a)josefsson.org> have these patches?
He's the XEmacs PGG package maintainer.
all the pgg attention has also precipitated a move of pgg out of
the gnus package to be a package in its own right.
PGG has been a package in its own right with XEmacs packages ever
since the code was introduced about 3 years ago.
and that i may be executing the revisions for allout, if i get
committer privileges (haven't heard anything from norbert koch).
Yo, Norbert!
Ken, Norbert will need your SSH public key (version 2 I think is
preferred, but version 1 should be OK too), and your preferred userid
(for CVS logging purposes).
i won't be in a position to handle the application of the pgg
revisions, though - don't want to take on maintenance of that...
That's cool. We already have a PGG maintainer. :-)
seems like it'll be a bit of a dance to get all the adjustments
in
place - allout, pgg revisions and resituation out of gnus, and
reflection between the gnu.org and xemacs repositories, which is why
i'm posting this heads-up...
Appreciated.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve(a)sxemacs.org>---|
midnight
Ken Manheimer <ken.manheimer(a)gmail.com> writes:
here's an update on the status of my allout changes.
i have revised my new version of allout so the new encryption features
depend on pgg rather than mailcrypt/crypt++. it is a revised version
of pgg, however, based on a combination of patches developed by me and
a fellow named sascha wilde. all the pgg attention has also
precipitated a move of pgg out of the gnus package to be a package in
its own right. all that is happening in the gnu.org repository, but
pending copyright assignment for the pgg patches from me and sascha.
(i already have allout copyright assignment on file, from long ago.)
i'm sending the copyright assignment form in, now.
i'm not attaching here any patches, ChangeLog excerpts, or NEWS
entries here, figuring the xemacs changes can follow from changes in
the gnu.org repository - and that i may be executing the revisions for
allout, if i get committer privileges (haven't heard anything from
norbert koch). i won't be in a position to handle the application of
Hello Ken,
please see 3. under
http://www.xemacs.org/Develop/cvsaccess.html#committers
Mailing cvs-manager(a)xemacs.org should give you fastest service with
CVS issues.
Best regards,
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7002
days inactive
7022
days old
7 comments
4 participants
participants (4)
-
Adrian Aichner -
Ken Manheimer -
Stephen J. Turnbull -
Steve Youngs