On 10/1/05, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
>>>>> "Ken" == Ken Manheimer
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
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
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
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
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.)
b) it's so good users won't complain about the backward
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
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
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
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
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...