CEDET

On 12/02/2011 08:48 PM, Brendan Miller wrote:
> I'm trying to get a handle on the architecture of cedet and have some
> questions about how the various bits relate to one another.
>
> 1. How are senator and semantic-ia related?
>
> Both packages seem to have some overlap in functionality, e.g. jump to
> definition and completion. Personally, I've had better luck with
> semantic-ia. How are they different, and what is one good for vs
> another?

The difference is mainly historical.  Senator came first, and some 
simple completion and jumping mechanisms were created there.

As the "smart completion" engine slowly started forming, that utility 
was wrapped up in semantic-ia.  The idea was that the functions in 
semantic-ia would be super-simple examples on how to use the analyzer to 
accomplish different tasks.  Unfortunately, those functions turned into 
the features of choice, and slowly gained features, making them less 
simple from a learning perspective.

I then wrote semantic-complete.el, the home of complex completion 
commands.  Senator was adapted to start using some of those.

So now there is a mix of odd stuff, and no unified view.

> 2. Same question, but with semantic-complete
>
> The semantic complete-package also seems to overlap with the last
> two... How does this fit in the architecture relative to them?

My goal was to create a library so someone else could create cool 
commands and programs that had symbol completion, and smart code 
analysis.  My simple examples turned into those commands for most.

> 3. Mark rings.
>
> In etags, I find-tag in conjunction with pop-tag-mark to navigate.
> etags uses an underlying mark ring, find-tag-marker-ring, to allow
> this. Are there any mark rings in any of the jump to definition
> facilities that I just haven't seen?
>
> My above questions were motivated partially wondering what the best
> location to add this mark tracking to is. I'm wondering if I need to
> add it to both senator and semantic-ia functions.

Ideally there would be a function for pushing a new tag mark, but there 
isn't one in Emacs, but there is one in XEmacs.  In Emacs, I think the 
feature is buried in the etags code, and I never dug in to see if I 
could join in the fun with Semantic commands.

It would be nice if that could be done.  In place of the tag ring, the 
global mark ring can be used instead, or you can try 
semantic-mru-bookmark mode.

Eric

On Fri, Dec 2, 2011 at 7:03 PM, Eric M. Ludlam <ericludlam@...> wrote:
> On 12/02/2011 08:48 PM, Brendan Miller wrote:
>> 3. Mark rings.
>>
>> In etags, I find-tag in conjunction with pop-tag-mark to navigate.
>> etags uses an underlying mark ring, find-tag-marker-ring, to allow
>> this. Are there any mark rings in any of the jump to definition
>> facilities that I just haven't seen?
>>
>> My above questions were motivated partially wondering what the best
>> location to add this mark tracking to is. I'm wondering if I need to
>> add it to both senator and semantic-ia functions.
>
>
> Ideally there would be a function for pushing a new tag mark, but there
> isn't one in Emacs, but there is one in XEmacs.  In Emacs, I think the
> feature is buried in the etags code, and I never dug in to see if I could
> join in the fun with Semantic commands.
>
> It would be nice if that could be done.  In place of the tag ring, the
> global mark ring can be used instead, or you can try semantic-mru-bookmark
> mode.
>

I spent some time digging around in the etags code a while ago. It
turns out it's pretty easy. In GNU emacs pushing to the etags mark
ring is done like this:

(ring-insert find-tag-marker-ring (point-marker))

This is the ring of marks of locations where you invoked your "jump to
definition" command (find-tag in the case of etags).

Etags also keeps track of the locations that you jumped to after
invoking find-tag. It looks like it's possible to use this other ring
to move forwards in history, although I haven't tried this. You add to
the second ring like this:

(ring-insert tags-location-ring (point-marker))

I wrote a simple wrapper of semantic-ia-fast-jump that adds support
for this mark rings like this:
(defun c5-alt-find-definition ()
  (interactive)
  (let ((jump-src-marker (point-marker)))
    (semantic-ia-fast-jump (point))
    ;; we never invoke these next two lines if semantic-ia-fast-jump throws
    ;; an error.
    (ring-insert find-tag-marker-ring jump-src-marker)
    (ring-insert tags-location-ring (point-marker))))

I was thinking of incorporating some logic like this directly into
semantic-ia, or whichever package is most appropriate.

I guess cedet needs to support xemacs though? That makes things a
little more complicated.

I downloaded the source for xemacs and took a look at their etags
implementation. It looks a bit different than gnu emacs.

GNU Emacs has a generic "ring" datastructure implemented in ring.el,
which is used for etags, and other things that need to keep history.

xemacs doesn't seem to have any ring.el, and looks like xemacs etags
uses a one off stack.

One strategy would be to write some code that papers over the two
implementations. The other would be to not use the etags tag history
at all, and have cedet keep its own history. If I get time I'll play
around with both possibilities and see which is nicer...

Brendan Miller writes:
> I guess cedet needs to support xemacs though?

I wouldn't worry much about that. CEDET hasn't worked on xemacs for
quite some time now, and I can't remember seeing any complaints about
that (quite the contrary, actually).  Eric may see this differently,
though.

-David

On 12/03/2011 01:37 AM, Brendan Miller wrote:
> On Fri, Dec 2, 2011 at 7:03 PM, Eric M. Ludlam<ericludlam@...>  wrote:
>> On 12/02/2011 08:48 PM, Brendan Miller wrote:
>>> 3. Mark rings.
>>>
>>> In etags, I find-tag in conjunction with pop-tag-mark to navigate.
>>> etags uses an underlying mark ring, find-tag-marker-ring, to allow
>>> this. Are there any mark rings in any of the jump to definition
>>> facilities that I just haven't seen?
>>>
>>> My above questions were motivated partially wondering what the best
>>> location to add this mark tracking to is. I'm wondering if I need to
>>> add it to both senator and semantic-ia functions.
>>
>>
>> Ideally there would be a function for pushing a new tag mark, but there
>> isn't one in Emacs, but there is one in XEmacs.  In Emacs, I think the
>> feature is buried in the etags code, and I never dug in to see if I could
>> join in the fun with Semantic commands.
>>
>> It would be nice if that could be done.  In place of the tag ring, the
>> global mark ring can be used instead, or you can try semantic-mru-bookmark
>> mode.
>>
>
> I spent some time digging around in the etags code a while ago. It
> turns out it's pretty easy. In GNU emacs pushing to the etags mark
> ring is done like this:
>
> (ring-insert find-tag-marker-ring (point-marker))
>
> This is the ring of marks of locations where you invoked your "jump to
> definition" command (find-tag in the case of etags).
>
> Etags also keeps track of the locations that you jumped to after
> invoking find-tag. It looks like it's possible to use this other ring
> to move forwards in history, although I haven't tried this. You add to
> the second ring like this:
>
> (ring-insert tags-location-ring (point-marker))
>
> I wrote a simple wrapper of semantic-ia-fast-jump that adds support
> for this mark rings like this:
> (defun c5-alt-find-definition ()
>    (interactive)
>    (let ((jump-src-marker (point-marker)))
>      (semantic-ia-fast-jump (point))
>      ;; we never invoke these next two lines if semantic-ia-fast-jump throws
>      ;; an error.
>      (ring-insert find-tag-marker-ring jump-src-marker)
>      (ring-insert tags-location-ring (point-marker))))
>
> I was thinking of incorporating some logic like this directly into
> semantic-ia, or whichever package is most appropriate.
>
> I guess cedet needs to support xemacs though? That makes things a
> little more complicated.
>
> I downloaded the source for xemacs and took a look at their etags
> implementation. It looks a bit different than gnu emacs.
>
> GNU Emacs has a generic "ring" datastructure implemented in ring.el,
> which is used for etags, and other things that need to keep history.
>
> xemacs doesn't seem to have any ring.el, and looks like xemacs etags
> uses a one off stack.
>
> One strategy would be to write some code that papers over the two
> implementations. The other would be to not use the etags tag history
> at all, and have cedet keep its own history. If I get time I'll play
> around with both possibilities and see which is nicer...
>

I think you will find that semantic-ia-fast-jump-helper has the xemacs 
impl of pushing a tag onto the tag mark ring with the function 
'push-tag-mark.

That would be a logical place to add the Emacs version.  If there are 
additional places that should have it added (via semantic-complete, etc) 
then a helper would be a good idea.

Thanks for looking into it for us!
Eric

On 12/03/2011 04:38 AM, David Engster wrote:
> Brendan Miller writes:
>> I guess cedet needs to support xemacs though?
>
> I wouldn't worry much about that. CEDET hasn't worked on xemacs for
> quite some time now, and I can't remember seeing any complaints about
> that (quite the contrary, actually).  Eric may see this differently,
> though.

CEDET *almost* compiles on XEmacs, and does work when you ignore what 
doesn't compile.  I couldn't figure out the build issue, and someone was 
trying to fix the compilation issue, but they didn't get it either.  A 
tenacious user can go back and open the files in XEmacs, and compile 
them from an interactive session to finish the job.  Thus, very hard to 
debug.

In the grand scheme of things though, I don't know if we have any 
dedicated XEmacs users.

Eric

Eric M. Ludlam writes:
> On 12/03/2011 04:38 AM, David Engster wrote:
>> Brendan Miller writes:
>>> I guess cedet needs to support xemacs though?
>>
>> I wouldn't worry much about that. CEDET hasn't worked on xemacs for
>> quite some time now, and I can't remember seeing any complaints about
>> that (quite the contrary, actually).  Eric may see this differently,
>> though.
>
> CEDET *almost* compiles on XEmacs, and does work when you ignore what 
> doesn't compile.  I couldn't figure out the build issue, and someone was 
> trying to fix the compilation issue, but they didn't get it either.  A 
> tenacious user can go back and open the files in XEmacs, and compile 
> them from an interactive session to finish the job.  Thus, very hard to 
> debug.

Well, that's just compilation. I'd be interested in what happens if you
actually try to run the code. I've just fixed hundreds of byte-compiler
warnings for FSF Emacs, and more than a few of them were actual errors...

Anyway, even that level of compatibility will be hard to maintain with
the next Emacs merge, since we're required to drop some packages in
favor of functions which are included in Emacs proper (for example,
`make-progress-reporter' instead of working.el). In fact, I already had
to spend quite some time to re-introduce compatibility with the current
Emacs23(!), due to the changes Stefan and Yidong have introduced in
Emacs24-bzr. I can only imagine how much work it would be to get this
stuff to work on xemacs. I think we should not impose that work on the
few contributors we have.

BTW, the 'newtrunk' branch is almost ready for public testing. I will be
posting a longer description regarding compilation and setup in the
coming days.

Cheers,
David