RE: [CEDET-devel] rewritten semantic-elisp-use-read so it is now smart and driven by symbol-properties!

[Berndl, K. <kla...@sd...>]

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