Hi Eric,
I tried without doc-mode and I still have the issue, I tried with "emacs
-q" to remove all other packages I used and evaluating my cedet init
file and the issue is still there. What could I try to help tracking the
issue ?
Damien
Eric M. Ludlam wrote:
> Hi,
>
> I tried your steps as exactly as I could, except I used my sandbox
> version of CEDET which is pretty close to CVS. Unfortunately, I didn't
> reproduce the problem.
>
> In your example, you excluded 'doc-mode' which I found a copy online. In
> doc-mode, I found this suspicious line in doc-mode:
>
> (modify-syntax-entry ?\' ".")
>
> This like could mess up parsing, since it will not treat chars 'a' as
> chars, but as some misc punctuation with a symbol in between. I don't
> think it depends on this, but monkeying with the syntax table has this
> potential.
>
> I will re-investigate some more later.
>
> Eric
>
> On 03/19/2010 06:12 AM, Damien Deville wrote:
>> Ok,
>>
>> i have found a way to reproduce it :)
>>
>> 1/ start with a fresh cedet cvs
>> 2/ edit semantic/semanticdb.el and uncomment line 1000
>> ;; This shouldn't ever be set. Debug some issue here?
>> (when kill-buffer-flag (debug))
>> 3/ compile cedet
>> 4/ download http://pbmtp.free.fr/emacs/pb-cedet.el and place it into
>> your load path and require it. (you should have the load path set like
>> this)
>>
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/common")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/contrib")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/ede")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/eieio")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/semantic")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/semantic/bovine")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/semantic/ctags")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/semantic/symref")
>> (add-to-list 'load-path "~/.emacs.d/lib/cedet/srecode")
>>
>> 5/ go in a temp folder and create a test.c with the following content
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> typedef struct
>> {
>> int a1;
>> int b1;
>> } type1;
>>
>> typedef struct
>> {
>> int a2;
>> int b2;
>> } type2;
>>
>> static int foo(type1 *t1, type2 *t2)
>> {
>> return t1->a1 == t2->a2;
>> }
>>
>> int main(int argc, char *argv[])
>> {
>> type1 t1 = { 1, 2};
>>
>> return 0;
>> }
>>
>> 6/ launch gtags in the folder where test.c is located
>> 7/ launch emacs place your cursor on the declaration line of foo before
>> the 'f' of foo
>> 8/ wait a bit and your buffer will get killed
>>
>> In *Message* you will have
>>
>> Idle Service Error semantic-idle-summary-idle-function: "#<buffer
>> *Messages*> - Wrong type argument: syntax-table-p, nil"
>>
>> In *CEDET Global* you will have
>> foo 16 /XXXXXXXX/test.c static int foo(type1 *t1, type2 *t2)
>>
>> If you remove all the G* files created from gtags and redo the same
>> thing it will work as expected.
>>
>> Hope that with this you will be able to fix it as it is very annoying.
>> If i disable the lines that enable global support in pb-cedet.el all
>> work fine.
>>
>> Damien
>>
>> Eric M. Ludlam wrote:
>>> On 03/18/2010 10:14 AM, Damien Deville wrote:
>>>> Hi cedet-devel,
>>>>
>>>> First a little fix
>>>>
>>>> In latest cedet cvs version semantic-idle.el should (require 'eldoc)
>>>> otherwise eldoc-message function is not defined.
>>>
>>> Thanks, I'll put one in.
>>>
>>>
>>>> Now a recurrent problem i am facing:
>>>>
>>>> I have some C code which define one static function foo then uses it in
>>>> another function, when placing cursor at the start of foo() and waiting
>>>> for idle-summary timer to expire, my buffer get closed and I have the
>>>> following error in *Messages* buffer
>>>
>>> What feature is using the below in the idle timer? I cannot find a
>>> call to semantic-symref-result-get-tags in anything that is called
>>> from the idle timer except for the use of gnu global as a database
>>> backend.
>>>
>>> Even in that case, the purpose is to close buffers that weren't
>>> already open. The earlier block of code in that function attempts to
>>> do that with get-file-buffer. If the database return is retrieving a
>>> file name for which get-file-buffer fails, but find-file-noselect
>>> succeeds, well that's kind of interesting. What do you think that
>>> might be? You can look in the temporary buffer *CEDET Global* to see
>>> what those names might look like.
>>>
>>> Eric
>>>
>>>>
>>>> Idle Service Error semantic-idle-summary-idle-function: "#<buffer
>>>> *Messages*> - Wrong type argument: syntax-table-p, nil"
>>>>
>>>>
>>>> Here is the patch i use which prevent the buffer from being closed but
>>>> leads to lot of buffer being opened.
>>>>
>>>> Index: semantic/symref/semantic-symref.el
>>>> ===================================================================
>>>> RCS file: /cvsroot/cedet/cedet/semantic/symref/semantic-symref.el,v
>>>> retrieving revision 1.15
>>>> diff -u -r1.15 semantic-symref.el
>>>> --- semantic/symref/semantic-symref.el 28 Mar 2009 12:42:14 -0000 1.15
>>>> +++ semantic/symref/semantic-symref.el 7 Sep 2009 06:38:27 -0000
>>>> @@ -396,8 +396,10 @@
>>>> tag))
>>>> lines)))
>>>> ;; Kill off dead buffers, unless we were requested to leave them
>>>> open.
>>>> - (when (not open-buffers)
>>>> - (mapc 'kill-buffer buffs-to-kill))
>>>> + ;; DAMIEND
>>>> + ;; (when (not open-buffers)
>>>> + ;; (mapc 'kill-buffer buffs-to-kill))
>>>> + ;; DAMIEND
>>>> ;; Strip out duplicates.
>>>> (dolist (T ans)
>>>> (if (and T (not (semantic-equivalent-tag-p (car out) T)))
>>>>
>>>> I tried reproducing the issue on a simple c files but did not succeed.
>>>> What could I try to help debugging this issue.
>>>>
>>>> Damien
>>>
>>
>
|