CEDET

Hi,

  I was about to send you a response with a similar suggestion for
semantic-go-to-tag, though I was going to suggest something like
`semantic-retrieve-tag-buffer' which used `find-file-noselect' instead
of find-file.  The perfect name would be `semantic-tag-buffer' but
that's been used.

  As far as layers are concerned, there are a lot of layers in
semantic.  There's the parser, the primitive tag layer, a set of file
finding layers.  Search layers. Analysis layers.  Mode layers.  And
finally, some applications, like imenu support.  I doubt there is a
black and white rule for determining which is which, except via
experimentation and discovery.

  Of course, the speedbar use of `semantic-go-to-tag' means that it
does exactly what speedbar wants. ;)

Eric

>>> <klaus.berndl@...> seems to think that:
>Hi,
>
>after spending some minutes more for the solution i came down with the
>idea that the best would be if semantic-go-to-tag would be renamed
>into something like semantic-tag-location whic would just return a 
>cons-cell where the car is the full pathfile-name of the tag-definition
>and the cdr the position with in this file where TAG starts. But it should 
>not perform file-opening or some cursor-moving. Of course
>semantic-tag-location should be overloadable too.
>
>With such a function tools like ECB would get all what they need and can
>then use the informations (file-name and position of tag-start) in any
>manner they need/want.
>
>If we see tools like ECB and semantic as 2 layers of a software then
>semantic is the server which just supplies informations and ECB is the
>client which uses this informations and displays them suitable. IMHO it
>would be the best if both tools would not cross this responsibility-frontier.
>For speedbar and senator the same arguments as for ECB are applicable.
>
>semantic-go-to-tag is a good example how things should not be done with
>respect of the responsibilities i described above. For semantic-imenu-goto-function
>the situation is a little bit different because this function just hooks
>into imenu and makes it working with semantic, so maybe calling find-file
>or stuff like this could be ok here.
>
>I have not checked the whole semantic-API but i suspect that there are
>other semantic function which perform some display-jobs which should be
>done by layers above semantic.
>
>Strict disjuncture of responsibilities is one of the best and most important
>design principles in software-development - at least IMHO ;-)
>
>Thoughts?
>
>Ciao,
>Klaus
>
>klaus.berndl@... wrote:
>> Hi Eric, David,
>> 
>> i just found semantic-go-to-tag which does some things ECB currently
>> implements for itself. But in general i think ECB should throw away
>> its own implementation of this job and use instead this function
>> because its 
>> overloadable - which is most important advantage. Currently ECB
>> implements 
>> quite the same stuff as the default-code of semantic-go-to-tag but of
>> course 
>> ECB could not profite from overloaded versions...
>> 
>> But to become useable by ECB `semantic-go-to-tag' has to be changed
>> slightly, especially concerning finding files. ECB needs the full
>> controll which 
>> function is used for finding files wheres semantic-go-to-tag
>> currently uses 
>> hard-coded `find-file' - but ECB sometimes wants files to being
>> openend in the 
>> other window etc...
>> 
>> So i have patched `semantic-go-to-tag' and also
>> `semantic-imenu-goto-function' 
>> as follows (these functions are currently the only ones using
>> `find-file'...): 
>> 
>> First i have introduced a new option:
>> 
>> ;; TODO: Klaus Berndl <klaus.berndl@...>: Where to put this
>> option?? ;; currently used by semantic-imenu-goto-function and
>> semantic-go-to-tag (defcustom semantic-find-file-function 'find-file
>>   "*Function used by semantic to find and display a file."
>>   :group 'semantic
>>   :type 'function)
>> 
>> This option is currently placed in semantic.el - maybe there is a
>> better place? 
>> 
>> Then i have ajusted `semantic-go-to-tag' and also
>> `semantic-imenu-goto-function' (i have only replaced the calls to
>> find-file 
>> by a more flexible solution):
>> 
>> (define-overload semantic-go-to-tag (&optional tag parent)
>>   "Go to the location of TAG.
>> TAG may be a stripped element, in which case PARENT specifies a
>> parent tag that has position information.
>> Different behaviors are provided depending on the type of tag.
>> For example, dependencies (includes) will seek out the file that is
>> depended on (see `semantic-dependency-tag-file'."
>>   (or tag (setq tag (car (semantic-find-tag-by-overlay nil))))
>>   (unless (and (eq (semantic-tag-class tag) 'include)
>>                (let ((f (semantic-dependency-tag-file tag))
>>                      (find-file-function (or (and (fboundp
>>                                                  
>>                                             
>>                  semantic-find-file-function)
>>     semantic-find-file-function) 'find-file))) (if f (funcall
>>      find-file-function f)))) (:override (if (semantic-tag-buffer tag)
>>          ;; If the tag has no buffer, it may be deoverlayed.
>>          ;; Assume the tool doing the finding knows that we came
>>          ;; in from a database, and use the current buffer.
>>          (set-buffer (semantic-tag-buffer tag)))
>>      (if (semantic-tag-with-position-p tag)
>>          ;; If it's a number, go there
>>          (goto-char (semantic-tag-start tag))
>>        ;; Otherwise, it's a trimmed vector, such as a parameter,
>>        ;; or a structure part.
>>        (if (not parent)
>>            nil
>>          (if (semantic-tag-with-position-p parent)
>>              (progn
>>                (if (semantic-tag-buffer parent)
>>                    ;; If this parent tag has no buffer, then it
>>                    ;; may be deoverlayed.
>>                    (set-buffer (semantic-tag-buffer parent)))
>>                (goto-char (semantic-tag-start parent))
>>                ;; Here we make an assumption that the text returned by
>>                ;; the parser and concocted by us actually exists
>>                ;; in the buffer.
>>                (re-search-forward (semantic-tag-name tag) nil
>> t)))))))) 
>> 
>> (defun semantic-imenu-goto-function (name position &optional rest)
>>   "Move point associated with NAME to POSITION.
>> Used to override function `imenu-default-goto-function' so that we
>> can continue 
>> to use overlays to maintain the current position.
>> Optional argument REST is some extra stuff."
>>   (if (semantic-overlay-p position)
>>       (let ((os (semantic-overlay-start position))
>> 	    (ob (semantic-overlay-buffer position)))
>> 	(if os
>> 	    (progn
>> 	      (if (not (eq ob (current-buffer)))
>> 		  (switch-to-buffer ob))
>> 	      (imenu-default-goto-function name os rest))
>> 	  ;; This should never happen, but check anyway.
>> 	  (message "Imenu is out of date, try again. (internal bug)")
>> 	  (setq imenu--index-alist nil)))
>>     ;; When the POSITION is actually a pair of numbers in an array,
>>     then ;; the file isn't loaded into the current buffer.
>>     (let ((find-file-function (or (and (fboundp
>>                                        semantic-find-file-function)
>>                                   semantic-find-file-function)
>>       'find-file))) (if (vectorp position)
>>           (let ((file (aref position 0))
>>                 (pos (aref position 1)))
>>             (and file (funcall find-file-function file))
>>             (imenu-default-goto-function name pos rest))
>>         ;; When the POSITION is the symbol 'file-only' it means that
>>         this ;; is a directory index entry and there is no tags in
>>         this ;; file. So just jump to the beginning of the file.
>>         (if (eq position 'file-only)
>>             (progn
>>               (funcall find-file-function name)
>>               (imenu-default-goto-function name (point-min) rest))
>>           ;; Probably POSITION don't came from a semantic imenu.  Try
>>           ;; the default imenu goto function.
>>           (condition-case nil
>>               (imenu-default-goto-function name position rest)
>>             (error
>>              (message "Semantic Imenu override problem. (Internal
>>              bug)") (setq imenu--index-alist nil)))))
>>       )))
>> 
>> 
>> Maybe there are additional function where this new option could be
>> used - 
>> don't know?
>> 
>> With this new option and the changed functions tools like ECB could
>> have 
>> full-controll in which window (or even frame) semantic would "find"
>> files! 
>> What do you think?
>> 
>> Ciao,
>> Klaus
>> 
>> 
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users. 
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
>> _______________________________________________
>> Cedet-devel mailing list
>> Cedet-devel@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
>

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

>>> <klaus.berndl@...> seems to think that:
>Hi,
>
>Eric M. Ludlam wrote:
>>>>> <klaus.berndl@...> seems to think that:
>>> Well, i makes also sense calling semantic-go-to-tag withsuch a
>>> faux-tag - and i'm not sure if this is already handled by the new
>>> implementation? 
>> 
>> Hi Klaus,
>> 
>>   It must have been a long day for me because I don't quite
>> understand.  Could you please explain the purpose of a faux tag in
>> ECB?  I am assuming it is a tag that represents several real tags that
>> happen to represent the same item?  How would I exercise this feature
>> from ECB?
>
>well, let me explain faux-tags - funny because your semantic generates
>faux-tags ;-)

I am familiar with the faux tags from semantic-adopt-external-members.
I thought you were making your own faux tags for some reason.

  [ ... ]
>So, the class and the method-prototypes are defined in test.h whereas the
>implementation of the class faux resides in test.cpp.
>
>So when you now open test.cpp in ECB for example then ECB runs internaly
>semantic-adopt-external-members which creates a somehow virtual type-tag with
>name "Faux" (tag-class is 'type) and stores the property 'faux at this tag.
>The term faux comes from you - see `semantic-adopt-external-members'.
>What you then see in ECB is:
>
>[-] Faux
> |  +berndl_test_function (arg1:int, arg2:int):void
> `- +klaus_test_function (arg1:int, arg2:int):int
>
>But the tag "Faux" can not be found in test.cpp but is is there so the methods
>of class Fuax can be grouoped under a type-tag.

Ok, so you are using the faux tags from adopting external members, but
you want there to be meaning when the user clicks on it.

>Well, when the user now clicks onto the "Faux"-tag in ECB then ECBN/semantic should
>recognize that this is such a virtual "faux"-tag (created by semantic-adopt...)
>and then try to find the origin tag for this - means it should find via semanticdb
>the real(!) tag "Faux" defined within test.h.
>
>So, when semantic-go-to-tag is called weith that faux tag named "Faux" from test.cpp(!!)
>then it should be so smart to check that this is not a real tag defined in test.cpp but
>only a virtual grouping tag which is defined elsewhere and therefore try to find it
>via semanticdb...
>
>is this now understandable?
  [ ... ]

I think perhaps what is needed is for there to be a method to convert
faux tags into real tags via semanticdb.

semantic-sort.el already uses semanticdb to find things to adopt for
classes discovered in a file, but it does not do this the other way
around for the constructed faux tags.  This would probably be the
simplest solution as semantic-go-to-tag and its relations do not
currently use semanticdb for anything.

That said, I still don't know why your routine is so large.  Here is a
sample I whipped up that might translate a faux tag into real tags:


(defun semantic-tag-external-class-default (tag)
  "Return a list of real tags that faux TAG might represent.
See `semantic-tag-external-class' for details."
  (if (and (fboundp 'semanticdb-minor-mode-p)
	   (semanticdb-minor-mode-p))
      (let* ((semanticdb-search-system-databases nil)
	     (m (semanticdb-find-tags-by-class 
		 (semantic-tag-class tag)
		 (semanticdb-find-tags-by-name (semantic-tag-name tag)))))
	(semanticdb-strip-find-results m t))
    ;; Presumably, if the tag is faux, it is not local.
    nil
    ))

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org