6:32 a.m.
The current Linux kernel development model appears to be a
lot more appropriate to base (stable) XEmacs releases on than the
former version.
So, what's left to sign off on a 21.5? (The 21.5 I built on Solaris
crashes immediately, but that may be an older long-standing bug).
Just as soon as I'm done building a full-featured XEmacs I'll take
another look at that.
FSF macs has gone on to v22. I suppose we ought to be aiming
for that too.
21.1.x is all the programming power in an editor I ever dreamed
of and by "modern" standards, we are no longer a heavy weight
application.
I want to see relational database support embedded (and I'm going
to work on PostgreSQL support, I think I'm going to have to have a
Linux box to sort all that out though, Mac OS X is great for playing
games but it leaves something to be desired in the development arena)
Inspire me. XEmacs is good! It must not die.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:13 p.m.
SL Baur writes:
So, what's left to sign off on a 21.5?
Oh, just about everything.
1. The long-standing bug in the progress gauge is still there; the
only way to be sure not to crash is to disable the widget.
2. Unicode support sucks.
3. Xft support sucks.
4. Carbon support isn't in the mainline yet.
5. Gtk is effectively unsupported (we still require v1).
6. The new GC sucks, at least RAM and CPU.
7. There are infloops or something like them in the regexp engine.
8. Fontlock is still way too slow, partly due to 7, partly due to 9.
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.)
10. comint needs GNU sync, but this is known to be hard, as we just
had to back out the last attempt.
11. We still don't have an all in one tarball.
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.
13. Mule coding systems suck, and autodetection needs a lot of tuning.
14. Modules don't really work right yet. I think we should go to a
model like Python's where .so's and .py's mix interchangably, but that
doesn't go with binary packages very well. Elisp eggs would be nice,
too (Google for "python eggs").
That's off the top of my head.
Inspire me. XEmacs is good! It must not die.
Do your PostgreSQL support. I don't know about "one true way"; MySQL
at least is still way popular in the webapp end of the world. But
more SQL support would be a good thing.
I have a few desiderata, I've got libneon and libcurl added as modules
in a private workspace, and I'd like to see libsvg and expat or libxml
supported as modules. We also need to do something with git, which is
just LISP in C clothing. It is just dying to be given LISP bindings.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:30 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
SL Baur writes:
> So, what's left to sign off on a 21.5?
Oh, just about everything.
[...]
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.
Hm? There is a working AUCTeX+preview-latex package from the AUCTeX
site for XEmacs. The main problem here is XEmacs package policies.
Yes, there are shortcomings in AUCTeX+preview-latex for XEmacs, but
the image API is nothing that would strike me as relevant: there are
bug workarounds (some of them rather ridiculous) in place for pretty
every problem. Functionally, the main shortcoming is that it is
impossible to place the cursor _on_ an image: it has to be before or
after it.
Much more important are shortcomings in font lock mode and line
wrapping. Here basically a synch to Emacs 22 would be the sanest
thing to do.
We also need to do something with git, which is just LISP in C
clothing.
Hm?
It is just dying to be given LISP bindings.
contrib/emacs/git.el in the git distribution and vc-git.el in Emacs 22.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:20 a.m.
David Kastrup writes:
It is just dying to be given LISP bindings.
contrib/emacs/git.el in the git distribution and vc-git.el in Emacs 22.
Those aren't "bindings".
Do you mean you haven't realized that "git commit" is just "cons"
in a
tuxedo, and "git rebase" just
(lambda (node branch)
(setcdr (nthcdr branch (common-ancestor-index branch node)) node))
tsk tsk.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:48 p.m.
On 8/18/07, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
David Kastrup writes:
> It is just dying to be given LISP bindings.
>
> contrib/emacs/git.el in the git distribution and vc-git.el in Emacs 22.
Those aren't "bindings".
Do you mean you haven't realized that "git commit" is just "cons"
in a
tuxedo, and "git rebase" just
(lambda (node branch)
(setcdr (nthcdr branch (common-ancestor-index branch node)) node))
tsk tsk.
I was hoping that was what you meant. Kind of like the difference
between inferior SQL mode and my PostgreSQL binding. SQL
programming in Lisp rocks and so would dealing with an SCM.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:16 a.m.
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.
On 8/15/07, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
SL Baur writes:
> So, what's left to sign off on a 21.5?
Oh, just about everything.
1. The long-standing bug in the progress gauge is still there; the
only way to be sure not to crash is to disable the widget.
I've seen that it's annoying. Why not drop the patch until
it's fixed or turn off the feature.
2. Unicode support sucks.
That was a v22 item. Did you move it 21.5?
3. Xft support sucks.
No comment until I get a working X11 setup and/or Linux box
for testing.
4. Carbon support isn't in the mainline yet.
I'll pitch in there, but I wouldn't hold back 21.5 for it.
5. Gtk is effectively unsupported (we still require v1).
That's a problem I guess.
6. The new GC sucks, at least RAM and CPU.
That's a problem. I'll read the archives to see what
happened. Our tradition has been always a bit faster.
That way as hardware keeps up with the Microsoft
curve we're way faster.
7. There are infloops or something like them in the regexp engine.
O.K. That's a problem.
8. Fontlock is still way too slow, partly due to 7, partly due to 9.
Fontlock has always been slow. Is fastlock slow now?
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.
10. comint needs GNU sync, but this is known to be hard, as we just
had to back out the last attempt.
Yeah, I've noticed that they are diverging. I don't think that's a
good thing and unfortunately it is costing me a lot of time at
work.
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, but it shouldn't hold up an initial release.
The world is a lot different place than it was when I split things
up. Bandwidth isn't what it used to be and XEmacs is now a
pretty light weight application compared to what's now out there.
Just remember though that some people don't always want to
upgrade their packages. God got angry at us for that. (Is Dr.
McCarthy still an XEmacs user?)
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?
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.
14. Modules don't really work right yet. I think we should go to
a
model like Python's where .so's and .py's mix interchangably, but that
doesn't go with binary packages very well. Elisp eggs would be nice,
too (Google for "python eggs").
This 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.
Now, which of these are reversions and which are not?
> Inspire me. XEmacs is good! It must not die.
Do your PostgreSQL support. I don't know about "one true way"; MySQL
at least is still way popular in the webapp end of the world. But
more SQL support would be a good thing.
I'll need some kind of SQL back end, at least as a demo, for my forms
package. And it shouldn't take me that long to upgrade the build
to deal with more recent versions of PostgreSQL.
I have a few desiderata, I've got libneon and libcurl added as
modules
in a private workspace, and I'd like to see libsvg and expat or libxml
supported as modules. We also need to do something with git, which is
just LISP in C clothing. It is just dying to be given LISP bindings.
I've got git installed and working. Anything written/designed by Linus is
interesting. (The lack of) git bindings shouldn't hold up a release,
neither should the other things you've listed.
Release early, release often. Be ruthless. Drop everything that isn't
working properly, defer stuff that needs a lot more work. It doesn't
have to be perfect, it just has to be a bit better than the previous
version. The Japanese know this and so does Microsoft. Kaizen
works.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:34 a.m.
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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
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.
Just remember though that some people don't always want to
upgrade
their packages. God got angry at us for that. (Is Dr. McCarthy
still an XEmacs user?)
Dunno.
> 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.
> 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.
[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.
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.
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.
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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:32 a.m.
On 8/16/07, Stephen J. Turnbull <stephen(a)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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:24 a.m.
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
1:50 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> さんは書きました:
SL Baur writes:
> > 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.
Yes, I also think this is a long standing problem.
Data corruption when saving files in UTF-8 is a big problem in 21.4.x,
in 21.5.x it works far better.
Unicode support in 21.5.x certainly isn't perfect yet, but it has
improved a lot compared to 21.4.x.
I think the not yet perfect Unicode support is no reason to hold back a
release. As it is already far better than in the previous release, I
think as far as Unicode support is concerned, releasing a 21.6 with what
is available now is a good thing.
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:58 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
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'm all for it.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:24 p.m.
On 8/18/07, Michael Sperber <sperber(a)informatik.uni-tuebingen.de> wrote:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> 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'm all for it.
I, too, am strongly in favor of a 21.6 release as soon as possible.
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:34 p.m.
On 8/18/07, Vin Shelton <acs(a)alumni.princeton.edu> wrote:
On 8/18/07, Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> wrote:
>
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> > > OK. I'll float it again. Why not?
> >
> > This is your cue, guys!
>
> I'm all for it.
I, too, am strongly in favor of a 21.6 release as soon as possible.
Make it so, #1! But we'll wait until you're settled after your
move. How about Halloween XEmacs?
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:48 a.m.
SL Baur writes:
Make it so, #1! But we'll wait until you're settled after
your
move. How about Halloween XEmacs?
I'm philosophically opposed to me doing it. I'm too old and
crotchety. I can be drafted, it's a realistic choice I guess, but I
don't really think it's a great idea. It would be better if someone
with delusions of grandeur did it.
As for Halloween, IMO that's unrealistic. If we're going to do a
"with all the warts" release, let's shoot for (US) Labor Day for a
"gamma" announcement, just to remind us of how much work is left to
do. If we're going to try to fix some of the problems, I misdoubt
we'll still be deciding what to fix and what to document as a feature
around Halloween. (Although I guess 21.6.0 can be "Edward
Scissorhands" because it's more sorrow than horror, and then .1 can be
"Halloween" XEmacs, followed by "Freddy", "Jason", and
"Texas
Chainsaw" as the realization of what we've let loose on society starts
to sink in!)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:20 a.m.
On 8/19/07, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I'm philosophically opposed to me doing it. I'm too old and
crotchety. I can be drafted, it's a realistic choice I guess, but I
don't really think it's a great idea. It would be better if someone
with delusions of grandeur did it.
Hmm, a tin-plated dictator with delusions of grandeur? But no, Captain
that's not why I hit him. He called XEmacs 21.6 a garbage scow! And
that's when I hit him.
As for Halloween, IMO that's unrealistic. If we're going to
do a
"with all the warts" release, let's shoot for (US) Labor Day for a
"gamma" announcement, just to remind us of how much work is left to
do.
I'm going to be out of the country with my family that week.
If we're going to try to fix some of the problems, I misdoubt
we'll still be deciding what to fix and what to document as a feature
around Halloween. (Although I guess 21.6.0 can be "Edward
Scissorhands" because it's more sorrow than horror, and then .1 can be
"Halloween" XEmacs, followed by "Freddy", "Jason", and
"Texas
Chainsaw" as the realization of what we've let loose on society starts
to sink in!)
No, just call it "Vista".
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:02 a.m.
Stephen J. Turnbull wrote:
SL Baur writes:
> So, what's left to sign off on a 21.5?
Oh, just about everything.
[...]
14. [...]
That's off the top of my head.
15. I can't use it at all. Here's the warnings stack just after
launching it.
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:37 p.m.
Didier Verna writes:
15. I can't use it at all. Here's the warnings stack just
after
launching it.
You've got an image XEmacs doesn't like, so don't do that until the
bug gets fixed, maybe?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:41 p.m.
Stephen J. Turnbull wrote:
Didier Verna writes:
> 15. I can't use it at all. Here's the warnings stack just after
> launching it.
You've got an image XEmacs doesn't like, so don't do that until the
bug gets fixed, maybe?
Point is, 21.4 likes it very much :-) Seriously, I've tried to debug
it once, but fell short of time / internals understanding, and the bug
seems very profound.
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:57 p.m.
On 8/20/07, Didier Verna <didier(a)xemacs.org> wrote:
Stephen J. Turnbull wrote:
> You've got an image XEmacs doesn't like, so don't do
that until the
> bug gets fixed, maybe?
Point is, 21.4 likes it very much :-) Seriously, I've tried to debug
it once, but fell short of time / internals understanding, and the bug
seems very profound.
Can you link to the image so we can try to reproduce the problem?
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:59 p.m.
"SL Baur" <steve(a)xemacs.org> wrote:
On 8/20/07, Didier Verna <didier(a)xemacs.org> wrote:
> Stephen J. Turnbull wrote:
> > You've got an image XEmacs doesn't like, so don't do that until the
> > bug gets fixed, maybe?
>
> Point is, 21.4 likes it very much :-) Seriously, I've tried to debug
> it once, but fell short of time / internals understanding, and the bug
> seems very profound.
Can you link to the image so we can try to reproduce the problem?
Yup: http://www.lrde.epita.fr/~didier/marble.xpm
But I don't think this is related to the image itself. Last time I
checked, I was also getting problems with display-time in the modeline.
Besides, the problem was somewhat erratic (felt like GC problem).
In order to maximize the chances of reproduction, you should customize
your default face so that it uses the pixmap as soon as possible.
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:19 p.m.
Didier Verna writes:
Stephen J. Turnbull wrote:
> Didier Verna writes:
>
> > 15. I can't use it at all. Here's the warnings stack just after
> > launching it.
>
> You've got an image XEmacs doesn't like, so don't do that until the
> bug gets fixed, maybe?
Point is, 21.4 likes it very much :-)
Yah, but I quote you above. "I can't use [21.5] at all." You've been
saying *that* for years, now you tell us there's a particular image
you want to use for background?
You're an experienced user, we can use all the good bug reports we can
get, even if you have to do without your favorite backing image. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:41 p.m.
Stephen J. Turnbull wrote:
"I can't use [21.5] at all." You've been saying
*that* for years, now
you tell us there's a particular image you want to use for background?
What? I can't use 21.5 at all indeed, because the warnings buffer
keeps popping up, and if it's not with my background pixmap, it's gonna
be with display-time, and if not, with a message in Gnus from a user
that has a picon, or whatever else. And no, I'm not gonna spend one day
making a text-only configuration for XEmacs 21.5 and all related
packages. I'm better off using 21.4.
You're an experienced user, we can use all the good bug reports
we can
get,
It's not like if I hadn't properly reported this problem before, or
even tried to fix it myself. I even offered Ben Wing access to my
machine some years ago about this, at a time he popped up, did some
random stuff and disappeared again. But the time when I could spend days
debugging XEmacs and follow up with the development is unfortunately
over.
But you know my feeling about 21.5 in general, so please don't get me
started ;-)
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:31 p.m.
Ar an fichiú lá de mí Lúnasa, scríobh Didier Verna:
> That's off the top of my head.
15. I can't use it at all. Here's the warnings stack just after
launching it.
Could you do an M-x report-emacs-bug, or point me to one you’ve sent for
that build already? This call:
(set-face-background-pixmap 'default "~/xemacs-21.5/etc/trash.xpm" nil
'(custom))
works fine for me (insofar as anything that makes the frame as unreadable as
it does *can* work fine).
(1) (image/debug) error: (invalid-argument (Unable to interpret glyph
instantiator ~/share/images/tile/marble.xpm))
Backtrace follows:
# bind (inhibit-quit)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x84cd09c> ...)
# (unwind-protect ...)
add-spec-list-to-specifier(#<image-specifier global=<unspecified> 0x1f1d>
((global ((custom) . "~/share/images/tile/marble.xpm"))) nil)
# bind (is-valid nval how-to-add tag-set locale value specifier)
set-specifier(#<image-specifier global=<unspecified> 0x1f1d>
"~/share/images/tile/marble.xpm" nil (custom) nil)
# bind (how-to-add tag-set locale value property face)
set-face-property(default background-pixmap "~/share/images/tile/marble.xpm"
nil (custom) nil)
# bind (how-to-add tag-set locale pixmap face)
set-face-background-pixmap(default "~/share/images/tile/marble.xpm" nil
(custom))
funcall(set-face-background-pixmap default "~/share/images/tile/marble.xpm"
nil (custom))
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:27 p.m.
Steve (Baur):
I’d be happy if we released tomorrow. 21.4 isn’t good enough for everyday
usage in this world of UTF-8 and Windows, and a more recent version in the
distribution channels would make many people’s lives easier. That said, 21.5
is not great code, but I don’t see any prospect of that changing in the next
two years.
Ar an cúigiú lá déag de mí Lúnasa, scríobh Stephen J. Turnbull:
SL Baur writes:
> So, what's left to sign off on a 21.5?
Oh, just about everything.
1. The long-standing bug in the progress gauge is still there; the
only way to be sure not to crash is to disable the widget.
2. Unicode support sucks.
Optimistically, Unicode support is better than that of GNU (this wasn’t
true--except when it came to things like the programmer’s API to use
it--until my recent change to preserve invalid sequences on encoding and
decoding). We support all the Unicode code points on reading and writing,
for example, which they don’t. Unicode (and other character set) support for
input and redisplay under server-side X11 is good, and faster than that on
21.4 (fewer string matches when instantiating fonts).
Pessimistically, it does indeed suck. But I cannot imagine any universe in
which our next release has BiDi or normalisation or proper collation or
decomposition (especially in searches) or Unicode classes in regular
expressions or the rest of what really is a huge standard. So its suckage is
irrelevant to the next release.
3. Xft support sucks.
Optimistically; Xft support is in the mainline, and it’s in a better state
than was Win32 support at the time of the 21.4 release.
4. Carbon support isn't in the mainline yet.
Optimistically; putting it in the mainline is not hard. And I now have a Mac
Mini, but admittedly my XEmacs development priorities are elsewhere. I have
to say though that it brought a smile to my face that redisplay on Carbon
didn’t need any work for the JIT Unicode code points to appear correctly.
5. Gtk is effectively unsupported (we still require v1).
6. The new GC sucks, at least RAM and CPU.
Optimistically; we can turn it off as a default. People have more RAM than
when 21.4 was released, and the old GC with an increased gc-cons-threshold
will mean better performance for them.
Pessimistically; we’re leaking memory independent of the compiled-in GC
(memory that isn’t counted in our memory usage statistics). And on 64-bit
platforms a -vanilla startup is 40 MB for me, double the 20 MB on a 32-bit
machine and growing faster, since every Lisp variable has to take up at
least the size of a pointer in RAM; yes, that is inherent with the CPU, but
it does intensify the problem on a platform that’s becoming more common
every day.
7. There are infloops or something like them in the regexp engine.
8. Fontlock is still way too slow, partly due to 7, partly due to 9.
Font lock is algorithmically broken. Optimistically, GNU’s is better.
Pessimisticially, the last time I looked, merging was hard.
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.)
10. comint needs GNU sync, but this is known to be hard, as we just
had to back out the last attempt.
11. We still don't have an all in one tarball.
Optimistically, we have it on Windows, and the platform package systems make
its lack not a big issue on Unix.
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.
13. Mule coding systems suck, and autodetection needs a lot of tuning.
Autodetection’s not far off from being as good as it can be without
statistical analysis like the browsers do, and such analysis is really at
its most useful for plain text, not program (and TeX and HTML and whatever)
source code. I hate that we ignore so much metadata indicating what encoding
a file is saved in. Optimistically, GNU have a decent infrastructure for
looking at that metadata. Pessimistically, SJT argues against it without
providing a coherent alternative design or implementation, so merging it is
a lot of work.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)OB
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6303
days inactive
6309
days old
23 comments
8 participants
participants (8)
-
Aidan Kehoe -
David Kastrup -
Didier Verna -
Michael Sperber -
Mike FABIAN -
SL Baur -
Stephen J. Turnbull -
Vin Shelton