Re: What is the status of 21.5?

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: 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. 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. 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. 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. Font lock is algorithmically broken. Optimistically, GNU’s is better. Pessimisticially, the last time I looked, merging was hard. Optimistically, we have it on Windows, and the platform package systems make its lack not a big issue on Unix. 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