Redirecting to xemacs-beta from xemacs-patches. Note this thread has already been redirected at a different stage by Vin Shelton; since this subthread quotes more, I propose we meet here instead of in Vin's subthread. Matthias> I don't see where our patch would add "substantial Matthias> complexity" to any of those or other areas you mentioned Matthias> above. Well, I've tried working on all of them, and it _does_ add complexity, at least given my skills. Much of the complexity is because the Xft stuff is not properly abstracted, but rather #ifdef'd into place. This would fit naturally with improvements in face and font description. Matthias> That's correct, Xft is a fourth font description Matthias> model. But you still have to convince me that Customize Matthias> and friends get more complicated with it. No, I don't. It's the other way around. Sorry; that's the point of having a review process. If you can convince others to lean on me, that works too. But you have to do the convincing, at this point. Matthias> I totally agree that having a great, unifying font Matthias> description scheme incorporated into XEmacs would surely Matthias> be an awesome thing. But I think this is a whole other Matthias> project. Yes. One that should be at least in the _design review stage_ before your patch is accepted for 21.5. As I say, I feel your pain. Matthias> you mean by "two-octet Unicode" and "error checking"? "Two-octet unicode" was a mistake. Yuri/Aleksey's patch uses UTF-8. The problem is the same, however. X11 historically just pukes if you feed it data it doesn't expect. Routines that call into X without doing range-checking on the arguments are simply crashes waiting to happen. Do you know what happens if an illegal character is given for one of those fonts? If you do, please document it. (Note that you may not assume at this point that the Mule routines themselves know what they are doing---anything can get passed into Xft: illegal characters, mal-formed UTF-8, and you either have to know the Xft will gracefully signal an error so you can catch it, or catch the bad data yourself.) Matthias> I once integrated their patch into my workspace, built a Matthias> Mule/XEmacs and fiddled around with it quite Matthias> bit. Unfortunately the patch didn't seem to work for me: Matthias> already visiting buffers with just Latin1 text showed Matthias> some wrong character translations of the "upper half" of Matthias> the latin1 char set. Unfortunately I never managed to Matthias> figure out whether the unicode translation is broken or Matthias> I am just unable to use XEmacs with different character Matthias> encodings correctly. Matthias> We also discovered all those problems you describe Matthias> above. And that's why the latest patch leaves all the Matthias> widget code (lwlib) completely untouched, as you Matthias> hopefully noticed. Actually, I was rather disappointed. But we have different viewpoints. But you're saying you _have_ tried several of these desirable things, failed, don't know why---and still you claim you see no additional complexity? Think again; are you kidding yourself? Matthias> Then, there seems no (obvious) way to incorporate the Matthias> automatic selection of charsets into the current font Matthias> selection scheme using just pattern strings and Matthias> Customize. Yup, and that needs to come first IMO. Matthias> do you really foresee [fixing custom and the font model] Matthias> to happen in the not-too-distant future? Not if someone doesn't push for it to happen. It does need to happen, or XEmacs will lose users that it really should have. Matthias> Are there any plans to do this? Ben has some ideas that are related, Hrvoje has some ideas specifically along these lines, I have some ideas. If there are features in the queue that are waiting, we'll have more incentive to turn them into "plans", and those who have features they want in will help us to design something that works for everybody. Matthias> Are there any people willing to work on this? Dunno. I don't know what Ben plans or has time for, or Hrvoje. I'll probably have some time for the next couple of months, but I'm not the programmer that some of the other guys are. ms> but defaulting it to off for now? (And forcing it to off with ms> Mule.) Matthias> Our Mule users see some nice Xft-enabled XEmacs at their Matthias> neighbors', they get jealous, do their homework and fix Matthias> the breakage in no time at all ... :-) You don't fix design breakage in no time at all. ms> We've been over this often: branches in CVS simply don't work ms> well enough to support this model gracefully. Matthias> I'm not in favor of a separate branch either. We all Matthias> know how it ends ... Yeah. You put on your waders, step into the muck, start shoveling, and several hours or days later you have a merged workspace. Even in free software, not everything can be fun. Not all patches should be merged. Etc. Matthias> So, are there any ways to resolve the current situation? You'll notice I haven't issued a formal veto, yet. All I want at this stage is to talk about the issues before we commit something that really looks fishy to me, precisely because you're not interested in addressing any of the fundamental breakage. Your patch is perfectly appropriate for 21.6. I proposed that quite a while ago, and it was vetoed by the same people who don't like branches. Maybe we should revive it. Or maybe you can get Vin to take it. Matthias> Anyways, receiving a couple of private emails from Matthias> others users shows me that I'm not the only one who Matthias> likes eye candies either ... :-) Everybody likes candy. Too much of it and you get far more friendly with your dentist than is good for your wallet, not to mention painful. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.