Following is a patch for semantic-tag-buffer function to verify that a
file exists before attempting to call find-file-noselect on it.
=== modified file 'cedet-trunk/semantic/semantic-tag.el'
--- cedet-trunk/semantic/semantic-tag.el 2011-05-01 16:34:08 +0000
+++ cedet-trunk/semantic/semantic-tag.el 2011-07-20 17:00:10 +0000
@@ -193,7 +193,8 @@
buff
;; TAG has an originating file, read that file into a buffer, and
;; return it.
- (if (semantic--tag-get-property tag :filename)
+ (if (and (semantic--tag-get-property tag :filename)
+ (file-exists-p (semantic--tag-get-property tag :filename)))
(save-match-data
(find-file-noselect (semantic--tag-get-property tag :filename)))
;; TAG is not in Emacs right now, no buffer is available.
I needed to add this when my emacs23 got into a state where push-mark
failed due to the missing file. I was completely hosed, because I could
not even yank (i.e., Control-y)! Adding the check above allowed me to
get out of this state so that I could go on.
I'm sorry, but I did not save the stack trace. However I remembr that
it all started with this advice
(defadvice push-mark (around semantic-mru-bookmark activate)
"Push a mark at LOCATION with NOMSG and ACTIVATE passed to `push-mark'.
If `semantic-mru-bookmark-mode' is active, also push a tag onto
the mru bookmark stack."
(semantic-mrub-push semantic-mru-bookmark-ring
(point)
'mark)
ad-do-it)
which ended up iterating over some kind of ring which contained entries
for files that were removed since the data in the ring was created.
Perhaps the fact that I work with multiple branches of the same set of
files exacerbate the code? That is I often edit files that are almost
identical within different directory trees. I also often remove one or
more trees with "rm -rf" after having visited files that get deleted.
The one line change is something that worked for me to recover my emacs
session. I do not propose that it should be a fix that gets checked in,
but as something that illustrates a possible bug.
|