Another possibly silly question arising from perusal of the great Mule
merge...
Is speed (or small linear factors in memory) ever actually a concern
nowadays? The whole deal of supporting multiple internal buffer
formats seems to be justified by speed for multi-lingual processing,
and there are various tricky things scattered around the rest of the
code to improve speed.
The last time I can remember being disturbed by XEmacs' slowness was
sometime in the mid 90s when I was running Lucid Emacs 19 on a 68040.
(The days when a full compile was a go-out-for-long-dinner job rather than
a you-may-just-have-time-to-make-coffee job.)
On the other hand, I don't do extensive non-English processing.
Do people find XEmacs noticeably slow in any normal usage pattern?
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hi,
I have received this bug report, https://bugs.gentoo.org/661592, which is about a segmentation violation during the build process of xemacs 21.5.34. I managed to recreate the problem once(!) on one of my machines but after that I have not been able to get it again, sigh, although I have tried it a like 20 times or more.
I can't see that we have had this issue on the build bot either which uses the same machine I got the error on and does a lot of builds!?
Aidan: Have you seen anything like this? (With a hope that some recent development you have done has touched and fixed things that could cause segmentation violations in this old code base!?)
Yours
--
%% Mats

Hello --
I have committed and built versions of the following packages. They will soon
be available on ftp.xemacs.org in the normal way; for the moment they are
downloadable from:
https://www.parhasard.net/xemacs/packages-released-june-2018/
auctex-1.58-pkg.tar.gz
ede-1.07-pkg.tar.gz
edit-utils-2.58-pkg.tar.gz
eieio-1.10-pkg.tar.gz
eshell-1.21-pkg.tar.gz
gnus-2.04-pkg.tar.gz
mail-lib-1.84-pkg.tar.gz
prog-modes-2.33-pkg.tar.gz
psgml-1.50-pkg.tar.gz
text-modes-2.06-pkg.tar.gz
time-1.17-pkg.tar.gz
xemacs-base-2.46-pkg.tar.gz
xwem-1.26-pkg.tar.gz
Best,
Aidan
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)

I probably have known this once, but I can't remember.
What is the reason for all the DEFVAR_BUFFER_LOCAL_VARIABLES with
hardwired slots in the buffer structure?
If I want a new buffer-local C-accessible variable,, do I have to do
that, or can I just define a standard DEFVAR variable, and then make
it buffer-local in Lisp ?