Re: What is the status of 21.5?

SL Baur writes: That's right. The stuff either needs to be fixed or come out. There's been nobody able and willing to do the fixing, and no support for amputation. Cf. "21.5 is not pre-21.6" below. 21.5 is pre-22, always has been. A release without decent Unicode support (including but not limited to Unicode internal encoding) is kind of meaningless at this point IMO. The idea of a 21.6 release, with bugfixes for "whatever we've got at the moment" has been floated a couple times, with absolutely no support. I would. A lot of people I want to pay back (you, jwz, mly, baw) have asked for it, and it has full support from all board members AFAIK. Choi has already basically done it, except for the poor support for non-Carbon consoles in a Carbon build. That's good enough to start with. I don't see how you can say that's a problem, but not be willing to hold a release for Carbon. Fontlock feels slower than ever before, despite faster hardware than ever before. Martin always said it should be possible to highlight a 1MB buffer in imperceptible time, and I really think that's true. But we can't do it, not even for a ChangeLog. Yes, and I think the SOE has to go. It's designed on the assumption that most movement will be local, which is true of interactive editing, but is not true of font-lock as currently implemented, which tends to charge back and forth across large regions of the buffer because it's defun-oriented. We already have it on Windows. Again, I disagree. It's just not that hard to do, and "why doesn't anything work" is still a FAQ (including on Windows, where the problem often seems to be the space in "Program Files"). The problem is just doing it. Dunno. Gerd Moellman, actually. According to David Kastrup, the GNU implementation sucked pretty bad for the whole 21.x series; I don't know if 22.1 is any better. There are some useful features, I guess, but they'll be ugly to implement, I suspect, because redisplay will need to be hacked. Well, really, that's what I'm talking about. The problem is that because the internal encoding is not Unicode, buffer I/O is full of ambiguities that just aren't possible to disentangle without help from the user. It's possible to make things work most of the time, but really robust support need Unicode inside. There's also a problem of silent data loss in many coding systems, which can't be fixed once and for all because they're all implemented as individual monolithic C functions. I have to differ on that. It's a very important feature to binary distro packages because they can demote a slew of library REQUIREs to SUGGESTs. I don't understand. Many of the problems are present in 21.4 and even 21.1 as Lisp gets more convoluted (especially with FSF compatibility, but also with features). But many are new with new stuff from Ben, Mike, and Marcus. I don't think there any any old features that have become significantly more buggy in 21.5, though. Building works fine, at least up to pg 8.1.x. Who be ruthless? In October 2000, everybody but Martin wanted a release, and we had a dozen people willing to back it up with substantial effort. Currently for practical purposes, the only developer active on 21.5 as a whole is Aidan, and for what it's worth I disagree with his priorities. If he were willing to be release manager, too, that wouldn't matter, but AFAIK he's not. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta