Thread: [CEDET-devel] cedet questions
Brought to you by:
zappo
From: Brendan M. <cat...@ca...> - 2011-12-03 01:48:11
|
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? 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? 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. |
From: Eric M. L. <eri...@gm...> - 2011-12-03 03:03:47
|
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 |
From: Brendan M. <cat...@ca...> - 2011-12-03 06:38:02
|
On Fri, Dec 2, 2011 at 7:03 PM, Eric M. Ludlam <eri...@gm...> 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... |
From: David E. <de...@ra...> - 2011-12-03 09:38:10
|
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 |
From: Eric M. L. <eri...@gm...> - 2011-12-03 12:30:30
|
On 12/03/2011 01:37 AM, Brendan Miller wrote: > On Fri, Dec 2, 2011 at 7:03 PM, Eric M. Ludlam<eri...@gm...> 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 |
From: Eric M. L. <eri...@gm...> - 2011-12-03 12:33:57
|
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 |
From: David E. <de...@ra...> - 2011-12-03 13:03:01
|
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 |