Re: What is the status of 21.5?
SL Baur writes:
> 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?
This is your cue, guys!
> I don't see how you can say that GTK'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?
Yes.
If I were in charge, I would never ask a volunteer to take over that
code,
Not a problem. Malcolm is Australian. :-)
besides, I don't like Gnome and I'd rather have Qt anyway.
cvs co -r DEV_QT
Also Bill Perry's work.
I think the misguided interface change of forcing line & column
display
on the modeline by default may have something to do with that.
I don't think so. Point doesn't move for the most horribly annoyingly
slow operations like fontlock. Worth testing, patches welcome.
> 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.
Er, that takes us back to Epoch AFAIK. The stack of extents code is
ancient and hairy (AIUI, this is the infamous code that rms couldn't
understand); without Ben we will have to deal with it in any 21.6
release. (I could be wrong, but in the spirit of a quick cut at
what's feasible for a potential 21.6 release.)
> Again, I disagree. [bootstrap packages/sumo in source is] 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?
No. We need a person with a bit of time, but it's totally independent
of everything else, so not hard to delegate or test.
OK, so we don't support that, or we fork the modes involved.
Heh. Good luck telling DAK that! :-)
> 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?
Because it's a long-standing problem that (a) GNU had too and (b) not
so many people ran into. That was then, this is now: all the Linux
distros are defaulting to *.UTF-8 locales. We must do a better job of
dealing with Han breakage and latin-unity. In a 21.6 release, the
work that Aidan's been doing will be useful.
> 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?
No, but all the distro packagers know about it. Gentoo, it doesn't
matter much, but SuSE, Debian, and Red Hat would take advantage of it.
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.
AFAIK the main stuff there is coding detection. Better Unicode
support, well, current 21.5 is a net win according to SuSE at least,
and of course to Windows users who need I18N.
Dump whatever garbage you can, Steve-san. Get a 21.5 released,
Not my decision. xemacs-review is that-a-way, guy. -> -> -> -> ->
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta