>>> Paul Kinnucan <[EMAIL PROTECTED]> seems to think that:
>>>>>> "Michael" == Michael Schierl <[EMAIL PROTECTED]> writes:
[ ... ]
> Michael> (defcustom jde-enable-senator t
> Michael> "Enable senator minor mode.
> Michael> This mode provides Java-aware buffer navigation and
> Michael> searching commands."
> Michael> :group 'jde-project :type 'boolean :set '(lambda (sym
> Michael> val)
> Michael> ;; Starting with version 1.4 beta 12 Semantic
> Michael> ;; can globally enable `senator-minor-mode'.
> Michael> ;; So don't override the global setting in
> Michael> ;; JDE's buffers.
> Michael> (or (and (boundp 'global-senator-minor-mode)
> Michael> global-senator-minor-mode)
> Michael> t ;; <------------------------------------ added
> Michael> by me
> Michael> (mapc
> Michael> (lambda (buff)
> Michael> (save-excursion
> Michael> (set-buffer buff) (senator-minor-mode
> Michael> (if val 1 -1))))
> Michael> (jde-get-java-source-buffers)))
> Michael> (set-default sym val)))
>
> Michael> which seems to work as expected (although i might have
> Michael> broken senator, but I don't care about that on my
> Michael> machine).
>
>This effectively disables the resetting of existing open buffers
>when a user customizes jde-enable-senator. I would rather fix the
>bug then cripple a function in order to avoid it. I've narrowed
>the problem, i.e., resetting the value of jde-enable-senator
>triggers the error:
>
> Setting JDE variables to startup values... [3 times]
> wisent-java-tags-lexer:
> Wrong type argument: stringp, nil
>
>
>to the java version of the semantic-parse-region function. However, I
>cannot get any further because the semantic java parser is implemented
>via macros that cannot be enabled for edebugging, which is the only
>way I know how to find the exact line that causes a particular
>error. (BTW, I find the heavy reliance on macros a serious problem
>with the design of semantic 2.0; it makes debugging problems with
>semantic next to impossible, at least that has been my experience so
>far.) Perhaps Eric or David can find the line that causes the error
>or suggest a way for me to find it so this bug can be fixed.
[ ... ]
Hi Paul (& co)
In semantic 2.0 we are spending brain power on a pair of goals in the
parser generation area. Make it fast, and make it easy to implement
new languages.
The best way to make a lexer fast is to cut back on the number of
regexp matches and remove as many function calls as possible.
Side-effect: funny-macros for constructing custom lexers.
On the make it easy side, Emacs Lisp is just not a great language
for making an easy-to-read lexical analyzer. The macros let you write
and mix individual analyzers in a convenient high-level way.
As for debugging, there is the `semantic-lex-debug' command. This
lets you debug the meaning of an analyzer, and is unfortunately not
what you are really looking for.
Also, it is easy to just re-evaluate the lexer construction element,
and toggle-debug-on-error to see what aspect of a given lexer is
failing, which is what I usually use.
I will try and track you down at work sometime to see what solutions
there may be.
Eric
--
Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED]
Home: http://www.ludlam.net Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
