Hi,
Semantic-analyze-current-context will always try to parse the local
text. It is generally up to the tool calling the analyzer to first
check what the local context is to see if that is worth while.
For example, in the idle-summary-mode, it calls
semantic-idle-summary-useful-context-p. This itself is a bit of a hack,
since it depends on font-lock, which the analyzer shouldn't really
depend on.
Ideally, semantic would parse the whole buffer, and know the difference,
but this hasn't happened.
I think Klaus moved some of ECB's events into Semantic's idle timer, but
I don't know what the full state of things there is.
Eric
On 11/08/2010 12:06 PM, Nate Schley wrote:
> 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 <eric@...
> <mailto:eric@...>>
>
> 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
|