outdated url-library: is XEmacs still the next generation of Emacs?

[Stephen J. Turnbull]

Aidan Kehoe writes:

 > Menus and Custom for Xft fonts is not helpful;

Of course it is, *if* we're going to ship a 21.6 any time soon.

 > Xft redisplay is never going to get good advanced text features
 > support (contextual shaping, bidi)

That may or may not be true.  Emacs has done substantial work on both.

 > All the coding systems I have had anything to do with have invertibility on
 > decoding.

I personally will probably never need any of those, though. ;-)

 > Invertibility on *encoding* would be too much of an API change,

But that's where most of the corruption happens.

 > and the #'query-coding-region support means that the corresponding
 > information is available anyway.

It isn't used in my experience, though.  I don't care if it's there in
principle, it's still way too easy to write applications that corrupt
text.  VM does it quite frequently, for example.

 > We should merge changes from Aquamacs into Carbon XEmacs, but Carbon XEmacs
 > is in a mild legal limbo. And we may end up forced to Cocoa anyway, as Apple
 > dropped support for Carbon on 64-bit platforms before release, which
 > strongly suggests they’re willing to drop Carbon entirely.

The scuttlebutt on Python-Dev is that Carbon GUI is a dead letter.
Certain internal APIs will be kept indefinitely, though.

 > We should fix the GUI generally, make it adhere to the conventions of the
 > major GUI platforms of today by default,

Again that is probably not doable in the time frame of a prospective 21.6.

 > That’s the first time I’ve seen the proposal for integrating bignum
 > support into buffer sizes giving us real large file support;

It's been around for a while, but tabled so hard the proposal bounced
and the tabletop cracked, because it's almost certainly way slow.

 > it’s eminently reasonable, and shouldn’t be too much work. (I’m
 > thinking, move the Charbpos, Bytebpos and Membpos typedefs to
 > corresponding to off_t rather than EMACS_INT;

I don't understand that.  off_t is likely to be 32 bits on 32-bit
platforms.