>>> David PONCE <david.ponce@...> seems to think that:
>> Semantic does not store the positions of the individual lexical
>> tokens of the items it parsers. As such, the senator isearch mode has
>> to guess where the name is via a simple search across the tag. This
>> has the effect of narrowing the search to just the named fields.
>> What you describe doesn't really surprise me, but I'm not sure how
>> to fix it without really slowing things down. Perhaps David (who
>> first wrote it) has an idea.
>I agree it is a limitation of the current tag design. The only
>robust solution I can see would be to have a new property like
>:name-location that gives the (start . end) positions of the tag name
>(maybe relative to the start position of the tag).
>`senator-search-tag-name' could use it if present or use the current
>regexp based heuristic otherwise. Anyway a such change should be
>postponed for after the release (it is probably worth adding it to the
>TO DO list).
[ ... ]
An interesting idea. I've been fiddling with a code
generator/modifier that uses semantic and ran into the same problem.
Here is an example: User changes data type of some thing via
structured GUI or interface (ie, refactoring type tool). How to you
know where the data type text is in a language independent way?
I haven't actually gotten that far in my coding. (I'm still battling
tempo issues for generic new-code output.) My thinking in this
regard is still a bit jumbled, but I'll let you see my thought process
and perhaps a fun idea will emerge.
First, getting position information is basically 'extra' information
not usually needed. Idea: Separate pass on a specific tag (similar to
incremental parser) asking for "extra information". This requires
hacking the existing grammars, and having new properties.
Second thought. Position info is just like what you would need to
replace font-lock. Idea: Would a font-lock replacement using
text-properties do what I need for the code-generator? Probably. It
would also solve this isearch problem. This tactic definitely depends
on wisent, as the bovine parser doesn't have the same bounds
information available as does wisent.
The other issue was with code and code tags. It is unclear to me what
the right idea is. Some sort of text is needed from a GUI
perspective, but that could be solved in `semantic-format-tag-name'.
Thus leaving the name blank would require that second change to keep
tools like ECB and Imenu happy. This seems like a reasonable
As I'd like to have the 'code' portion of function tags marked by an
overlay to assist in simplifying some issues in the incremental parse,
solving this would be useful.
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