Re: existing work on TODO items

[Dave Love]

"Richard M. Stallman" <address@hidden> writes:

> Could you please be more specific?  I never knew all that much about
> allout.  All I know is that it does a more powerful kind of outlining.

I never figured it out either, especially compared with Hyperbole's
outliner (or Org).  Then when I actually tried it to investigate, I
found it wouldn't actually run as then installed, which suggests it's
not actually used.  [Shouldn't packages be required to compile cleanly
when they're installed -- there was at least macro use before
definition -- and be clean for Checkdoc?  Not that Allout is atypical
that way.]

> Oh, I see allout.el was changed to use pgg.el, which was also used by
> Gnus.  Is that the change you are criticizing?

No; I didn't realize it had been changed to use the internal support.
Originally it was updated using external libraries to do this
encryption task (which have fundamental problems).  That's what I
meant.  Now there seems to have been a lot of work done on pgg for
this during some sort of non-freeze, but not for the general facility
in TODO.  I don't understand this.

I didn't mean to single out allout or denigrate contributions.  The
basic point is that development badly needs to stabilize, fix all the
problems, and make a release.  It looks worse than the Emacs 21
non-freeze, which I hoped would have shown what to avoid at least.

> Well, it is another outliner, so it would need to include the basic
> functionality of outlines.  Are you saying that it could use
> outline.el instead of duplicate it?

Or replace it, if was a superset.  It turns out it isn't, though.

> It would be good to make that change, after the release--if it really
> results in an improvement.  Sometimes duplicating code makes
> maintenance harder, and sometimes it makes maintenance easier.

Sure, but mostly the latter.  Just the code size (1/4 MB of allout)
must be significant.  It's not just maintenance, though; it affects
interactive and programmatic users too.  For instance, if allout was
built on outline, it would be obvious to us that it was at least a
superset, and there would be mode-specific support which doesn't seem
to have been programmed for allout.  It can't be good to have a lot of
duplicated work (languishing unreleased anyway) while more fundamental
generally-useful things aren't addressed and bugs don't get fixed.

Here's another example I noticed that will have an effect in future.
cc-subword.el is something of a kludge and apparently meant just for
C-like modes for some reason.  On the other hand, I installed a clean,
general minor mode for that job (cap-words.el) three years ago using
handa's moribund work in the emacs-unicode branch.  (See commentary in
python.el about not doing that sort of thing like the old python-mode
did.)  Even if the relevant bit of emacs-unicode couldn't be brought
to life, someone could presumably have mode
`word-separating-categories' work for ASCII, or at least have produced
a minor mode more-or-less compatible with cap-words and separate from
CC mode.  It's similar with all the advice that's been installed
against the previous policy rather than adding necessary hooks.

I don't want to lecture, and obviously I understand the realities of
maintenance, but sadly things just look out of control.  Someone
should say so, for the sake of us users getting facilities as well as
what can't be good PR for GNU.