Re: [Bug: 21.5-b11] ECB Window configuration problem.

>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org&gt; writes: SY> # bind (standard-output stack-trace-on-signal debug-on-signal SY> # stack-trace-on-error debug-on-error) (unwind-protect ...) SY> signal(error ("ECB 1.91.1: Only an edit-window can be deleted!")) SY> # bind (args datum) SY> cerror("ECB 1.91.1: Only an edit-window can be deleted!") SY> apply(cerror "ECB 1.91.1: Only an edit-window can be deleted!" nil) SY> # bind (args datum) SY> error("ECB 1.91.1: Only an edit-window can be deleted!") SY> # bind (debug-on-error ad-return-value force window) SY> delete-window(#<window on " *ECB Sources*" 0xdb8d>) SY> # bind (next window window) SY> window-reduce-to-one(#<window on " *ECB Directories*" 0xce19>) SY> # bind (window) SY> window-reduce-to-one(#<window 0xdb89>) SY> # bind (combination-start root-window frame) SY> frame-reduce-to-one-window(#<x-frame "emacs" 0x1356>) SY> # bind (configuration frame) SY> really-set-window-configuration(#<x-frame "emacs" 0x1356> [cl-struct-window-configuration #<x-frame "emacs" 0x1356> 822 645 #<buffer "*info*"> 13 2 2 [cl-struct-saved-window nil nil nil nil nil nil nil 0 0 814 587 0 0 nil [cl-struct-saved-window nil nil nil nil nil nil nil 0 0 274 587 0 0 t nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Directories*"> #<marker in no buffer 0x8513f14> #<marker at 1 in *ECB Directories* 0x85c76dc> #<marker at 1 in *ECB Directories* 0x8513efc> 0 0 274 169 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Sources*"> #<marker in no buffer 0x85c7694> #<marker at 1 in *ECB Sources* 0x859baec> #<marker at 1 in *ECB Sources* 0x859bad4> 0 169 274 312 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Methods*"> #<marker in no buffer 0x86472ec> #<marker at 1 in *ECB Methods* 0x859bec4> #<marker at 1 in *ECB Methods* 0x8647274> 0 312 274 481 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " ! *ECB! SY> History*"> #<marker in no buffer 0x86472d4> #<marker at 1 in *ECB SY> History* 0x8513f8c> #<marker at 1 in *ECB History* 0x864737c> 0 481 SY> 274 587 0 0 t nil nil nil]]]] [cl-struct-saved-window t nil nil SY> #<buffer "*info*"> #<marker in no buffer 0x92b2e24> #<marker at 15339 SY> in *info* 0x859beac> #<marker at 15339 in *info* 0x864761c> 274 0 814 SY> 587 0 0 nil nil nil nil]] nil [cl-struct-saved-window nil t nil SY> #<buffer " *Minibuf-0*"> #<marker in no buffer 0x92b2e9c> #<marker at SY> 1 in *Minibuf-0* 0x92b2e0c> #<marker at 1 in *Minibuf-0* 0x92b2eb4> 0 SY> 587 814 600 0 0 nil nil nil nil]]]) SY> # bind (frame configuration) SY> set-window-configuration([cl-struct-window-configuration #<x-frame "emacs" 0x1356> 822 645 #<buffer "*info*"> 13 2 2 [cl-struct-saved-window nil nil nil nil nil nil nil 0 0 814 587 0 0 nil [cl-struct-saved-window nil nil nil nil nil nil nil 0 0 274 587 0 0 t nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Directories*"> #<marker in no buffer 0x8513f14> #<marker at 1 in *ECB Directories* 0x85c76dc> #<marker at 1 in *ECB Directories* 0x8513efc> 0 0 274 169 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Sources*"> #<marker in no buffer 0x85c7694> #<marker at 1 in *ECB Sources* 0x859baec> #<marker at 1 in *ECB Sources* 0x859bad4> 0 169 274 312 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " *ECB Methods*"> #<marker in no buffer 0x86472ec> #<marker at 1 in *ECB Methods* 0x859bec4> #<marker at 1 in *ECB Methods* 0x8647274> 0 312 274 481 0 0 t nil nil [cl-struct-saved-window nil nil nil #<buffer " *ECB History*"> #<marker in no bu! ffer! The problem is that `set-window-configuration' is called while an ECB window is around. `set-window-configuration' essentially deletes all current windows and re-installs a window geometry that was captured earlier. The old C code we had (and still have in 21.4) for this went completely behind the back of almost all Elisp code, so it didn't trigger this problem. So it's probably not a good idea for ECB to trigger an error in this case. I'll try to look into this in more detail, but I'm temporarily very busy, so it may be a while.