Re: [cedet-semantic] semantic looking up tags with cursor placed in code comments or strings

[Nate S. <nat...@gm...>]

Eric,

I have the idle scheduler config'd for reasons you explained.  I have
 '(semantic-idle-scheduler-idle-time 5)
in my .emacs, but there's a correlation between my placement of the cursor
in a comment/string, and Semantic's *immediate* commencement of parsing.
It's not like I place the cursor, pause to think what I'm going to do for so
many seconds, and then see the parser working...  It's as if the parser
activates in response to my placing the point.

It occurred to me that the issue may be with ECB.  I use its fairly new
"symboldef" buffer.  I suspect now that ECB is reacting to my point
placement, and (ecb-symboldef-find-definition) is triggering the reparse
without paying attention to the context of the point's location.  This seems
to be the case; there seems to be no check for context in the function.  The
issue, does, however, come back to a question about semantic...

ecb-symboldef.el does have a commented code block that employs
(semantic-analyze-current-context).  I evaluated that with the point in a
comment, on the name of the .h file I was browsing.  I don't understand the
meaning of the come-back, but it appears that semantic is digesting the
location as if it were code:

I put the cursor "FooClass" on the line
  |// FILE:        FooClass.h
and on the line
  |class FooClass {
The comeback from (semantic-analyze-current-context) was
  |[object semantic-analyze-context "context"
  |        (98 . 111)
  |        (
  |         ("FooClass" type
  |          (:members ... :type "class")
  |          (:filename "w:/project/foo/include/FooClass.h")
  |          [2715 3238]))
  |        (type)
  |        nil ........

The only difference was what I've broken out as the 2nd line, which seems to
be the range of the word in which the point lies.  So, it appears Semantic
*will* look up words in comments as if they were "live" code.

Questions to you:
1.  is the behavior of (semantic-analyze-current-context) correct &
desirable?  I would think not.
2.  Is there a better way to determine if the context of (point) is code
(and not "string" or "comment")?

BTW, I wrote the draft of this email on around 10/1, so if
(semantic-analyze-current-context) has changed, please disregard

2010/9/30 Eric M. Ludlam <er...@si...>

> Hi,
>
> Semantic will go off and do work, even when in knows there is nothing to
> do.  It is basically pre-parsing files for you, and that work is not related
> to comments or strings.
>
> If you have a particularly large code base, and you would rather wait when
> you ask for something instead of the idle interruptions, you should turn off
> the following:
>
> semantic-idle-work-parse-neighboring-files-flag
> semantic-idle-work-update-headers-flag
>
> You could also just move out when it happens here:
>
> semantic-idle-scheduler-work-idle-time
>
> I posted on stackoverflow about this recently on a question with an Emacs
> tag.  I need to get that info merged into the CEDET info file still.
>
> Eric
>
>
> On 09/30/2010 09:54 AM, Nate Schley wrote:
>
>> Eric,
>>
>> I find that often, when place the cursor in // a code comment
>>  or "a literal string", I find myself waiting for semantic to digest
>> gobs of files in an apparent attempt to look up what should be ignored.
>> Happily, ^G works eventually, but it is an interruption to the workflow.
>>
>> As an enhancement to your excellent SW, may I suggest first checking to
>> see if the point lies in a comment or literal string before charging off
>> into the look-up task.
>>
>> FWIW, I'm working in C++ with more kSLOCs than you can shake a stick at.
>> --
>> Thanks,
>>
>> Nate
>>
>>


-- 
Thanks,

Nate