CEDET

The fix worked nicely, thank you very much!


On Fri, Mar 1, 2013 at 1:13 AM, Zadirion Fay <zadirion@...> wrote:

> Just saw your second email, checking now if it works
>
>
> On Fri, Mar 1, 2013 at 12:01 AM, Zadirion Fay <zadirion@...> wrote:
>
>> Hey, thanks David Engster for confirming this. I was afraid there might
>> be something wrong with my configuration.
>> Also, do you happen to know if cdb-gud, the unified debugger mode for
>> debugging Visual Studio application through cdb is still maintained? Or any
>> other way to debug VS apps from emacs?
>>
>> Thanks
>>
>>
>> On Thu, Feb 28, 2013 at 9:21 PM, David Engster <deng@...:
>>
>>> Zadirion Fay writes:
>>> > I'm having a problem getting semantic to understand the `this` c++
>>> keyword:
>>> >
>>> >  #include <iostream>
>>> >
>>> >     class SomeStructure
>>> >     {
>>> >       int mMemberOne;
>>> >       float mMemberTwo;
>>> >
>>> >       char MemberFunction()
>>> >         {
>>> >           int test = 0;
>>> >           ++test;
>>> >           this->
>>> >         }
>>> >     };
>>> >
>>> >       int main()
>>> >       {
>>> >         SomeStructure abc;
>>> >         abc.MemberFunctionMemberFunction
>>> >       }
>>> >
>>> > Any other autocompletion works in this file except when I'm trying to
>>> > autocomplete `this->`. I get no suggestions.
>>>
>>> Yes, it doesn't work in inline member functions. If you define it
>>> outside the class, it should work. Not sure why it doesn't work for
>>> inlines. It's on my TODO now, but it might take a while until I get to
>>> it.
>>>
>>> -David
>>>
>>
>>
>

Just saw your second email, checking now if it works


On Fri, Mar 1, 2013 at 12:01 AM, Zadirion Fay <zadirion@...> wrote:

> Hey, thanks David Engster for confirming this. I was afraid there might be
> something wrong with my configuration.
> Also, do you happen to know if cdb-gud, the unified debugger mode for
> debugging Visual Studio application through cdb is still maintained? Or any
> other way to debug VS apps from emacs?
>
> Thanks
>
>
> On Thu, Feb 28, 2013 at 9:21 PM, David Engster <deng@...:
>
>> Zadirion Fay writes:
>> > I'm having a problem getting semantic to understand the `this` c++
>> keyword:
>> >
>> >  #include <iostream>
>> >
>> >     class SomeStructure
>> >     {
>> >       int mMemberOne;
>> >       float mMemberTwo;
>> >
>> >       char MemberFunction()
>> >         {
>> >           int test = 0;
>> >           ++test;
>> >           this->
>> >         }
>> >     };
>> >
>> >       int main()
>> >       {
>> >         SomeStructure abc;
>> >         abc.MemberFunctionMemberFunction
>> >       }
>> >
>> > Any other autocompletion works in this file except when I'm trying to
>> > autocomplete `this->`. I get no suggestions.
>>
>> Yes, it doesn't work in inline member functions. If you define it
>> outside the class, it should work. Not sure why it doesn't work for
>> inlines. It's on my TODO now, but it might take a while until I get to
>> it.
>>
>> -David
>>
>
>

Zadirion Fay writes:
> I'm having a problem getting semantic to understand the `this` c++ keyword:   
>
>  #include <iostream>
>     
>     class SomeStructure
>     {
>       int mMemberOne;
>       float mMemberTwo;
>     
>       char MemberFunction()
>         {
>           int test = 0;
>           ++test;
>           this->  
>         }
>     };
>     
>       int main()
>       {
>         SomeStructure abc;
>         abc.MemberFunctionMemberFunction
>       }
>
> Any other autocompletion works in this file except when I'm trying to
> autocomplete `this->`. I get no suggestions.

Yes, it doesn't work in inline member functions. If you define it
outside the class, it should work. Not sure why it doesn't work for
inlines. It's on my TODO now, but it might take a while until I get to
it.

-David

David Engster writes:
> Zadirion Fay writes:
>> Any other autocompletion works in this file except when I'm trying to
>> autocomplete `this->`. I get no suggestions.
>
> Yes, it doesn't work in inline member functions. If you define it
> outside the class, it should work. Not sure why it doesn't work for
> inlines. It's on my TODO now, but it might take a while until I get to
> it.

Actually, I think I just fixed that. Please update from bzr and let me
know if it works for you.

-David

Hey, thanks David Engster for confirming this. I was afraid there might be
something wrong with my configuration.
Also, do you happen to know if cdb-gud, the unified debugger mode for
debugging Visual Studio application through cdb is still maintained? Or any
other way to debug VS apps from emacs?

Thanks


On Thu, Feb 28, 2013 at 9:21 PM, David Engster <deng@...> wrote:

> Zadirion Fay writes:
> > I'm having a problem getting semantic to understand the `this` c++
> keyword:
> >
> >  #include <iostream>
> >
> >     class SomeStructure
> >     {
> >       int mMemberOne;
> >       float mMemberTwo;
> >
> >       char MemberFunction()
> >         {
> >           int test = 0;
> >           ++test;
> >           this->
> >         }
> >     };
> >
> >       int main()
> >       {
> >         SomeStructure abc;
> >         abc.MemberFunctionMemberFunction
> >       }
> >
> > Any other autocompletion works in this file except when I'm trying to
> > autocomplete `this->`. I get no suggestions.
>
> Yes, it doesn't work in inline member functions. If you define it
> outside the class, it should work. Not sure why it doesn't work for
> inlines. It's on my TODO now, but it might take a while until I get to
> it.
>
> -David
>

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

On 02/10/2013 06:51 PM, Fedor Baart wrote:
> Hi,
>
> I noticed the following line in the semantic-f90.el:
>
> (modify-syntax-entry ?& " " f90-mode-syntax-table)
>
> This causes the & to be considered whitespace. This causes some issues
> if you cleanup trailing whitespace.
> Suppose you have the following line:
>
> a = 1 + &
> 1
>
> In this case after a delete-trailing-whitespace, the & will be deleted,
> which is incorrect.
>
> a = 1 +
> 1 ! Invalid code
>
> See http://fortranwiki.org/fortran/show/Continuation+lines for some
> details.
>
> I think that it can be considered an escape character (if placed at the
> end of a line). Perhaps when placed at the start of the line (after
> optional whitespace), it can be considered extra whitespace.

Hi Fedor,

You are right, there is a problem here.  The f90 fortran parser for 
Semantic explicitly changes the syntax table.  I'm guessing it should 
instead use the lexical syntax modification system instead.

I don't use fortran, nor would I know what to do with a fortran file, 
but the attached patch is my guess as to how to resolve this issue.  It 
compiles and passes unit tests. Perhaps it will help fix your problem?

Thanks
Eric

Eric M. Ludlam writes:
> On 02/10/2013 06:51 PM, Fedor Baart wrote:
>> I noticed the following line in the semantic-f90.el:
>
>>
>> (modify-syntax-entry ?& " " f90-mode-syntax-table)
>>
>> This causes the & to be considered whitespace. This causes some issues
>> if you cleanup trailing whitespace.

Yes, I realize now this was a pretty stupid and dangerous idea.

> You are right, there is a problem here.  The f90 fortran parser for
> Semantic explicitly changes the syntax table.  I'm guessing it should
> instead use the lexical syntax modification system instead.
>
> I don't use fortran, nor would I know what to do with a fortran file,
> but the attached patch is my guess as to how to resolve this issue.
> It compiles and passes unit tests. Perhaps it will help fix your
> problem?

Oh, I didn't know semantic-lex-syntax-modifications. If the unit test
passes, that's good. However, as far as I see I forgot to add a test
with a continuation line, so Fedor, could you test if those lines are
still parsed correctly?

-David

Hi Eric, David,

Thanks for the update. I will test it and let you know if it works. 

Cheers,

Fedor
On Feb 20, 2013, at 12:38 PM, David Engster wrote:

> Eric M. Ludlam writes:
>> On 02/10/2013 06:51 PM, Fedor Baart wrote:
>>> I noticed the following line in the semantic-f90.el:
>> 
>>> 
>>> (modify-syntax-entry ?& " " f90-mode-syntax-table)
>>> 
>>> This causes the & to be considered whitespace. This causes some issues
>>> if you cleanup trailing whitespace.
> 
> Yes, I realize now this was a pretty stupid and dangerous idea.
> 
>> You are right, there is a problem here.  The f90 fortran parser for
>> Semantic explicitly changes the syntax table.  I'm guessing it should
>> instead use the lexical syntax modification system instead.
>> 
>> I don't use fortran, nor would I know what to do with a fortran file,
>> but the attached patch is my guess as to how to resolve this issue.
>> It compiles and passes unit tests. Perhaps it will help fix your
>> problem?
> 
> Oh, I didn't know semantic-lex-syntax-modifications. If the unit test
> passes, that's good. However, as far as I see I forgot to add a test
> with a continuation line, so Fedor, could you test if those lines are
> still parsed correctly?
> 
> -David

Fedor Baart writes:
> Thanks for the update. I will test it and let you know if it works. 

I'd also be interested in general feedback in how useful the F90 parser
is. My Fortran days are pretty much over and I stopped development as it
became just good enough for my daily use. The question is whether it is
good enough to be merged to Emacs proper.

-David

On 02/06/2013 08:06 AM, kototama kototama wrote:
> Hello,
>
>
> There is semantic-fetch-tags to retrieve the tags of the current
> buffer but how can I
>
> a) fetch all tags from a project or all tags from all files under a
> given directory
>
> b) fetch all tags from all opened buffer
>
>
> I would like to have something like helm-semantic
> (https://github.com/emacs-helm/helm/blob/master/helm-semantic.el)
> but for all the files of my project.

It is probably not too good an idea to get all the tags into one big 
list.  It has the potential to be REALLY big.

There is also the dilemma that Semantic won't have all your files 
pre-parsed.  It just parses what it needs as it goes along.  I generally 
recommend people use GNU Global as a tool to bootstrap Semantic's global 
symbol table for big projects where just a pile o tag names is needed.

In semantic/complete.el are completion tools that can jump to any known 
tag in a project.  It does it by doing semantic based searches 
(semanticdb-find-tags-for-completion) which works fine without the need 
to duplicate the datastructure into a flat list.  It has options for a 
brute search (whole project) vs something based on include files.

Lastly, if you just  want a nice table of symbols that are relevant, the 
semantic/db-typecache collects that info for you as you go, and is very 
fast.

Eric

Ok so maybe I need complete.el then, can it do fuzzy matching?

On Thu, Feb 7, 2013 at 12:38 AM, Eric M. Ludlam <eric@...> wrote:
> On 02/06/2013 08:06 AM, kototama kototama wrote:
>>
>> Hello,
>>
>>
>> There is semantic-fetch-tags to retrieve the tags of the current
>> buffer but how can I
>>
>> a) fetch all tags from a project or all tags from all files under a
>> given directory
>>
>> b) fetch all tags from all opened buffer
>>
>>
>> I would like to have something like helm-semantic
>> (https://github.com/emacs-helm/helm/blob/master/helm-semantic.el)
>> but for all the files of my project.
>
>
> It is probably not too good an idea to get all the tags into one big list.
> It has the potential to be REALLY big.
>
> There is also the dilemma that Semantic won't have all your files
> pre-parsed.  It just parses what it needs as it goes along.  I generally
> recommend people use GNU Global as a tool to bootstrap Semantic's global
> symbol table for big projects where just a pile o tag names is needed.
>
> In semantic/complete.el are completion tools that can jump to any known tag
> in a project.  It does it by doing semantic based searches
> (semanticdb-find-tags-for-completion) which works fine without the need to
> duplicate the datastructure into a flat list.  It has options for a brute
> search (whole project) vs something based on include files.
>
> Lastly, if you just  want a nice table of symbols that are relevant, the
> semantic/db-typecache collects that info for you as you go, and is very
> fast.
>
> Eric

Hi,

semantic/complete.el is part of the CEDET distro, and is used in 
semantic-complete-jump.  It doesn't have a fuzzy matcher.  It would 
probably be a nice thing to add as a feature of semanticdb though.

Eric

On 02/08/2013 05:50 AM, kototama kototama wrote:
> Ok so maybe I need complete.el then, can it do fuzzy matching?
>
> On Thu, Feb 7, 2013 at 12:38 AM, Eric M. Ludlam<eric@...>  wrote:
>> On 02/06/2013 08:06 AM, kototama kototama wrote:
>>>
>>> Hello,
>>>
>>>
>>> There is semantic-fetch-tags to retrieve the tags of the current
>>> buffer but how can I
>>>
>>> a) fetch all tags from a project or all tags from all files under a
>>> given directory
>>>
>>> b) fetch all tags from all opened buffer
>>>
>>>
>>> I would like to have something like helm-semantic
>>> (https://github.com/emacs-helm/helm/blob/master/helm-semantic.el)
>>> but for all the files of my project.
>>
>>
>> It is probably not too good an idea to get all the tags into one big list.
>> It has the potential to be REALLY big.
>>
>> There is also the dilemma that Semantic won't have all your files
>> pre-parsed.  It just parses what it needs as it goes along.  I generally
>> recommend people use GNU Global as a tool to bootstrap Semantic's global
>> symbol table for big projects where just a pile o tag names is needed.
>>
>> In semantic/complete.el are completion tools that can jump to any known tag
>> in a project.  It does it by doing semantic based searches
>> (semanticdb-find-tags-for-completion) which works fine without the need to
>> duplicate the datastructure into a flat list.  It has options for a brute
>> search (whole project) vs something based on include files.
>>
>> Lastly, if you just  want a nice table of symbols that are relevant, the
>> semantic/db-typecache collects that info for you as you go, and is very
>> fast.
>>
>> Eric
>

Ok thank you very much.

Just tell me if you commit the patch so that I change my code.

On Tue, Feb 5, 2013 at 3:39 AM, Eric M. Ludlam <eric@...> wrote:
> On 02/01/2013 04:24 AM, kototama kototama wrote:
>>>
>>> Anyway, the real proof is to debug your example.  Do you have something
>>> sharable somewhere with a test I can try?
>>
>>
>> That's nice from you.
>>
>> I have the code here https://github.com/kototama/clojure-semantic
>>
>> If you compile the grammar, evaluate the clojure.el and open the file
>> test/test.clj you can M-: (car (semantic-fetch-tags))
>>
>> and see that the argument of t3 are in the right order. But then look
>> at the grammar: I call the reverse function! When not called, the
>> arguments are in the wrong order.
>
>
> I think I understand this problem better now.  It isn't just that they are
> nested, they are nested and the tag list is coming out of
> `semantic-repeat-parse-whole-stream' multiple times.
>
> For the types of nesting I discussed, a variable list (args) where put into
> a tag, and then that tag was returned from the next level of EXPANDFULL.
>
> semantic-repeat-parse-whole-stream always returns the tags in reverse order.
> It is called from semantic-parse-region-default which puts them back in
> order.  When the inner EXPANDFULL pushes it's correct tag list up, the
> -repeat- fcn doesn't reverse the order, because mapc doesn't do that.  On
> the way out, however, it gets reversed by -default.
>
> Fixing the double reverse looks easy, and should improve performance. It
> also fixes this issue in your example.  It even passed all the tests.  To be
> honest though, I don't quite trust it yet.
>
> I've attached the patch so you can play with it.  I'll sit on the change for
> a little bit and see if I can detect any weird dependencies on this that
> needs to be fixed along with it.
>
> Eric

On 02/05/2013 05:53 AM, kototama kototama wrote:
> Ok thank you very much.
>
> Just tell me if you commit the patch so that I change my code.
>

I couldn't find anything obvious dependent on the old tag order 
flipping, so I checked in my change.

Thanks
Eric

On 02/03/2013 07:34 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> On 02/02/2013 04:50 PM, David Engster wrote:
>>> Eric M. Ludlam writes:
>>>> On 01/31/2013 07:16 PM, Stephen Leake wrote:
>>>>> I bug report 13593 on debbugs.gnu.org;
>>
>>>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13593
>>>>>
>>>>> I tried to report it to the cedet sourceforge tracker, but apparently
>>>>> only cedet project members can file bug reports there.
>>>
>>>> As far as I know, there are no restrictions on the sourceforge tracker,
>>>> but thanks for reporting somewhere.
>>>
>>> Just FYI, CEDET related bugs now usually get tagged in the tracker, so
>>> you can get a list there with
>>>
>>> http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=cedet
>>>
>>> I guess I could write a small note here if I tag a new bug, so that you
>>> see it.
>>
>> That would be handy, though it sounds like a bunch of work for you to
>> do.  I should try and get better at looking there.
>
> Nah, the amount of bugs is still pretty small. If it gets more, I can
> still script that on the Buildbot server.
>
>> I just fixed one of the bug reports.  (It was a doc bug for EDE.)  How
>> do I edit the debbugs report.  Do I need a login somewhere?
>
> No, it's all via mail. Just write to BUGNUMBER@... to write
> a comment. However, note that those bugs are usually reported against
> the CEDET version bundled with Emacs. So if you fixed a bug, you should
> mention that this fix is currently only in upstream CEDET and will soon
> be merged, and put me in the CC. I can then close the bug when I have
> done the merge.

Cool!  Thanks.

Eric