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 @@
;; 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)))
(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."
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.