CEDET

>>> Thomas Geffert <tgf-news2003@...> seems to think that:
>Hello,
>
>I cannot get semantic to parse my C/C++ files correctly with XEmacs.
>
>I'm using XEmacs 21.4 (patch 16) from Debian testing with the current 
>cedet-1.0beta3b. I also tried the older semantic-1.4.4 with the same 
>results.
>
>Due to debugging the parsing with semantic-debug I found that all 
>punctuation codes are not recognized. That means that code like
>
>#include <stdio.h>
>
>fails because the hash sign is not recognized as HASH and
>
>int start=0;
>
>fails because the equal sign is not recognized as EQUAL.
>
>Using cedet/semantic from GNU Emacs 21.3.1 the parsing works correctly.
>
>The output of (semantic-lex (point-min) (point-max)) looks the same in 
>both XEmacs and Emacs.
>
>To be sure that no other XEmacs packages are doing any harm I started 
>XEmacs with the -vanilla option, but this didn't changed anything.
>
>Does anybody has an idea why the parsing within XEmacs fails? Is anybody 
>using cedet/semantic successfully with the Debian XEmacs version from 
>testing?
  [ ... ]

Hi,

The lexical analyzer often uses the local syntax table to generate the
lexical tokens.  During this step, keywords are also converted into
keyword symbols.  Since you mention that this step seems ok, we need
to look at the next step.

Punctuation symbols like HASH are placed into a punctuation symbol
table.  In the case of C the hash regexp looks like this: "\\b[#]\\b"

This regexp is then spliced directly into the grammar for the C
language.  (The wisent parser has a better mechanism.)

Two things to try as an experiment are these:

1) Test the regexp:
  * put cursor on the # in the #include.
  * M-: (looking-at "\\b[#]\\b") RET
  -- should return t

2) Test string-match on the regexp.
  * from anywhere in the C file
  * M-: (string-match "\\b[#]\\b" "#") RET
  -- should return 0

If either of those fails, then there is some regexp matching issue.
If they pass, I an not really sure what the dilemma might be.

Eric

-- 
          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 wrote:
>>>>Thomas Geffert <tgf-news2003@...> seems to think that:
>>
>>Hello,
>>
>>I cannot get semantic to parse my C/C++ files correctly with XEmacs.
[...]
> Punctuation symbols like HASH are placed into a punctuation symbol
> table.  In the case of C the hash regexp looks like this: "\\b[#]\\b"
> 
> This regexp is then spliced directly into the grammar for the C
> language.  (The wisent parser has a better mechanism.)
> 
> Two things to try as an experiment are these:
 >
> 1) Test the regexp:
>   * put cursor on the # in the #include.
>   * M-: (looking-at "\\b[#]\\b") RET
>   -- should return t

This doesn't work, it returns nil. But it works on a = with M-: 
(looking-at "\\b[=]\\b") RET. But the equal sign is not recognized by 
the parser, too.

> 2) Test string-match on the regexp.
>   * from anywhere in the C file
>   * M-: (string-match "\\b[#]\\b" "#") RET
>   -- should return 0

It returns nil too, even width the # replaced by = .
It works with (string-match "\\b[#]\\b" "x#x") which returns correctly 
1, So it seems that \b doesn't recognize a word boundary on string 
start/end.

The documentation of my Emacs21 explains \b in the same way as the 
XEmacs documentation, but adds:

| `\b' matches at the beginning or end of the buffer regardless of
|  what text appears next to it.

This sentence is missing in the XEmacs regexp documentation.

I'm wondering if this doesn't work only with my XEmacs or if it is 
rather a general XEmacs problem.

Do you have any ideas how to solve this problem?

  Thanks for your help,

  Thomas