John> 7. now click Done in the customize buffer -> oops! the dired John> buffer, which still has the point, is killed! I think this has been reported before; several widget-using programs make unwarranted assumptions about what the current buffer is. When widgets are activated via extent event maps, the extent knows what buffer it's in and kills the right one (more or less, I'm not sure about the precise mechanism). But native widgets don't rely on extents for event transmission. John> I realize that it might seem that now I'm arguing that the John> button *should* grab focus, but what I'd really expect to John> happen is for the customize buffer to go away, but focus, John> and point, remain where they were in the dired buffer. Well, what would you expect to happen if you clicked on the Reset button? (Serious question.) I think that what should happen in this case is that (1) the Customize buffer should grab focus (not necessary the button; I would expect that Customize would assign keyboard focus elsewhere, probably the last-modified variable) (2) it would commit suicide (3) focus would revert to the last buffer to have focus (ie, the dired buffer) Same effect as you are asking for in this case, but it would be different if the Customize buffer persisted. (Thus the above "serious question.") -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."