>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>>>> David Hansen <david.hansen@...> seems to think that:
>>>(defun foo ()
>>>gets highlighted with `semantic-unmatched-syntax-face'. Note
>>>this doesn't seem to be limited to the '\' reader macro but also
>>>some others i tried. See "2.4.8 Sharpsign" in the Hyper Spec for
>> The semantic Lisp parser uses Emacs' `read' to do the parsing.
>> So basically, to get this to work for Lisp (not Emacs Lisp,) we
>> need to write a new parser. It would likely be similar to the
>> parser which is pretty simple.
>You probably know this well but, as a remainder, unlike in Scheme
>or Emacs Lisp, reader in Common Lisp is programmable. Of course,
>that doesn't mean that a better-than-current parser that could
>handle the default syntax and maybe a few common ways to extend the
>syntax would be a bad thing. That's really all anyone can ask.
>Maybe it could also be used as a basis for a cl-indent.el
The cedet parsers are generally targeted at tagging information so
there isn't much detail inside function bodies where good indentation
is needed. Adding that type support is something I'd like to see
happen someday though for a wide range of other types of tools.
>Then again I am surprised that someone has even tried to use
>Semantic with CL. Some of the most important functionality (in my
>opinion; completion, jumping to definitions/callers/etc) provided
>by CEDET tools is already provided by SLIME (the currently "hip"
>package that integrates CL implementations to Emacs) in a way
>specific to CL by talking to the external CL process. I don't know
>if Semantic could somehow interface to SLIME (I suspect this would
>correspond to whatever you guys have been talking about Java and
>beanshell stuff recently, although I haven't paid much attention to
>that so this is wild speculation) but either way I doubt that there
>is much interest to this sort of marriage (that's just my
>suspicion, I can't speak for other CL developers).
You can chop semantic into 3 layers. There is the middle layer that
defines what a TAG looks like, manages tags, and APIs for saving,
restoring, and searching tags. There are also tools for creating
class trees and attempting to analyze a particular bit of code.
This layer depends on the parser layer. Parsers can be written in by
(bovine) format or wy (wisent) format which are Semantic's built in
aids for writing parsers. You can also write your own using any
technique you want, such as using regexps, like the texinfo and html
Lastly, there are the applications that sit on top of the semantic
APIs, many of which come with semantic.
The basic idea is that you can take some new language, define a parser
using any mechanism you want, override a few language specific
functions, and possibly write a backend for a system database of tags,
and have all the semantic applications work for that application. On
the other side, if you want to write a new application for you
language, if your language is supported, you can write it against the
Semantic API, and know it will work pretty well for any language
semantic eventually supports.
My theory has always been that the more languages supported by
cedet/semantic, the more folks will use the core parts of cedet, and
over time, the better the applications that sit on it will be for all
languages, not just for the languages that hard-core Emacs hackers use.
>Personally I only wish that some day Semantic would provide for C++
>some of the functionality SLIME provides for Common Lisp (obviously
>not interactivity which is SLIME's main point but at least working
>completion and jump to definition/callers/etc based on static
[ ... ]
Me too. It's been getting better as time marches on and as I,
personally, learn more C++. The CVS version supports much more than
the currently released version (1.0pre3), and the new ebrowse DB
support makes parsing lots of header files for the system, or your
project a quick process.
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