Xref: utzoo gnu.emacs.help:1521 comp.emacs:10369 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage From: darrylo@HPNMXX.HP.COM Newsgroups: gnu.emacs.help,comp.emacs Subject: Re: Compress Message-ID: <9103212300.AA16511@hpnmd.hp.com> Date: 21 Mar 91 22:52:53 GMT Sender: daemon@tut.cis.ohio-state.edu Followup-To: gnu.emacs.help Distribution: world Organization: Gatewayed from the GNU Project mailing list help-gnu-emacs@prep.ai.mit.edu Lines: 83 RMS says: > In my own work, I'm not going to install support for using compress as > long as it's something we can't safely use. Some people advise not > worrying about the issue, which means counting on it to be bypassed > before it becomes acute. But this seems risky and unwise to me. [ Normally, I'd keep my mouth shut, as (1) I like the FSF, (2) this topic doesn't belong here, and (3) I really don't have the time to write a reply. However, I can't pass this up. ] RMS says that we should not use compress. Well, that's fine, but we do not yet have a good replacement. Until the FSF releases "GNU file reduction" or whatever, people will continue to use compress, and they'll continue to use compress, and they'll continue to use compress, ad nauseam. This brings up a another "hot" topic: the "timelyness" of FSF software. I'm worried that the world will pass by the FSF. I'm sure that I am not alone when I say that I support the FSF, and that I really appreciate what they are doing. However, the incredibly slow rate of software development is nearly unbelievable (I like to think of it as "legendary"). I realize that part of the problem may be beyond the control of the FSF, but the two biggest offenders are GNU Emacs and Bash. Those people who follow the Bash saga will know what I'm talking about. I'm not trying to insult the developers of GNU Emacs or Bash -- I really appreciate what they are doing. However, I would appreciate it if the FSF would take MUCH MORE CARE with announcing schedules. It's very, super, incredibly, unbelievably annoying when a developer says that program "X" will be released in a couple of weeks, and then months, or even years, pass by. The developers of GNU Emacs have gotten better -- at least they are no longer giving out rough schedules. My favorite message is (NOTE THE DATE): ------------------------------------------------------------------------------- From rms@WHEATIES.AI.MIT.EDU Thu Sep 1 13:05:25 1988 From: rms@WHEATIES.AI.MIT.EDU (Richard Stallman) Date: Thu, 1 Sep 1988 20:05:25 GMT Subject: Emacs 18.52 available Newsgroups: comp.emacs Sender: daemon@eddie.MIT.EDU Lines: 11 Emacs 18.52 is now available on prep.ai.mit.edu in /u/emacs/edist.tar-18.52.Z. This file is around 4 meg. Compressed differences from 18.51 are in /u/emacs/diff-18.51-18.52.Z. They are 542000 bytes. This is the last release of Emacs I intend to make before version 19. The first test releases of version 19 will probably be in 6 to 9 months. Version 19 already has support for multiple X windows, per-buffer mouse commands, scroll bars, and European character sets. I don't know what other new features it will have. ------------------------------------------------------------------------------- *OVER* *FOUR* *YEARS* *AGO*, HP had an internal MULTI-WINDOW version of GNU Emacs V18.44, with scroll bars, etc., working under X10 (that's VERSION TEN of X-windows), and it was ported to X11. A year or two ago, Epoch appears (Epoch is better than HP's version, BTW). What's taking the FSF? If two independent groups can create a multi-window version of GNU Emacs, in a relatively short period of time, what is taking the FSF so long? Sure, making Emacs work on both X-windows and terminals is more work, but this doesn't account for the vast time differences. Given the quality of the existing FSF software, I can't believe that the FSF programmers are not as good as anyone else. What gives? Has the development stopped? -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.