CEDET

One addition:

To allow reusing already defined tagger for other symbols too the first
argument of your macro should be renamed as follows:
macro:

(defmacro semantic-elisp-use-tagger (tagger-or-symbol &rest symbols)
  ""
  (let ((sym (make-symbol "sym")))
    `(dolist (,sym ',symbols)
       (put ,sym 'semantic-elisp-tagger ',tagger-or-symbol))))


Or should we define two different macros with names

(defmacro semantic-elisp-define-tagger (tagger &rest symbols)...

and

(defmacro semantic-elisp-reuse-tagger (taggered-symbol &rest symbols)...

Of course alwaays assumed you do not completely deprecate my vote
for such a reuse-tagger-feature?! ;-)

Thought?

Ciao,
Klaus

Berndl, Klaus wrote:
> Hi David,
> 
> thanks for giving fast feedback!
> 
>> However, it seems to me that too much hard-coding the arguments
>> passed to the tagger is not necessary and not generic enough.  I
>> would prefer that each tagger function is responsible of extracting
>> what information it needs from the read form it receives.
>> 
>> Based on your idea, I did this implementation which IMHO is simpler
>> and seems to work as expected.  The tagger function is passed 3
>> arguments: 
>> 
>> - the read form to convert into a tag.
>> - the corresponding start and end location in the input buffer.
>> 
>> WDYT?
> 
> If you refer to my first approach with giving also 3 arguments to the
> tagger (the read lisp-objekt, the keyword-symbol and the name after
> this symbol) but not the start- and end-pos in the input-buffer then
> i agree 
> with you --> not generic enough...
> 
> But in my latest code-version i sent to you today i can not see whay
> my 5-args approach shoud be less generic then yours -
> 
> i give these args to the tagger:
> 
> 1. the read form (your 1. arg)
> 2. the keyword-symbol
> 3. the name-after-keyword
> 4. start-pos (your 2. arg)
> 5. end-pos (your 3. arg)
> 
> So my tagger can do all what yours can do ;-)
> But my arguments 2 and 3 are for conveniance for tagger-programmers
> because why each tagger should extract the keyword and the following
> name (especially for the latter one sometimes some conversio to a
> string 
> is necessary whioch can be done outside)... but anyway... it#s no
> problem 
> for me to live with your 3-arg approach!
> 
> But i want to vote for my recursive tagger-definition-feature!
> You solution does not allow to use an already defines tagger for
> symbol 
> X for symbol Y too when the definitiob is located not only in
> semantic-el 
> but in a different thirdparty-package like ecb...
> 
> Why a package-author should rewrite the complete tagger for his own
> symbols when he can use already by semantic defined taggers...
> example: 
> ECB defines a new macro `defecb-multicache' which should be parsed
> exactly as a `defvar'. Why i should fully copy the tagger for defvar
> from semantic-el when i could simply write
> 
>     (semantic-elisp-set-tagger 'defecb-multicache 'defvar)
> 
> This feature i really miss in your approach because without this i
> have to duplicate code of semantic-internals without need (suppose
> you guys change 
> in the future the API for tag-generation....then with your aproach
> ECB would to have to rewrite the tagger for `defecb-multicache' too
> otherwise it would not longer work. But with my "use already defines
> tagger from another symbol" the parsing of `defecb-multicache' would
> be robust against API-changes because the only thing i define with
> 
> is, that i say "parse a defecb-multicache exactly as defvar".
> 
> So IMHO the best solution would be:
> 
> - your macro-approach with &rest symbols because this makes defining
>   a tagger for more symbols easy and looks good ;-)
> - An approach where at least the read-lispobject and the start- and
>   end-pos in the input-buffer are parsed as argments to a tagger
> - my transitive-tagger-definition-feature which allows to reuse
>   already defined taggers within foreign packages.
> 
> 
> To make a long story short ;-): using my original
> semantic-elisp-get-tagger function within your solution would be fine
> for me. 
> 
> WDYT?
> 
> Ciao,
> Klaus
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement
> on 
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel