Re: Semantic questions for my language mode
Eric Ludlam <[email protected]> Thu, 12 Feb 2015 21:20:42 -0500
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
On 02/11/2015 12:33 PM, Isak Andersson wrote:
>
> On 11/02/2015 01:35, Eric Ludlam wrote:
>> On 02/10/2015 01:07 PM, Isak Andersson wrote:
>>>
>>> First, as auto indentation is quite the task since it pretty much
>>> requires some parsing to work reliably, I was wondering if it's possible
>>> to perhaps use the semantic parser to build an indentation system with
>>> and how one would go about doing so if it's possible.
>>>
>>> Second, I was hoping it would be possible to somehow utilize semantic
>>> for building the syntax highlighting system as well. For example
>>> highlighting things based on what kind of type they are (function or
>>> variable). Boo also allows you to add new keywords by using macros, so
>>> if I could parse the project and detect macros and start highlighting
>>> macro invokations as keywords automatically (rather than manually like
>>> you do with the current boo-mode) that would be super swell. Would it be
>>> possible to do this?
>>
>> Both those tasks are theoretically possible, but there is no example
>> or infrastructure to support using the parser for indentation and
>> coloring.
>>
>> The premis is pretty simple - in the actions for rule matching, you
>> could apply some additional logic, such as building a syntax tree you
>> could then use to place color. In practice, I suspect you would need
>> some infrastructure outside of the parser to do the work, such as the
>> way to build a colorizing syntax tree.
>>
>> I don't know boo, but you might be able to do indentation by creating
>> a typical tag parser, and using the tags to start/end indentation
>> regions, and possibly the semantic-ctxt-* overloads for parts of your
>> code.
[...]
> Do you think there is an interest to add such infrastructure to CEDET?
Possibly. The problem is writing a fully correct language parser can be
a big task. The tagging parsers usually skip all the code in the
functions, but font-lockers still want to highlight in there, so they
are an incomplete starting point.
> By typical tag parser you mean typical semantic tag parser (would be a
> shame to have to have two tag parsers :p)?
Yes, a typical tag parser, and the tag output results can be used to
find the symbols you might want to add to font lock.
> I'll see if i can find the C parser so that I can examine how it does
> what you described.
The C parser is using an extra lex-spp utility so it may be opaque how
it works. A simplified view would be:
(add-hook 'semantic-after-toplevel-cache-change-hook 'my-update-function)
(add-hook 'semantic-after-partial-cache-change-hook 'my-update-function)
(defun my-update-function (newbuffertags)
"Update keywords for BOO"
(when newbuffertags
(let ((matches (semantic-find-tags-by-class 'macro newbuffertags)))
(dolist (M matches)
(my-add-match-to-some-list (semantic-tag-name M))))))
which is probably better than the C macro handler since this is
interfacing with an external tool.
Eric
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/