Re[2]: [CEDET-devel] Bug in semantic-el.el and a nifty new parser for defalias
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2005-01-05 14:35:02
|
>>> <kla...@sd...> seems to think that: [ ... ] >Or can a type have plain string-members???? ....<some tests>..... >Appearantly because speedbar displays such a defstruct correctly... >now i found why i get a wrong-type-argument error... it comes because >currently ECB expects that all children of a semantic-tag to be a >semantic-tags too and therefore calls functions as semantic-bucketize for >the list of childrens of a semantic-tag or semantic-tag-name for a single >children of a tag.... currently these functions fails when called for plain >strings... at least semantic-bucketize fails when calls with a list of >strings instead a list of tags... > >Well, now we know the problem, the question is now how to deal with - in my >opinion there are several possible approaches: >1. Only semantic tags are allowed as childrens (:members) of a semantic-tag > (e.g. variable-tags for the members of structs (c, c++) or defstructs > (elisp) >2. ECB (and all other tools using semantic) have to take care that children of > a tag are not needed to be semantic-tags too and have to deal suitable with > them >3. cedet/semantic allows all API-functions dealing with tags to be called also > with plain strings (or whatever) and return something suitable > (e.g. (semantic-tag-name "klaus") returns "klaus" and does not fail > >I would vote for 1. but admit that i do really see if this would have >serious drawbacks?! Approach 2. would be a lot of work for tools like ECB. >Approach 3. is - hmm, how to say - also somehow clumsy and ugly..... > >What do xou think?? Hi, Plain strings have been allowable children since the first parsers I wrote. The reason was that if a language only provided a name and nothing else worth storing, then why store it? A classic example are function arguments in Lisp. When all you have is: (defun myfunc (a) "...") Why store ("a" 'variable nil nil ...) when "a" is just as useful? Admittedly, this had to be special cased throughout different parts of semantic and was a source of bugs. It may be time to retire this idea. However, you could use the function `semantic-tag-components-with-overlays' to restrict what you get to only semantic tags. In most cases I handled this case generically such that most of the routines (semantic-format, speedbar, imenu, etc) would know how to deal with both types. In speedbar, it is already important to differentiate between tags with and without overlays so it can determine if a name is clickable. It isn't much of a stretch to go one more. Perhaps a couple more options are: * Add a function `semantic-tag-components-as-tags' that converts any strings to tags. * Have `semantic-tag-components' convert any strings to tags. (though this would cause problems with code that modifies lists of components in place.) At this point, my only resistance to #1 is that the datastructures would get bigger, and I'm feeling a bit lazy of late. ;) [ ... ] >> Good points Eric! So what do you think of this definition inspired >> from what the C parser produces for typedefs? >> >> (semantic-elisp-setup-form-parser >> (lambda (form start end) >> (let ((alias (nth 1 form))) >> (semantic-tag-new-type >> ;; If not a quoted symbol evaluate the alias expression. >> ;; Signal an error if the alias is not a symbol. >> (symbol-name (if (eq (car alias) 'quote) >> (cadr alias) >> (eval alias))) >> "typedef" ;; Indicate an alias >> nil nil >> ;; The following attribute hold the aliased definition. >> :typedef (nth 2 form) >> ))) >> defalias >> ) > >well, i have tried this parser and then i get the following ECB-display of an >defalias (excerpt of the methods-browser of ECB: [ ... ] >Well, i understand Eric's points and i agree in some aspects but nevertheless >i found this display of a defalias not really satisfying - for a defvaralias >it makes more sense - but IMHO a defalias is NOT a type but just another name >for a function (refernces in C++ are also just other names!) > >IMO a defalias should ba parsed as something like a function ans a defvaralias >as something like a variable because exactly these they are. Both of them are [ ... ] Hopefully my previous email in response to David explains better what I was thinking. Thanks! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |