xemacs segmentation fault on my new iMac

Howdy, Hoping this posts all right. I subscribed to this list for years, but it was a long time ago. But I still use XEmacs. I'm trying to get XEmacs properly working on my new iMac. It worked beautifully for years (since 2006) with my previous Mac, a MacBook Pro. When I just start xemacs, it crashes. (I get a Segmentation fault, though no core dump.) Interestingly, when I run xemacs -q and then immediately run (load-file "~/.xemacs/init.el"), it does *not* crash. Or I can do it the hard way and progessively eval pieces of it all the way through. But once I try to visit a Perl file or something, it goes ka-boom. It seems to be failing any time it tries to fontify anything via font-locks.el, which happens primarily when font-lock-fontify-buffer runs, which is often, because it's built into the hooks of just about any sort of mode that is entered for entering almost anything other than plain text, e.g., any programming language file: shell, C, Elisp, Perl, LaTeX, and so forth. I've included a lisp backtrace below. As background, I've been an XEmacs user since it was in alpha state at Lucid with Zamie Zawinski in charge. I can hardly live without it, but have used Macs as my primary machines since about 2006. While I no longer delve into it or try to tweak it much, I do have a lot of legacy effort invested in it and would love to just continue using it if I can. I'm running it under the current version of X11 for OS X that is owned by (or called?) XQuartz. I installed it from the macports collection. I've got version 21.4 patch 22. I could finally just switch over to using GNU Emacs permanently, but the transition would be extremely painful, almost like starting over, because I have a great deal of stuff in my startups and custom code and the like. I particularly prefer the way that XEmacs allows me to do key bindings. I seem to recall that it was over issues that touched at leaset tangentially on this that JWZ and his crew parted ways with RMS. And I know XEmacs is not being supported much these days. Boo hoo. Still, here's the promised backtrace. If anyone can give me a clue how I might work through this problem, I'd be grateful. dispatch-non-command-events() # (condition-case ... . ((nil))) progress-feedback-dispatch-non-command-events() # bind (tmsg top frame value message label) append-progress-feedback(font-lock "Fontifying Opts..." 0 nil) # bind (frame value message label) display-progress-feedback(font-lock "Fontifying Opts..." 0) # bind (str) # (unwind-protect ...) # bind (args value fmt label) progress-feedback-with-label(font-lock "Fontifying %s..." 0 "Opts") # bind (maybe-loudly end beg) font-lock-default-unfontify-region(1 365 t) # bind (loudly end beg) font-lock-unfontify-region(1 365 t) # bind (was-on font-lock-verbose font-lock-message-threshold aborted) # (unwind-protect ...) font-lock-default-fontify-buffer() # bind (font-lock-verbose) font-lock-fontify-buffer() # bind (on-p maximum-size arg) font-lock-mode(1) # bind (was-on font-lock-verbose font-lock-message-threshold aborted) # (unwind-protect ...) font-lock-default-fontify-buffer() # bind (font-lock-verbose) #<compiled-function nil "...(9)" [font-lock-fontify-buffer-function font-lock-verbose] 1 ("/opt/local/lib/xemacs-21.4.22/lisp/font-lock.elc" . 38584) nil>() call-interactively(font-lock-fontify-buffer) command-execute(font-lock-fontify-buffer t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) -- Lynn David Newton Columbus, Ohio neologisticsediting.com lynndavidnewton.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta