>>> Jan Moringen <jan.moringen@...> seems to think that:
>> My brief look at your patch indicates you have the right idea here.
>> For me to accept a patch of 10 or more "new" lines, you will need to
>> have signed papers with the FSF for contributions to Emacs.
>> You can send email to copyright-clerk@... specifying your
>> intent, and they will help you out.
>I wasn't aware of that, but I will try to figure this out.
This is because CEDET will be integrated into Emacs sometime soon.
You will need to send signed papers saying that you will give the
copyright to code you write for Emacs to the FSF. You will also need
to get something signed by your business or school where they claim no
ownership. The first is easy. The second is not usually too
>> As I'm sure you have noticed, the current SRecode support for
>> regenerating tag code is proof-of-concept and does need help for many
>> more languages. I'm excited to know this is proving useful.
>Actually, the things I have tried so far worked pretty well. I will
>report any progress or problems as I go along.
>> In your patch, you ask "Is there a better way?"
>> Instead of a new section dictionary, you could simply set a value in
>> the current dictionary for CONST which would be "const ". If it is
>> not const, set CONST to be "".
>If I understand your suggestion correctly, you would assign the actual
>text (or nothing) to the dictionary key. I thought of that as well, but
>it would prevent users from "fine-tuning" whitespaces and newlines
>surrounding the "const". That is why I went with the section dictionary.
>Maybe I am thinking overly general in this case.
If "CONST" were added generically, then I would agree. In this case
it is for C++ only. Since the templates you will write will be
matched to the code adding CONST to the dictionary, it may not matter.
You may need to distinguish from something that is const and a macro,
as something like:
#define FOO 1
is also const.
>By the way, I unintendedly submitted the part which tries to store the
>fully qualified name using the FULLNAME key. As far as I can see,
>semantic-tag-full-name is not overloaded for any mode, so this part
>doesn't make any sense. (Unless I don't include the mode local
>implementation of semantic-tag-full-name, that is ;)
[ ... ]
The fullname function was added for the benefit of Java and, more
specifically JDEE. I guess it was never used. It would make a lot of
sense to add overloads for C++ also, as this is now derivable from the
:parent attribute. I think there are some cases that could take
advantage of this, such as code using semantic-analyze-unsplit-name
perhaps. I'll have to investigate that concept.
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net