Thread: [cedet-semantic] semantic wants to kill buffers I'm using
Brought to you by:
zappo
From: Nate S. <nat...@gm...> - 2013-02-27 16:04:57
|
Folks, While I'm coding in various buffers, sometimes semantic/cedet wants to delete some buffer(s) I'm not immediately using. The clue: A pop-up window saying words to the effect of "foo.cpp has been modified. Do you really want to kill it" This would appear to correlate with this entry in *Messages*: Updating buffer list...done I think its frequency depends on how many files I'm working on at the same time, but I have not figured out how to readily reproduce it. I would think semantic would only delete buffers that: 1) it -- not the user -- has opened, and 2) are not modified. Is this the case? If not, should it be? If there's some configuration associated with this behavior, please advise. -- Thanks, Nate |
From: David E. <de...@ra...> - 2013-02-27 19:02:24
|
Nate Schley writes: > While I'm coding in various buffers, sometimes semantic/cedet wants to delete > some buffer(s) I'm not immediately using. The clue: A pop-up window saying > words to the effect of > "foo.cpp has been modified. Do you really want to kill it" Which CEDET version are you using? -David |
From: Nate S. <nat...@gm...> - 2013-02-28 15:25:21
|
David, I've been using the latest off the bzr, updating every couple of weeks or so. The issue has been around for quite a while. In fact, I'd've sworn I'd seen something about it in the mailing list at some point, but I couldn't find anything when I searched my gmail for something on it. Thanks, Nate 2013/2/27 David Engster <de...@ra...> > Nate Schley writes: > > While I'm coding in various buffers, sometimes semantic/cedet wants to > delete > > some buffer(s) I'm not immediately using. The clue: A pop-up window > saying > > words to the effect of > > "foo.cpp has been modified. Do you really want to kill it" > > Which CEDET version are you using? > > -David > -- Thanks, Nate |
From: David E. <de...@ra...> - 2013-02-28 18:33:17
|
Nate Schley writes: > I've been using the latest off the bzr, updating every couple of weeks or so. > The issue has been around for quite a while. In fact, I'd've sworn I'd seen > something about it in the mailing list at some point, but I couldn't find > anything when I searched my gmail for something on it. Yes, I fixed such a bug last year in November. Semantic could kill buffers if you used the GNU Global database and had your files in a buffer with a symlinked directory in between. If you recently updated, this cannot be it, though. Is is very hard to debug this stuff without a backtrace. You could use something like this: (defun my-print-bt () (let ((buf (current-buffer))) (with-current-buffer (get-buffer-create "*kill-history*") (let ((standard-output (current-buffer))) (insert "-------------------------------------\n" "Buffer to be killed: " (buffer-name buf) "\nBacktrace: \n") (backtrace))) t)) Activate this function by doing (add-to-list 'kill-buffer-query-functions 'my-print-bt) and then try to reproduce your problem. As soon as you get a killed buffer, search for its name in the buffer "*kill-history*" and post the backtrace beneath. Be warned that a *lot* of buffers get killed during Emacs usage, so this *kill-history* buffer will get large pretty quick. -David |
From: Nate S. <nat...@gm...> - 2013-02-28 19:51:50
|
David, I'll try your suggestion, though probably next week. I'm trying to get something out by tomorrow now. I'll be in touch. thanks! Nate 2013/2/28 David Engster <de...@ra...> > Nate Schley writes: > > I've been using the latest off the bzr, updating every couple of weeks > or so. > > The issue has been around for quite a while. In fact, I'd've sworn I'd > seen > > something about it in the mailing list at some point, but I couldn't find > > anything when I searched my gmail for something on it. > > Yes, I fixed such a bug last year in November. Semantic could kill > buffers if you used the GNU Global database and had your files in a > buffer with a symlinked directory in between. If you recently updated, > this cannot be it, though. > > Is is very hard to debug this stuff without a backtrace. You could use > something like this: > > (defun my-print-bt () > (let ((buf (current-buffer))) > (with-current-buffer (get-buffer-create "*kill-history*") > (let ((standard-output (current-buffer))) > (insert "-------------------------------------\n" > "Buffer to be killed: " (buffer-name buf) > "\nBacktrace: \n") > (backtrace))) > t)) > > Activate this function by doing > > (add-to-list 'kill-buffer-query-functions 'my-print-bt) > > and then try to reproduce your problem. As soon as you get a killed > buffer, search for its name in the buffer "*kill-history*" and post the > backtrace beneath. > > Be warned that a *lot* of buffers get killed during Emacs usage, so this > *kill-history* buffer will get large pretty quick. > > -David > -- Thanks, Nate |