To allow reusing already defined tagger for other symbols too the first
argument of your macro should be renamed as follows:
(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)...
(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?! ;-)
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
>> - the read form to convert into a tag.
>> - the corresponding start and end location in the input buffer.
> 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
> is necessary whioch can be done outside)... but anyway... it#s no
> 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
> X for symbol Y too when the definitiob is located not only in
> 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...
> 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.
> 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
> 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