RE: [CEDET-devel] rewritten semantic-elisp-use-read so it is now smart and driven by symbol-prope
Brought to you by:
zappo
From: Berndl, K. <kla...@sd...> - 2004-09-20 13:31:49
|
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 > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel |