[CEDET-devel] Re[1]: Foreign tags (was Using lowercase in info @var markups)

[Eric M. L. <er...@si...>]

>>> David PONCE <dav...@wa...> seems to think that:
>Hi Eric,
>
>[...]
>> If the only reason not to use `define-overload' is because of
>> senator-parse, I suspect the newer parser will keep things better
>> updated now.  Though you now remind me that if (semantic-current-tag)
>> is called and point is on an overlay indicating edits, then we should
>> force a reparse.
>
>I am not convinced that `semantic-current-tag' should force a
>re-parse.  Depending on other changes, that might give some weird
>situations, where the current tag removes itself from the cache, or
>move it on a different buffer location not accessible from the
>`point'.

Perhaps we should follow this type of rule:

1) API programming routines never try to reparse the buffer.. except, of
   course, for API routines which are the the reparsing, of course.

2) User level commands should start off reparsing the buffer if they
   interact with the tagging system.

Since overload methods are API fcns, they would not call a reparse
method.

>And, if we go to do that it would be probably better to do it at a
>very low level, when accessing to a tag component for example.
>
>Anyway, I can't see why `senator-parse' would prevent to use
>`define-overload'?

I do not know.  The function you proposed was not using it, and I was
proposing that perhaps it should.

>[...]
>> The whole "foriegn-tag" thing could be turned into an object, with
>> `semantic-foriegn-tag-p' and the like.
>> 
>> This could be done either via EIEIO, or perhaps something like:
>> 
>> (setq newtag (semantic-copy-tag TAG))
>> (semantic--tag-put-property newtag :foreign t)
>> (semantic--tag-put-property newtag :buffer (current-buffer))
>> (semantic--tag-put-property newtag :mode major-mode)
>> (semantic--tag-put-property newtag :etc other-stuff)
>> 
>> That would let you change how many interesting things are stored more
>> easily since order is no longer important.
>
>I thought to that too, and using properties looks like a simple and
>natural way to record such informations.
>
>I wonder if it would make sense to automatically set the :mode
>property with the major mode used to produce the tag, like we already
>set the `reparse-symbol' property?

We need to keep the data structure as small as possible for normal
operations.  I do think things like :mode or :filename could be set
when a tag is being cloned for use elsewhere.  My emacs gets mighty
large on my MATLAB C++ projects and things can slow down because of it.

>It could be useful in multi-modes buffers analyzed with different
>parsers depending on context.

I've been contemplating this situation also.  I was thinking a tag
roughly like this:

(TAG "" 'embeddedlanguage :mode foo-mode :members (EXPANDALL ...))

In HTML, you might have this:

<INPUT name="foo" onClick="clickedIt()">

and HTML completion would notice if you were on onClick's value, and
know to search only in embedded language tags for the clickedIt name.

>For example, in grammars, I could imagine to delegate parsing of
>prologue, epilogue and perhaps semantic actions code to the Elisp
>parser, through an ad-hoc EXPANDFULL-like macro.

Hmmm, as above I would guess.

>Then, by examining a tag it would be possible to know which mode, so
>parser, etc., produced it, and use that information for
>auto-completion, re-parse, and so on.  __ I wonder if it would be a
>tricky task to adapt semantic-edit for incremental contextual re-parse
>;-) __

I think the layered approach above does this too, but with fewer cons cells.

I think it might be easier to program against the layers as well, but
I am not certain.

Eric

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org