CEDET

Hi,

  Are you experimenting with semantic 2.0?  If so, you have
encountered semantic-auto-parse-mode.  You can turn it off, or if you
are dealing with very big files (likely if it is slow) you could
modify semantic-auto-parse-max-buffer-size.  It could also be it is
tracking too quickly for you.  Perhaps modifying
semantic-auto-parse-idle-time is better?

  To bind a reparse to a keystroke, you could use the imenu entry to
do the reparse, or do the equivalent of "M-- M-x bovinate".  Perhaps
David could bind such a thing to a senator button.

  I'm not sure why summary mode would effect what you are seeing.  I
was pretty sure it did not request a reparse.  Perhaps a reparse
request snuck into the bowels of the library somewhere.

Good Luck
Eric

>>> Dan Debertin <airboss+cedet@...> seems to think that:
>I'm getting "force full reparse" messages, with concomitant delay,
>about every few keystrokes. As a result, I'm continually 5-10
>keystrokes ahead of emacs, as if I were typing over a 9600-baud modem.
>
>Turning off semantic-summary-mode causes the reparsing to stop, but
>summary-mode is one of the main reasons I'm using semantic in the
>first place, so I don't want to do that. 
>
>I would rather just invoke a reparse myself (with a keystroke) to pick
>up new tokens that I've entered since the last parse, than to have
>Emacs constantly doing it for me. 
  [ ... ]

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

>   Are you experimenting with semantic 2.0?  

Yes; I should've mentioned that. 

> If so, you have encountered semantic-auto-parse-mode.  

It sounds like a likely cause, but it doesn't appear to be turned on
in this buffer. If I invoke "M-x semantic-auto-parse-mode", Emacs
replies that auto-parse-mode is now enabled, implying that it wasn't
before. 

In any case, even after making sure auto-parse-mode is off, the
problem persists.

>   I'm not sure why summary mode would effect what you are seeing.  I
> was pretty sure it did not request a reparse.  Perhaps a reparse
> request snuck into the bowels of the library somewhere.

It seems strange to me too. You should be able to see what I'm seeing
by doing this:

1. C-x C-f foo.c RET
2. int *myfunc(

As soon as I type the open-paren, semantic does a forced full reparse,
and continues to do so at various junctures while I'm typing. If I
turn off semantic-summary-mode, the reparsing stops.

I'm pasting my custom-set-variables below my sig in case that helps.

Dan
--
/^Dan Debertin$/         | 
airboss@...  | 
 http://www.nodewarrior.org      | 

(custom-set-variables
  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 '(global-semantic-highlight-by-attribute-mode nil nil (semantic-util-modes))
 '(global-semantic-highlight-edits-mode nil nil (semantic-util-modes))
 '(global-semantic-show-parser-state-mode nil nil (semantic-util-modes))
 '(global-semantic-show-tag-boundaries-mode nil nil (semantic-util-modes))
 '(global-semantic-show-unmatched-syntax-mode nil nil (semantic-util-modes))
 '(global-semantic-summary-mode t nil (semantic-util-modes))
 '(global-senator-minor-mode t nil (senator))
 '(semantic-imenu-bucketize-file nil)
 '(semantic-imenu-bucketize-type-members nil)
 '(semantic-imenu-buckets-to-submenu nil)
 '(semanticdb-default-save-directory "~/.semantic")
 '(semanticdb-global-mode t nil (semanticdb))
 '(semanticdb-project-roots (quote ("~/code/lib" "~/code/lib/tests"))))

(require 'semantic-load)

Hi,

The cause is not what I had initially suspected.

Are you interested in debugging it?

M-x debug-on-entry RET semantic-edits-incremental-fail RET

You can then get a backtrace and we can see who forces the parse.

I'm not sure when I will get to debugging this problem myself.

Eric

>>> Dan Debertin <airboss+cedet@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>>   Are you experimenting with semantic 2.0?  
>
>Yes; I should've mentioned that. 
>
>> If so, you have encountered semantic-auto-parse-mode.  
>
>It sounds like a likely cause, but it doesn't appear to be turned on
>in this buffer. If I invoke "M-x semantic-auto-parse-mode", Emacs
>replies that auto-parse-mode is now enabled, implying that it wasn't
>before. 
>
>In any case, even after making sure auto-parse-mode is off, the
>problem persists.
>
>>   I'm not sure why summary mode would effect what you are seeing.  I
>> was pretty sure it did not request a reparse.  Perhaps a reparse
>> request snuck into the bowels of the library somewhere.
>
>It seems strange to me too. You should be able to see what I'm seeing
>by doing this:
>
>1. C-x C-f foo.c RET
>2. int *myfunc(
>
>As soon as I type the open-paren, semantic does a forced full reparse,
>and continues to do so at various junctures while I'm typing. If I
>turn off semantic-summary-mode, the reparsing stops.
>
>I'm pasting my custom-set-variables below my sig in case that helps.
>
>Dan
>--
>/^Dan Debertin$/         | 
>airboss@...  | 
>www.nodewarrior.org      | 
>
>(custom-set-variables
>  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
>  ;; Your init file should contain only one such instance.
> '(global-semantic-highlight-by-attribute-mode nil nil (semantic-util-modes))
> '(global-semantic-highlight-edits-mode nil nil (semantic-util-modes))
> '(global-semantic-show-parser-state-mode nil nil (semantic-util-modes))
> '(global-semantic-show-tag-boundaries-mode nil nil (semantic-util-modes))
> '(global-semantic-show-unmatched-syntax-mode nil nil (semantic-util-modes))
> '(global-semantic-summary-mode t nil (semantic-util-modes))
> '(global-senator-minor-mode t nil (senator))
> '(semantic-imenu-bucketize-file nil)
> '(semantic-imenu-bucketize-type-members nil)
> '(semantic-imenu-buckets-to-submenu nil)
> '(semanticdb-default-save-directory "~/.semantic")
> '(semanticdb-global-mode t nil (semanticdb))
> '(semanticdb-project-roots (quote ("~/code/lib" "~/code/lib/tests"))))
>
>(require 'semantic-load)
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>cedet-semantic mailing list
>cedet-semantic@...
>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

> Are you interested in debugging it?

I don't know this piece of code very well, but I'll do what I can.

> M-x debug-on-entry RET semantic-edits-incremental-fail RET

Here's a backtrace:

* semantic-edits-incremental-fail()
  (condition-case errobj (let* (... ... ... ... ... ... ... ... ... ...) (o=
r changes ...) (while changes ... ... ... ... ... ... ... ... ...) (semanti=
c-parse-tree-set-up-to-date)) (error (message ...) (semantic-edits-incremen=
tal-fail)))
  (let ((changed-tokens nil)) (condition-case errobj (let* ... ... ... ...)=
 (error ... ...)) changed-tokens)
  semantic-parse-changes-default()
  semantic-parse-changes()
  semantic-bovinate-toplevel(t)
  semantic-something-to-tag-table(#<buffer foo.c>)
  semanticdb-find-translate-path-includes-default(nil)
  semanticdb-find-translate-path-default(nil nil)
  semanticdb-find-translate-path(nil nil)
  semanticdb-find-tags-collector(#[(table) "=C3=82	\"=C2=87" [table name s=
emanticdb-deep-find-tags-by-name-method] 3] nil nil)
  semanticdb-deep-find-tags-by-name("myfunc")
  senator-find-current-symbol-tag("myfunc")
  senator-eldoc-print-current-symbol-info-default()
  senator-eldoc-print-current-symbol-info()
  eldoc-print-current-symbol-info()
  apply(eldoc-print-current-symbol-info nil)
  byte-code("=C3=81=C3=82H=C3=83H\"=C2=87" [timer apply 5 6] 4)
  timer-event-handler([t 0 0 500000 t eldoc-print-current-symbol-info nil t=
])

The "Force full reparse" message was also clobbering the real error
message, which is "Unhandled change group" at line 615 of
semantic-edit.el.

So I can see the part of -incremental-parser that prints this message,
but the large stretch of code above it will take some more time to
digest. I'll keep looking at it, but let me know if the above gives
you an idea of what's going on.

TIA,

Dan
--
/^Dan Debertin$/         |=20
airboss@...  |=20
 http://www.nodewarrior.org      |=20

Hi,

  It appears that in semantic-util.el line 101 seems to be the
problem.  That function now always tries to refresh the token list.
Functions like eldoc need to be able to access the token list of
buffers w/out doing a reparse for speed purposes.

  You could probably change this line to:

    semantic-toplevel-bovine-cache))

to fix your problem.  Really fixing this for future versions of
semantic will require some thought.

Eric

>>> Dan Debertin <airboss+cedet@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> Are you interested in debugging it?
>
>I don't know this piece of code very well, but I'll do what I can.
>
>> M-x debug-on-entry RET semantic-edits-incremental-fail RET
>
>Here's a backtrace:
>
>* semantic-edits-incremental-fail()
>  (condition-case errobj (let* (... ... ... ... ... ... ... ... ... ...)=
 (or changes ...) (while changes ... ... ... ... ... ... ... ... ...) (se=
mantic-parse-tree-set-up-to-date)) (error (message ...) (semantic-edits-i=
ncremental-fail)))
>  (let ((changed-tokens nil)) (condition-case errobj (let* ... ... ... .=
..) (error ... ...)) changed-tokens)
>  semantic-parse-changes-default()
>  semantic-parse-changes()
>  semantic-bovinate-toplevel(t)
>  semantic-something-to-tag-table(#<buffer foo.c>)
>  semanticdb-find-translate-path-includes-default(nil)
>  semanticdb-find-translate-path-default(nil nil)
>  semanticdb-find-translate-path(nil nil)
>  semanticdb-find-tags-collector(#[(table) "=C3=82=08	\"=C2=87" [table n=
ame semanticdb-deep-find-tags-by-name-method] 3] nil nil)
>  semanticdb-deep-find-tags-by-name("myfunc")
>  senator-find-current-symbol-tag("myfunc")
>  senator-eldoc-print-current-symbol-info-default()
>  senator-eldoc-print-current-symbol-info()
>  eldoc-print-current-symbol-info()
>  apply(eldoc-print-current-symbol-info nil)
>  byte-code("=C3=81=08=C3=82H=08=C3=83H\"=C2=87" [timer apply 5 6] 4)
>  timer-event-handler([t 0 0 500000 t eldoc-print-current-symbol-info ni=
l t])
>
>The "Force full reparse" message was also clobbering the real error
>message, which is "Unhandled change group" at line 615 of
>semantic-edit.el.
>
>So I can see the part of -incremental-parser that prints this message,
>but the large stretch of code above it will take some more time to
>digest. I'll keep looking at it, but let me know if the above gives
>you an idea of what's going on.
>
>TIA,
>
>Dan
>--
>/^Dan Debertin$/         |=20
>airboss@...  |=20
>www.nodewarrior.org      |=20
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>cedet-semantic mailing list
>cedet-semantic@...
>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

--=20
          Eric Ludlam:                 zappo@..., eric@...=
om
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org