tale@pawl.rpi.edu (David C Lawrence) (04/16/89)
GNU Emacs 18.53.2 of Tue Apr 11 1989 on imagine.pawl.rpi.edu (berkeley-unix)
Although I know what is causing a problem here, I think Emacs could be
slightly more graceful about recovering from it.
Repeat by:
(let ((win (selected-window)))
(pop-to-buffer "*crash*")
(enlarge-window (- (screen-height) (window-height))
(select-window win)))
At this point Emacs will die an ugly death, reporting that the marker
does not point anywhere and that Fatal Error(6.) has occurred.
The error in the lisp fragment above is in referencing a window for
select-window that is no longer visible. Playing around some, I also
found this caused Emacs considerable grief:
(setq grief (selected-window))
=> #<window 20 on *post-news*>
(switch-to-buffer "*Newsgroup*")
grief
=> #<window 20 on *Newsgroup*>
(switch-to-buffer-other-window "*post-news*")
grief
=> #<window 20 on *Newsgroup*>
(delete-other-windows)
grief
=> #<window 20 on *Newsgroup*>
... hmm ... looks like it is still active. When I did this just a
couple of minutes ago, I followed it with (select-window grief) and
Emacs had a lot of problems with that. Somehow through it all it did
not crash (though it was hardly working as it should -- correction, as
I expect it to) but it took many C-g's and other miscellaneous key
punching to get seemingly back to normal (now #<window 24 on *post-news*>).
Trying to figure out a way to build around this in the code that led
me to the first lisp segment above, I have only found
(if (get-buffer-window (window-buffer win)) (select-window win))
to do the trick (though there might be another way).
--
tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edujbw@bucsf.UUCP (04/16/89)
In article <TALE.89Apr15154633@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes: >[code segment deleted] >The error in the lisp fragment above is in referencing a window for >select-window that is no longer visible. Playing around some, I also >found this caused Emacs considerable grief: Well, since last summer I think I've seen about 6 or so bug reports on this particular bug, so maybe I better post a fix. I haven't been able to try this, but I believe it will work. Hopefully one of you out there can try it out and tell us. I'm using 18.52. *** window.c Sun Apr 16 12:50:57 1989 --- window.c.fix Sun Apr 16 12:52:01 1989 *************** *** 366,371 **** --- 366,372 ---- if (!NULL (tem)) { unshow_buffer (p); + p->buffer = Qnil; unchain_marker (p->pointm); unchain_marker (p->start); } >[more examples deleted] >Trying to figure out a way to build around this in the code that led >me to the first lisp segment above, I have only found >(if (get-buffer-window (window-buffer win)) (select-window win)) >to do the trick (though there might be another way). This is dangerous because the buffer might have been killed. Use this test instead (idea from Dan LaLiberte): (if (null (window-point win)) (select-window win)) (window-start win) will also be null if the window has been deleted. That's what the unchain_marker lines above are doing. -- Joe Wells <jbw@bucsf.bu.edu> jbw%bucsf.bu.edu@bu-it.bu.edu ...!harvard!bu-cs!bucsf!jbw