>>> David PONCE <david.ponce@...> seems to think that:
>> I agree with your assessment of the -update- in the name, but
>> `semantic-decorate-tags' sounds like something that could be really
>> useful when this function is very specific about apply decorations
>> for semantic-decoration-mode which is less useful.
>> Maybe I should have named all those internal functions using the
>> semantic-decorate--* convention used elsewhere for internal
>I worked a bit more on the new semantic-decoration-mode, and wrote
>the following cleaned up implementation. For now, I renamed the library
>semantic-decoration-mode to avoid confusion.
I'm at work at the moment and cannot run it, but it looks good.
>The main changes I did are:
>- elimination of implementation terms like primary/secondary overlay,
> replaced by primary tag highlighting versus independent decoration.
I had those two modes (the attribute, and boundary modes) separate
and so different for so long it never occurred to me that the
interface was essentially the same. Amazing.
>- to provide a basic API to manage independent decorations,
> introducing a level of abstraction from tags' secondary overlays.
This was much needed. Nifty.
>- unification of the notion of decoration style. This simplifies the
> interface, as the distinction between primary and secondary
> decoration style appeared to me not really necessary. The consequence is
> that there is only one `define-semantic-decoration-style' to define
> any kind of decoration style. The distinction between a primary
> highlighting and an independent decoration being actually handled by
> the `NAME-highlight' overload.
>I finally tried to find a good naming scheme for the various
>functions in that library. It would be nice if you could have a look
>at the code and give me your feedback.
I will examine this more closely soon as it still needs a bit of
customization magic and perhaps a senator menu. It also needs some
smarts about the call to `semantic-fetch-tags' which needs to be
postponed till after a buffer is displayed.
>FYI, I tried it in Java and Elisp buffers, and it seems to work
>nicely ;-) To try it, just load the library and enable/disable
[ ... ]
>(defun semantic-decorate-clear-tag (tag &optional deco)
> "Remove decorations from TAG.
>If optional argument DECO is non-nil, remove only that decoration."
> (assert (or (null deco) (semantic-decoration-p deco)))
> ;; Clear primary decorations.
> ;; For now, just unhighlight the tag. How to deal with other
> ;; primary decorations like invisibility, etc. ? Maybe just
> ;; restoring default values will suffice?
> (semantic-unhighlight-tag tag)
> tag (or deco 'semantic-decoration)))
This function no longer recurses on tag members. Is this happening
elsewhere and I just can't see it?
As for your comment about invisibility, etc, those decorate api calls
could each leave a trace on how to remove itself late. I will
contemplate this some more.
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