>>>> "John" == John A Turner
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
Same effect as you are asking for in this case, but it would be
different if the Customize buffer persisted. (Thus the above "serious
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."