Re: outstanding issues

That doesn't help me with the problem that John Turner reports; that's evidently not a "button", because the standard focus-hogging behavior of "buttons" is inappropriate for it, but it's obviously not a "toolbar-button" either. Now what?

Second, I see at least two other ways besides the "focusable" property on buttons to implement focus policy in XEmacs (tab groups for children of frames, and extents). Speaking as Release Manager: 1. I would strongly prefer that you pick one policy or the other, implement it, and we will document the "loser" platform in PROBLEMS. This is not a showstopper. I think it is highly likely given the strongly held biases on both sides that we will waste a lot more time than it's worth trying to come up with, and work the bugs out of, a generic solution by release time. Please continue the discussion with the X advocates (Matt and John, at least---I will stay out of it). I am trusting you to be as creative and open-minded as possible, Andy---I will abide by your decision. If you are going to simply choose one, I don't think there's a great hurry to make a decision. In any case, you may want to wait for Ben (who should be back next week). He will undoubtedly have strong opinions on default behavior and implementation. 2. On behalf of the next Release Manager: There are several possible implementations of focus policy. If you can't help yourself and find your fingers typing in an implementation by themselves :-), please carefully comment, and preferably #ifdef the code. The changes should be easy to locate if we decide to use a different implementation of focus policy.