What is the status of 21.5?

[SL Baur]

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?
</flame>

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
> support.

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
> with.

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
anyway.

>  > > 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
> SUGGESTs.

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
you.

-sb