Re: xemacs-gtk now displaying unicode

Marcus Harnisch writes: Sure, but they don't write code for XEmacs. What matters is, first, what those of us who do write code for XEmacs want, and second, what we're willing to do for others. You are more than welcome to express *your* opinions. You are well-known here (at least to one reviewer, and that's more than enough :-), and we value your past contributions and expect more in the future. We would like to keep you happy. But I really don't think it much matters what some ill-defined and silent "majority" prefers, and my votes and code contributions won't be informed by guesses about it. It's not a question of where it's rendered; it's a question of where it's displayed. XEmacs should be able to display on multiple displays, automatically adapting to each display's special characteristics. That's why we have specifiers (aside from torturing poor David Kastrup, who has -- in his own way -- actually been a pretty good sport about it). But specifiers don't populate themselves, mostly. They need to be initialized from some kind of configuration; where available, that should include X resources. N.B. We can't get away with relying on built-in Xt initializations anyway; we already do our own parsing of most resources. Satisfying Julian, even in the GTK context, should be possible with X resources. Au contraire. I do, and I imagine Julian does too, regularly have frames displayed on both machines at the same time for various reasons. It doesn't mean that there aren't other ways of accomplishing the same goals, but we'd rather not be forced to make a choice between upgrading XEmacs and maintaining personal workflows that don't need breaking. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta