CEDET

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

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 <deng@...>

> 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

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

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 <deng@...>

> 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