"Richard M. Stallman" <[EMAIL PROTECTED]> 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. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
