What is the status of 21.5?
steve at xemacs.org
Thu Aug 16 04:32:30 EDT 2007
On 8/16/07, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> SL Baur writes:
> > What's wrong with this picture? There's more stuff listed here
> > than the TODO list I inherited from Chuck after 19.14 that took
> > about 4 years to complete.
> 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.
Well, maybe it should be.
<flame=on target="Ben Wing">
Let's see, I was forced out of XEmacs development in 2000q1 because
there weren't enough releases going out. How many releases have been
made in the last (almost) seven years?
Please consider the idea of an XEmacs 21.6, Steve-san.
> > > 2. Unicode support sucks.
> > That was a v22 item. Did you move it 21.5?
> 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
OK. I'll float it again. Why not?
> > > 4. Carbon support isn't in the mainline yet.
> > I'll pitch in there, but I wouldn't hold back 21.5 for it.
> 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
I see. That's a good reason and Carbon deserves support from us.
We've always been Unix agnostic -- if you're Unix, we support you,
and the Macintrash whatever its other failings is Unix (and I'll admit
a personal reason - when I hand this over to my wife, I want it running a
graphical XEmacs downloadable from xemacs.org).
> > > 5. Gtk is effectively unsupported (we still require v1).
> > That's a problem I guess.
> I don't see how you can say that's a problem, but not be willing to
> hold a release for Carbon.
Yeah, I forgot to fix that. Didn't Bob finance the original GTK port?
If I were in charge, I would never ask a volunteer to take over that
code, besides, I don't like Gnome and I'd rather have Qt anyway.
Just drop it. All gtk does is SPAM the console with warning messages
> > > 8. Fontlock is still way too slow, partly due to 7, partly due to 9.
> > Fontlock has always been slow. Is fastlock slow now?
> 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.
I think the misguided interface change of forcing line & column display
on the modeline by default may have something to do with that. FSF
macs is *dead* slow at doing anything in buffers that size and that
didn't use to be true.
> > > 9. The stack of extents code is not robust to "large" extents, at
> > > least with Mule support. (Eg, putting an extent on (point-min),
> > > (point-max) will slow things very badly.)
> > That's a problem.
> 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.
OK, kill it or disable it or back the patches out until it's fixed.
> > > 11. We still don't have an all in one tarball.
> > Yeah, I read about this one. I have no objections so long as
> > Linux distro makers can still get separate core & Sumo tarballs
> > to make packages from. It's probably the right thing to do
> > on Microsoft Windows,
> We already have it on Windows.
Oh, I seem to have missed that last year when I tried my first ever (and
only!) Microsoft Windows install. Not a big deal for me.
> > but it shouldn't hold up an initial release.
> 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.
OK, so have someone fix it. Is that a problem?
> > > 12. AUCTeX and preview-latex support is a real issue for many
> > > people; it seems we can't do that without supporting more of the
> > > GNU image API.
> > Is this more Stallman crock, or did someone actually design it
> > for a change?
> 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.
Ugh. I was just recalling the hacking I had to do get Athena 3d
scrollbars (somewhat) working. The horror .... the horror ....
OK, so we don't support that, or we fork the modes involved.
> > > 13. Mule coding systems suck, and autodetection needs a lot of tuning.
> > O.K. How much do they suck, how many people are really
> > affected? Personally I would be more worried about proper UTF-8
> > support.
> 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.
This sounds like it's the long standing problem we've always had. So
why would this be a hold back to a 21.6?
> > [Modules] should not hold back 21.5. I was and am of the opinion
> > that this was a cool hack, but shouldn't ever be relied upon as a
> > core feature.
> 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
That sounds significant. Is it documented?
> > Now, which of these are reversions and which are not?
> 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.
Stuff that was a bug in 21.4 but still is a bug in 21.5 is not a reversion.
Stuff that was OK in 21.4 but doesn't work in 21.5 is a reversion.
> > And it shouldn't take me that long to upgrade the build to deal
> > with more recent versions of PostgreSQL.
> Building works fine, at least up to pg 8.1.x.
Oh, that's good to know. There are strange paths on the Mac,
I have to do some configure magic to get the right includes once I
get all the proper build tools installed. And I have 8.2, I'll have to
check whether that makes a difference.
> > Release early, release often. Be ruthless.
> 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.
Dump whatever garbage you can, Steve-san. Get a 21.5 released,
no matter how buggy you may think it is, ASAP[*]. We're years
late on a new release, but it's still not too late to start rebuilding.
Who did the final sign-off on 20.0? I did. It was a horrible, horrible
mistake in some sense, but good in others. Everybody seems to
forgive the inherent weakness of Microsoft Windows and I don't
think a slightly weak XEmacs will hurt us if we follow it up with
something a bit better a few months later.
[*] Yeah, I know you're moving. I'm not volunteering or trying to
take over, but I am volunteering to help you when you're local to
me again and Stanford is about as close to me as Inari-mae was to
More information about the XEmacs-Beta