cedet-devel Mailing List for CEDET (Page 2)
Brought to you by:
zappo
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(5) |
Feb
|
Mar
(3) |
Apr
|
May
(32) |
Jun
(75) |
Jul
(45) |
Aug
(77) |
Sep
(28) |
Oct
(10) |
Nov
(18) |
Dec
(49) |
2003 |
Jan
(98) |
Feb
(116) |
Mar
(111) |
Apr
(99) |
May
(29) |
Jun
(8) |
Jul
(48) |
Aug
(85) |
Sep
(61) |
Oct
(16) |
Nov
(70) |
Dec
(31) |
2004 |
Jan
(50) |
Feb
(74) |
Mar
(151) |
Apr
(76) |
May
(36) |
Jun
(91) |
Jul
(42) |
Aug
(26) |
Sep
(32) |
Oct
(38) |
Nov
(21) |
Dec
(35) |
2005 |
Jan
(78) |
Feb
(46) |
Mar
(25) |
Apr
(68) |
May
(47) |
Jun
(36) |
Jul
(42) |
Aug
(13) |
Sep
(12) |
Oct
(11) |
Nov
(12) |
Dec
(5) |
2006 |
Jan
(15) |
Feb
(9) |
Mar
(9) |
Apr
(10) |
May
(15) |
Jun
(29) |
Jul
(32) |
Aug
(17) |
Sep
(14) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
2007 |
Jan
(17) |
Feb
(60) |
Mar
(39) |
Apr
(7) |
May
(23) |
Jun
(30) |
Jul
(28) |
Aug
(34) |
Sep
(9) |
Oct
(9) |
Nov
(9) |
Dec
(9) |
2008 |
Jan
(18) |
Feb
(38) |
Mar
(33) |
Apr
(35) |
May
(39) |
Jun
(68) |
Jul
(31) |
Aug
(32) |
Sep
(16) |
Oct
(19) |
Nov
(17) |
Dec
(33) |
2009 |
Jan
(83) |
Feb
(104) |
Mar
(214) |
Apr
(156) |
May
(104) |
Jun
(55) |
Jul
(127) |
Aug
(58) |
Sep
(58) |
Oct
(58) |
Nov
(48) |
Dec
(28) |
2010 |
Jan
(46) |
Feb
(135) |
Mar
(97) |
Apr
(52) |
May
(75) |
Jun
(31) |
Jul
(35) |
Aug
(51) |
Sep
(52) |
Oct
(107) |
Nov
(71) |
Dec
(15) |
2011 |
Jan
(24) |
Feb
(49) |
Mar
(107) |
Apr
(110) |
May
(28) |
Jun
(63) |
Jul
(28) |
Aug
(37) |
Sep
(29) |
Oct
(24) |
Nov
(46) |
Dec
(44) |
2012 |
Jan
(79) |
Feb
(103) |
Mar
(67) |
Apr
(81) |
May
(29) |
Jun
(70) |
Jul
(39) |
Aug
(21) |
Sep
(54) |
Oct
(75) |
Nov
(72) |
Dec
(86) |
2013 |
Jan
(72) |
Feb
(38) |
Mar
(131) |
Apr
(8) |
May
(31) |
Jun
(3) |
Jul
(5) |
Aug
(39) |
Sep
(38) |
Oct
(41) |
Nov
(43) |
Dec
(37) |
2014 |
Jan
(12) |
Feb
(47) |
Mar
(36) |
Apr
(9) |
May
(24) |
Jun
(50) |
Jul
(19) |
Aug
(26) |
Sep
(27) |
Oct
(21) |
Nov
(12) |
Dec
(26) |
2015 |
Jan
(83) |
Feb
(58) |
Mar
(34) |
Apr
(26) |
May
(6) |
Jun
(8) |
Jul
(2) |
Aug
(18) |
Sep
(1) |
Oct
(27) |
Nov
(7) |
Dec
(2) |
2016 |
Jan
(9) |
Feb
(4) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(8) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
2020 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(12) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric L. <er...@si...> - 2020-01-16 02:47:32
|
Hi Vladimir, Mainline Emacs version of CEDET has moved past CEDET on sourceforge due to major changes to eieio. At this point it is not possible to use SF version with newer Emacsen. I have been posting minor patches to Emacs for missing features from SF version, but it is slow going as I have limited time, and I don't have a continous release from my company. Eventually I'd like to move some of the tools not in Emacs into melpa after updating them to work with newer Emacs, but it will be a while without help. Eric On 1/12/20 1:11 AM, Vladimir Nikishkin wrote: > I am reading the built-in Emacs CEDET manuals, and they are apparently > refencing some CEDET features that are not within a standard Emacs > installation. (For example, cogre is not there. Also the manual > references the grammar-fw info node, which is also not present.) > How large is the difference? Is it worth installing a git version of > cedet for everyday usage (not for development)? > > You know, org-mode is also generally divergent from the main Emacs > tree, but they maintain a separate MELPA repository, which allows to > have a "semi-fresh" org installation without interfering with Emacs > proper. Maybe it is worth making a melpa repository with the latest > CEDET? > |
From: Vladimir N. <loc...@gm...> - 2020-01-12 06:12:09
|
I am reading the built-in Emacs CEDET manuals, and they are apparently refencing some CEDET features that are not within a standard Emacs installation. (For example, cogre is not there. Also the manual references the grammar-fw info node, which is also not present.) How large is the difference? Is it worth installing a git version of cedet for everyday usage (not for development)? You know, org-mode is also generally divergent from the main Emacs tree, but they maintain a separate MELPA repository, which allows to have a "semi-fresh" org installation without interfering with Emacs proper. Maybe it is worth making a melpa repository with the latest CEDET? -- Yours sincerely, Vladimir Nikishkin |
From: Consciencia <con...@pr...> - 2019-11-19 21:16:41
|
I created one backend for that based on grep on unixes and findstr on windows. Findstr is there because of speed issues of grep on windows platform. Dont have idea why, probably same issue as in magit (slow startup of subprocesses). I will look If I can replicate your fix in there. Also I must warn about GNU Global. Its bugged, it sometimes gives bad results. At first I thought its some problem in DB, but after I created my solution based on grepping, issue vanished. NeoCEDET is currently 75% complete. Only couple of additional extensions needs to be added and I will be done with first version. Will write here release notification. C. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday 19. November 2019 1:38, Eric Ludlam <er...@si...> wrote: > Thanks for Clarifying, > > Your wrapper strategy sounds like a good idea to me. I always focused on > the bottom layer, and never had time for polishing the user-friendly part. > > I also had a hard time supporting languages I never used or didn't know, > so every thing ended up looking like C++. > > So in that light, the patch you originally asked about shouldn't have > any impact on C++, but if you have some wrapper support around > additional tools that provide C++ tags via semanticdb databases, you > could apply that idea. > > Eric > > On 11/17/19 4:19 PM, Consciencia via Cedet-devel wrote: > > > Hi Eric, > > My initiative is based on what is provided by Emacs. > > I decided that best way is to not fetch all CEDET sources into my > > repository, instead I just do wild monkey patching. > > It is not perfect, but I like the idea that most of the code receives > > compatibility fixes by Emacs dev team, so less work for me. > > Merging my changes to where development of CEDET will occur or is occurring > > is not probably good idea for many reasons. > > First, because I lack time but want many fixes and additional features, code > > is one big mess. Its not optimal, but only viable way for me. > > Another thing is, I deviated from some core CEDET principles in order > > to be maximally user friendly and concentrate on features which I find > > critical for me. > > To sum it up, my goal was to resurrect CEDET, not to continue in > > its main development which is outside of my possibilities. > > I consider CEDET to be biggest Emacs package initiative ever and > > its kind of sad that nearly no one today uses it even though there is > > no functional wise replacement for it in Emacs world so people > > work with worse tools than they used to in past when CEDET was fresh. > > One of the reasons for this situation is fact that it is > > gigantic system which requires some knowledge of its internals in order to > > be able to configure it properly. > > And yes, there is a huge amount of configuration options. > > Some people even wrote they own tools because they were unable to get > > this beast work as they wanted. > > Thus, my main goal is to create "wrapper" around CEDET which will make a lot of > > configuration assumptions how things should work so users will be able > > to initialize CEDET with one line of elisp and all will just work. > > I believe that If people are able to try full power of CEDET without any time > > investment, they will use it and possibly contribute to its development which > > is critically needed because languages are developing while CEDET parser > > definitions not. > > C. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Saturday 16. November 2019 1:58, Eric Ludlam er...@si... wrote: > > > > > Hi C, > > > Thanks for the feedback. Pre-indexing elisp would solve the issue, but > > > in the end, Emacs already has the info built in, so it isn't really needed. > > > This patch shouldn't affect C/C++. This is entirely related to elisp > > > special database. The technique could be applied to other data bases, > > > such as ebrowse or gtags, or whatever. I haven't developed in C++ for > > > quite a few years, so haven't used those tools in a while. > > > Current state of my CEDET development is that after the Emacs merge, > > > transferring changes from SourceForge to Emacs was too painful to deal > > > with, which made further development a bit disheartening. After a > > > pretty long hiatus, I'm trying to shift my focus to Emacs development > > > instead, but have been running into problems, some of which is getting > > > changes merged into Emacs. (I don't have permissions.) > > > I'm not sure what your neoCEDET is branched from, but I would recommend > > > branching from Emacs, and posting patches there. Better yet, there is a > > > final incomplete merge branch waiting to be merged into emacs. Once > > > that is merged in, I think we could then retire the sourceforge > > > repository. Someone was asking me about it but I haven't had time to > > > dig in yet. > > > Eric > > > On 11/15/19 6:02 PM, Consciencia via Cedet-devel wrote: > > > > > > > Hello, > > > > I did this change long ago and usually solved this issue with C-g. > > > > I personally think that pre-indexing emacs lisp sources can solve this issue too > > > > but not actually did it yet. > > > > I have one question, how this patch affect for example C (C++)? Can it reduce its reach? > > > > Anyway, thanks for patch. I will try it. > > > > Yes, and second question. What is the current state of CEDET development? Im currently working on something > > > > what I call "neoCEDET", its basically (dirty) project (resurrection?) with bunch of fixes and extensions > > > > whose main goal is to get CEDET to people by means of very easy setup and no external dependencies. > > > > But I dont want to interfere with your plans. > > > > C. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > On Saturday 12. October 2019 15:24, Eric Ludlam er...@si... wrote: > > > > > > > > > Hi all, > > > > > I'm finally updating to using a version of CEDET that's built into > > > > > Emacs. With the version from source-forge, emacs-lisp buffers used > > > > > CEDET features by default, but this is not the case with the version > > > > > built into Emacs. I feel it's important to include emacs lisp because > > > > > other modes like srecode and some decoration features depend on it. > > > > > My assumption is that this was left out on-purpose, so I enabled it (see > > > > > first part of patch below) and started using it and looking to see what > > > > > annoying things might have caused this to be removed. > > > > > If you have any reasons why emacs-lisp-mode shoult stay unsupported by > > > > > semantic by default (aside from what I'm fixing below) please let me > > > > > know what they are. Maybe I can fix them. > > > > > What I did find is a problem where completion-at-point (which I was > > > > > using via company-mode) started parsing piles of files from Emacs' lisp > > > > > directories. > > > > > The second part of the below patch fixes this problem. It also speeds > > > > > things up a bunch which is nice. > > > > > Repro steps: > > > > > emacs -q > > > > > M-x semantic-mode RET > > > > > ;; Edit /tmp/foo.el > > > > > ;; Type in: ;; comment a > > > > > ;; put cursor directly after "a" > > > > > M-x completion-at-point RET > > > > > You'll see a ton of parsing messages from semantic rolling by. Hit C-g > > > > > and don't wait for it. This is a worst-case scenario. > > > > > ;; Exit emacs > > > > > In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches > > > > > stored away. Delete them. Apply the patch. > > > > > When you try again, there may be a message or 2 rolling by but no > > > > > parsing. In addition, no extra semanticdb files should be saved. > > > > > How this patch works (if you care): > > > > > The semantic parser parses buffers for tags. semanticdb is a tool that > > > > > makes it possible to search tags from multiple files from multiple > > > > > directories. It caches these into files in .emacs.d to speed up usage > > > > > in future sessions, and allows searching of tags in files not in buffers. > > > > > For Emacs lisp, there is a special database used during search that uses > > > > > Emacs' internal symbol lookup to find tags that haven't been parsed. It > > > > > can find the files they come from, and read tags from those files if > > > > > needed. (ie - if you want to jump to that tag.) Completion doesn't need > > > > > that feature. To convert the found tags from Emacs' internal search > > > > > format to be useful, they need to be normalized, and that process was > > > > > loading and parsing the extra files. > > > > > This isn't necessary for completion, so instead of loading the tags, the > > > > > patched normalization process for emacs-lisp just saves the filename in > > > > > the found tag and moves on. The part the converts the tag list into the > > > > > completion list then needs to access that filename more generically for > > > > > cases where a found tag is already in a buffer. > > > > > An alternative to the below patch, or perhaps in addition to it, would > > > > > be to remove the (require 'semantic/db-el) from the end of > > > > > semantic/bovine/el.el. There are many very good emacs-lisp based tools > > > > > these days, so this feature is probably not necessary unless you are > > > > > bought into the CEDET modes specifically. > > > > > Thanks for any input > > > > > Eric > > > > Cedet-devel mailing list > > Ced...@li... > > https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: Eric L. <er...@si...> - 2019-11-19 00:39:10
|
Thanks for Clarifying, Your wrapper strategy sounds like a good idea to me. I always focused on the bottom layer, and never had time for polishing the user-friendly part. I also had a hard time supporting languages I never used or didn't know, so every thing ended up looking like C++. So in that light, the patch you originally asked about shouldn't have any impact on C++, but if you have some wrapper support around additional tools that provide C++ tags via semanticdb databases, you could apply that idea. Eric On 11/17/19 4:19 PM, Consciencia via Cedet-devel wrote: > Hi Eric, > > My initiative is based on what is provided by Emacs. > I decided that best way is to not fetch all CEDET sources into my > repository, instead I just do wild monkey patching. > It is not perfect, but I like the idea that most of the code receives > compatibility fixes by Emacs dev team, so less work for me. > > Merging my changes to where development of CEDET will occur or is occurring > is not probably good idea for many reasons. > > First, because I lack time but want many fixes and additional features, code > is one big mess. Its not optimal, but only viable way for me. > > Another thing is, I deviated from some core CEDET principles in order > to be maximally user friendly and concentrate on features which I find > critical for me. > > To sum it up, my goal was to resurrect CEDET, not to continue in > its main development which is outside of my possibilities. > > I consider CEDET to be biggest Emacs package initiative ever and > its kind of sad that nearly no one today uses it even though there is > no functional wise replacement for it in Emacs world so people > work with worse tools than they used to in past when CEDET was fresh. > > One of the reasons for this situation is fact that it is > gigantic system which requires some knowledge of its internals in order to > be able to configure it properly. > And yes, there is a huge amount of configuration options. > > Some people even wrote they own tools because they were unable to get > this beast work as they wanted. > > Thus, my main goal is to create "wrapper" around CEDET which will make a lot of > configuration assumptions how things should work so users will be able > to initialize CEDET with one line of elisp and all will just work. > > I believe that If people are able to try full power of CEDET without any time > investment, they will use it and possibly contribute to its development which > is critically needed because languages are developing while CEDET parser > definitions not. > > C. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday 16. November 2019 1:58, Eric Ludlam <er...@si...> wrote: > >> Hi C, >> >> Thanks for the feedback. Pre-indexing elisp would solve the issue, but >> in the end, Emacs already has the info built in, so it isn't really needed. >> >> This patch shouldn't affect C/C++. This is entirely related to elisp >> special database. The technique could be applied to other data bases, >> such as ebrowse or gtags, or whatever. I haven't developed in C++ for >> quite a few years, so haven't used those tools in a while. >> >> Current state of my CEDET development is that after the Emacs merge, >> transferring changes from SourceForge to Emacs was too painful to deal >> with, which made further development a bit disheartening. After a >> pretty long hiatus, I'm trying to shift my focus to Emacs development >> instead, but have been running into problems, some of which is getting >> changes merged into Emacs. (I don't have permissions.) >> >> I'm not sure what your neoCEDET is branched from, but I would recommend >> branching from Emacs, and posting patches there. Better yet, there is a >> final incomplete merge branch waiting to be merged into emacs. Once >> that is merged in, I think we could then retire the sourceforge >> repository. Someone was asking me about it but I haven't had time to >> dig in yet. >> >> Eric >> >> On 11/15/19 6:02 PM, Consciencia via Cedet-devel wrote: >> >>> Hello, >>> I did this change long ago and usually solved this issue with C-g. >>> I personally think that pre-indexing emacs lisp sources can solve this issue too >>> but not actually did it yet. >>> I have one question, how this patch affect for example C (C++)? Can it reduce its reach? >>> Anyway, thanks for patch. I will try it. >>> Yes, and second question. What is the current state of CEDET development? Im currently working on something >>> what I call "neoCEDET", its basically (dirty) project (resurrection?) with bunch of fixes and extensions >>> whose main goal is to get CEDET to people by means of very easy setup and no external dependencies. >>> But I dont want to interfere with your plans. >>> C. >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Saturday 12. October 2019 15:24, Eric Ludlam er...@si... wrote: >>> >>>> Hi all, >>>> I'm finally updating to using a version of CEDET that's built into >>>> Emacs. With the version from source-forge, emacs-lisp buffers used >>>> CEDET features by default, but this is not the case with the version >>>> built into Emacs. I feel it's important to include emacs lisp because >>>> other modes like srecode and some decoration features depend on it. >>>> My assumption is that this was left out on-purpose, so I enabled it (see >>>> first part of patch below) and started using it and looking to see what >>>> annoying things might have caused this to be removed. >>>> If you have any reasons why emacs-lisp-mode shoult stay unsupported by >>>> semantic by default (aside from what I'm fixing below) please let me >>>> know what they are. Maybe I can fix them. >>>> What I did find is a problem where completion-at-point (which I was >>>> using via company-mode) started parsing piles of files from Emacs' lisp >>>> directories. >>>> The second part of the below patch fixes this problem. It also speeds >>>> things up a bunch which is nice. >>>> Repro steps: >>>> emacs -q >>>> M-x semantic-mode RET >>>> ;; Edit /tmp/foo.el >>>> ;; Type in: ;; comment a >>>> ;; put cursor directly after "a" >>>> M-x completion-at-point RET >>>> You'll see a ton of parsing messages from semantic rolling by. Hit C-g >>>> and don't wait for it. This is a worst-case scenario. >>>> ;; Exit emacs >>>> In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches >>>> stored away. Delete them. Apply the patch. >>>> When you try again, there may be a message or 2 rolling by but no >>>> parsing. In addition, no extra semanticdb files should be saved. >>>> How this patch works (if you care): >>>> The semantic parser parses buffers for tags. semanticdb is a tool that >>>> makes it possible to search tags from multiple files from multiple >>>> directories. It caches these into files in .emacs.d to speed up usage >>>> in future sessions, and allows searching of tags in files not in buffers. >>>> For Emacs lisp, there is a special database used during search that uses >>>> Emacs' internal symbol lookup to find tags that haven't been parsed. It >>>> can find the files they come from, and read tags from those files if >>>> needed. (ie - if you want to jump to that tag.) Completion doesn't need >>>> that feature. To convert the found tags from Emacs' internal search >>>> format to be useful, they need to be normalized, and that process was >>>> loading and parsing the extra files. >>>> This isn't necessary for completion, so instead of loading the tags, the >>>> patched normalization process for emacs-lisp just saves the filename in >>>> the found tag and moves on. The part the converts the tag list into the >>>> completion list then needs to access that filename more generically for >>>> cases where a found tag is already in a buffer. >>>> An alternative to the below patch, or perhaps in addition to it, would >>>> be to remove the (require 'semantic/db-el) from the end of >>>> semantic/bovine/el.el. There are many very good emacs-lisp based tools >>>> these days, so this feature is probably not necessary unless you are >>>> bought into the CEDET modes specifically. >>>> Thanks for any input >>>> Eric > > > > > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Consciencia <con...@pr...> - 2019-11-17 21:19:19
|
Hi Eric, My initiative is based on what is provided by Emacs. I decided that best way is to not fetch all CEDET sources into my repository, instead I just do wild monkey patching. It is not perfect, but I like the idea that most of the code receives compatibility fixes by Emacs dev team, so less work for me. Merging my changes to where development of CEDET will occur or is occurring is not probably good idea for many reasons. First, because I lack time but want many fixes and additional features, code is one big mess. Its not optimal, but only viable way for me. Another thing is, I deviated from some core CEDET principles in order to be maximally user friendly and concentrate on features which I find critical for me. To sum it up, my goal was to resurrect CEDET, not to continue in its main development which is outside of my possibilities. I consider CEDET to be biggest Emacs package initiative ever and its kind of sad that nearly no one today uses it even though there is no functional wise replacement for it in Emacs world so people work with worse tools than they used to in past when CEDET was fresh. One of the reasons for this situation is fact that it is gigantic system which requires some knowledge of its internals in order to be able to configure it properly. And yes, there is a huge amount of configuration options. Some people even wrote they own tools because they were unable to get this beast work as they wanted. Thus, my main goal is to create "wrapper" around CEDET which will make a lot of configuration assumptions how things should work so users will be able to initialize CEDET with one line of elisp and all will just work. I believe that If people are able to try full power of CEDET without any time investment, they will use it and possibly contribute to its development which is critically needed because languages are developing while CEDET parser definitions not. C. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday 16. November 2019 1:58, Eric Ludlam <er...@si...> wrote: > Hi C, > > Thanks for the feedback. Pre-indexing elisp would solve the issue, but > in the end, Emacs already has the info built in, so it isn't really needed. > > This patch shouldn't affect C/C++. This is entirely related to elisp > special database. The technique could be applied to other data bases, > such as ebrowse or gtags, or whatever. I haven't developed in C++ for > quite a few years, so haven't used those tools in a while. > > Current state of my CEDET development is that after the Emacs merge, > transferring changes from SourceForge to Emacs was too painful to deal > with, which made further development a bit disheartening. After a > pretty long hiatus, I'm trying to shift my focus to Emacs development > instead, but have been running into problems, some of which is getting > changes merged into Emacs. (I don't have permissions.) > > I'm not sure what your neoCEDET is branched from, but I would recommend > branching from Emacs, and posting patches there. Better yet, there is a > final incomplete merge branch waiting to be merged into emacs. Once > that is merged in, I think we could then retire the sourceforge > repository. Someone was asking me about it but I haven't had time to > dig in yet. > > Eric > > On 11/15/19 6:02 PM, Consciencia via Cedet-devel wrote: > > > Hello, > > I did this change long ago and usually solved this issue with C-g. > > I personally think that pre-indexing emacs lisp sources can solve this issue too > > but not actually did it yet. > > I have one question, how this patch affect for example C (C++)? Can it reduce its reach? > > Anyway, thanks for patch. I will try it. > > Yes, and second question. What is the current state of CEDET development? Im currently working on something > > what I call "neoCEDET", its basically (dirty) project (resurrection?) with bunch of fixes and extensions > > whose main goal is to get CEDET to people by means of very easy setup and no external dependencies. > > But I dont want to interfere with your plans. > > C. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Saturday 12. October 2019 15:24, Eric Ludlam er...@si... wrote: > > > > > Hi all, > > > I'm finally updating to using a version of CEDET that's built into > > > Emacs. With the version from source-forge, emacs-lisp buffers used > > > CEDET features by default, but this is not the case with the version > > > built into Emacs. I feel it's important to include emacs lisp because > > > other modes like srecode and some decoration features depend on it. > > > My assumption is that this was left out on-purpose, so I enabled it (see > > > first part of patch below) and started using it and looking to see what > > > annoying things might have caused this to be removed. > > > If you have any reasons why emacs-lisp-mode shoult stay unsupported by > > > semantic by default (aside from what I'm fixing below) please let me > > > know what they are. Maybe I can fix them. > > > What I did find is a problem where completion-at-point (which I was > > > using via company-mode) started parsing piles of files from Emacs' lisp > > > directories. > > > The second part of the below patch fixes this problem. It also speeds > > > things up a bunch which is nice. > > > Repro steps: > > > emacs -q > > > M-x semantic-mode RET > > > ;; Edit /tmp/foo.el > > > ;; Type in: ;; comment a > > > ;; put cursor directly after "a" > > > M-x completion-at-point RET > > > You'll see a ton of parsing messages from semantic rolling by. Hit C-g > > > and don't wait for it. This is a worst-case scenario. > > > ;; Exit emacs > > > In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches > > > stored away. Delete them. Apply the patch. > > > When you try again, there may be a message or 2 rolling by but no > > > parsing. In addition, no extra semanticdb files should be saved. > > > How this patch works (if you care): > > > The semantic parser parses buffers for tags. semanticdb is a tool that > > > makes it possible to search tags from multiple files from multiple > > > directories. It caches these into files in .emacs.d to speed up usage > > > in future sessions, and allows searching of tags in files not in buffers. > > > For Emacs lisp, there is a special database used during search that uses > > > Emacs' internal symbol lookup to find tags that haven't been parsed. It > > > can find the files they come from, and read tags from those files if > > > needed. (ie - if you want to jump to that tag.) Completion doesn't need > > > that feature. To convert the found tags from Emacs' internal search > > > format to be useful, they need to be normalized, and that process was > > > loading and parsing the extra files. > > > This isn't necessary for completion, so instead of loading the tags, the > > > patched normalization process for emacs-lisp just saves the filename in > > > the found tag and moves on. The part the converts the tag list into the > > > completion list then needs to access that filename more generically for > > > cases where a found tag is already in a buffer. > > > An alternative to the below patch, or perhaps in addition to it, would > > > be to remove the (require 'semantic/db-el) from the end of > > > semantic/bovine/el.el. There are many very good emacs-lisp based tools > > > these days, so this feature is probably not necessary unless you are > > > bought into the CEDET modes specifically. > > > Thanks for any input > > > Eric |
From: Eric L. <er...@si...> - 2019-11-16 00:58:25
|
Hi C, Thanks for the feedback. Pre-indexing elisp would solve the issue, but in the end, Emacs already has the info built in, so it isn't really needed. This patch shouldn't affect C/C++. This is entirely related to elisp special database. The technique could be applied to other data bases, such as ebrowse or gtags, or whatever. I haven't developed in C++ for quite a few years, so haven't used those tools in a while. Current state of my CEDET development is that after the Emacs merge, transferring changes from SourceForge to Emacs was too painful to deal with, which made further development a bit disheartening. After a pretty long hiatus, I'm trying to shift my focus to Emacs development instead, but have been running into problems, some of which is getting changes merged into Emacs. (I don't have permissions.) I'm not sure what your neoCEDET is branched from, but I would recommend branching from Emacs, and posting patches there. Better yet, there is a final incomplete merge branch waiting to be merged into emacs. Once that is merged in, I think we could then retire the sourceforge repository. Someone was asking me about it but I haven't had time to dig in yet. Eric On 11/15/19 6:02 PM, Consciencia via Cedet-devel wrote: > Hello, > > I did this change long ago and usually solved this issue with C-g. > > I personally think that pre-indexing emacs lisp sources can solve this issue too > but not actually did it yet. > > I have one question, how this patch affect for example C (C++)? Can it reduce its reach? > > Anyway, thanks for patch. I will try it. > > Yes, and second question. What is the current state of CEDET development? Im currently working on something > what I call "neoCEDET", its basically (dirty) project (resurrection?) with bunch of fixes and extensions > whose main goal is to get CEDET to people by means of very easy setup and no external dependencies. > > But I dont want to interfere with your plans. > > C. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday 12. October 2019 15:24, Eric Ludlam <er...@si...> wrote: > >> Hi all, >> >> I'm finally updating to using a version of CEDET that's built into >> Emacs. With the version from source-forge, emacs-lisp buffers used >> CEDET features by default, but this is not the case with the version >> built into Emacs. I feel it's important to include emacs lisp because >> other modes like srecode and some decoration features depend on it. >> >> My assumption is that this was left out on-purpose, so I enabled it (see >> first part of patch below) and started using it and looking to see what >> annoying things might have caused this to be removed. >> >> If you have any reasons why emacs-lisp-mode shoult stay unsupported by >> semantic by default (aside from what I'm fixing below) please let me >> know what they are. Maybe I can fix them. >> >> What I did find is a problem where completion-at-point (which I was >> using via company-mode) started parsing piles of files from Emacs' lisp >> directories. >> >> The second part of the below patch fixes this problem. It also speeds >> things up a bunch which is nice. >> >> Repro steps: >> >> emacs -q >> M-x semantic-mode RET >> ;; Edit /tmp/foo.el >> ;; Type in: ;; comment a >> ;; put cursor directly after "a" >> M-x completion-at-point RET >> >> You'll see a ton of parsing messages from semantic rolling by. Hit C-g >> and don't wait for it. This is a worst-case scenario. >> >> ;; Exit emacs >> >> In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches >> stored away. Delete them. Apply the patch. >> >> When you try again, there may be a message or 2 rolling by but no >> parsing. In addition, no extra semanticdb files should be saved. >> >> How this patch works (if you care): >> >> The semantic parser parses buffers for tags. semanticdb is a tool that >> makes it possible to search tags from multiple files from multiple >> directories. It caches these into files in .emacs.d to speed up usage >> in future sessions, and allows searching of tags in files not in buffers. >> >> For Emacs lisp, there is a special database used during search that uses >> Emacs' internal symbol lookup to find tags that haven't been parsed. It >> can find the files they come from, and read tags from those files if >> needed. (ie - if you want to jump to that tag.) Completion doesn't need >> that feature. To convert the found tags from Emacs' internal search >> format to be useful, they need to be normalized, and that process was >> loading and parsing the extra files. >> >> This isn't necessary for completion, so instead of loading the tags, the >> patched normalization process for emacs-lisp just saves the filename in >> the found tag and moves on. The part the converts the tag list into the >> completion list then needs to access that filename more generically for >> cases where a found tag is already in a buffer. >> >> An alternative to the below patch, or perhaps in addition to it, would >> be to remove the (require 'semantic/db-el) from the end of >> semantic/bovine/el.el. There are many very good emacs-lisp based tools >> these days, so this feature is probably not necessary unless you are >> bought into the CEDET modes specifically. >> >> Thanks for any input >> Eric >> |
From: Consciencia <con...@pr...> - 2019-11-15 23:02:49
|
Hello, I did this change long ago and usually solved this issue with C-g. I personally think that pre-indexing emacs lisp sources can solve this issue too but not actually did it yet. I have one question, how this patch affect for example C (C++)? Can it reduce its reach? Anyway, thanks for patch. I will try it. Yes, and second question. What is the current state of CEDET development? Im currently working on something what I call "neoCEDET", its basically (dirty) project (resurrection?) with bunch of fixes and extensions whose main goal is to get CEDET to people by means of very easy setup and no external dependencies. But I dont want to interfere with your plans. C. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday 12. October 2019 15:24, Eric Ludlam <er...@si...> wrote: > Hi all, > > I'm finally updating to using a version of CEDET that's built into > Emacs. With the version from source-forge, emacs-lisp buffers used > CEDET features by default, but this is not the case with the version > built into Emacs. I feel it's important to include emacs lisp because > other modes like srecode and some decoration features depend on it. > > My assumption is that this was left out on-purpose, so I enabled it (see > first part of patch below) and started using it and looking to see what > annoying things might have caused this to be removed. > > If you have any reasons why emacs-lisp-mode shoult stay unsupported by > semantic by default (aside from what I'm fixing below) please let me > know what they are. Maybe I can fix them. > > What I did find is a problem where completion-at-point (which I was > using via company-mode) started parsing piles of files from Emacs' lisp > directories. > > The second part of the below patch fixes this problem. It also speeds > things up a bunch which is nice. > > Repro steps: > > emacs -q > M-x semantic-mode RET > ;; Edit /tmp/foo.el > ;; Type in: ;; comment a > ;; put cursor directly after "a" > M-x completion-at-point RET > > You'll see a ton of parsing messages from semantic rolling by. Hit C-g > and don't wait for it. This is a worst-case scenario. > > ;; Exit emacs > > In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches > stored away. Delete them. Apply the patch. > > When you try again, there may be a message or 2 rolling by but no > parsing. In addition, no extra semanticdb files should be saved. > > How this patch works (if you care): > > The semantic parser parses buffers for tags. semanticdb is a tool that > makes it possible to search tags from multiple files from multiple > directories. It caches these into files in .emacs.d to speed up usage > in future sessions, and allows searching of tags in files not in buffers. > > For Emacs lisp, there is a special database used during search that uses > Emacs' internal symbol lookup to find tags that haven't been parsed. It > can find the files they come from, and read tags from those files if > needed. (ie - if you want to jump to that tag.) Completion doesn't need > that feature. To convert the found tags from Emacs' internal search > format to be useful, they need to be normalized, and that process was > loading and parsing the extra files. > > This isn't necessary for completion, so instead of loading the tags, the > patched normalization process for emacs-lisp just saves the filename in > the found tag and moves on. The part the converts the tag list into the > completion list then needs to access that filename more generically for > cases where a found tag is already in a buffer. > > An alternative to the below patch, or perhaps in addition to it, would > be to remove the (require 'semantic/db-el) from the end of > semantic/bovine/el.el. There are many very good emacs-lisp based tools > these days, so this feature is probably not necessary unless you are > bought into the CEDET modes specifically. > > Thanks for any input > Eric > > diff --git a/lisp/cedet/semantic.el b/lisp/cedet/semantic.el > index 0b878cae52..e92c1ed363 100644 > --- a/lisp/cedet/semantic.el > +++ b/lisp/cedet/semantic.el > @@ -269,6 +269,7 @@ semantic-inhibit-functions > (defcustom semantic-new-buffer-setup-functions > '((c-mode . semantic-default-c-setup) > (c++-mode . semantic-default-c-setup) > > - (emacs-lisp-mode . semantic-default-elisp-setup) > (html-mode . semantic-default-html-setup) > (java-mode . wisent-java-default-setup) > (js-mode . wisent-javascript-setup-parser) > diff --git a/lisp/cedet/semantic/db-el.el b/lisp/cedet/semantic/db-el.el > index 39d61fe789..70f023750c 100644 > --- a/lisp/cedet/semantic/db-el.el > +++ b/lisp/cedet/semantic/db-el.el > @@ -176,15 +176,22 @@ emacs-lisp-mode > ;; Is it a .gz file? > (setq file (concat file ".gz")))) > > > - (let* ((tab (semanticdb-file-table-object file)) > > > > - ;; Use DONTLOAD opt for finding table obj associated w/ these tags. > > > - ;; If we did load these syms, then simple completions for "a" for > > > - ;; as-you-type completion systems will load half the libraries in > > > - ;; emacs. > > > - (let* ((tab (semanticdb-file-table-object file t)) > (newtags (when tab (semanticdb-find-tags-by-name-method > tab (semantic-tag-name tag)))) > (match nil)) > > > > - ;; We might not have a parsed tag in this file, because it > - ;; might be generated through a macro like defstruct. > > - ;; We might not have a parsed tag in this file due to > - ;; specifying DONTLOAD above, or the tag was generated with a > - ;; macro. In that case, just use our found tag, and store > - ;; the filename in it. > (if (null newtags) > > > - (setq match tag) > > > - ;; Find the best match. > > > > - ;; In this case > > > - (setq match (semantic--tag-put-property tag :filename file)) > > > - ;; Find the best match in the found tags. > (dolist (T newtags) > (when (semantic-tag-similar-p T tag) > (setq match T))) > > > > diff --git a/lisp/cedet/semantic/db-find.el b/lisp/cedet/semantic/db-find.el > index 18c749b098..114534bbf0 100644 > --- a/lisp/cedet/semantic/db-find.el > +++ b/lisp/cedet/semantic/db-find.el > @@ -882,7 +882,7 @@ semanticdb-strip-find-results > ;; Find-file-match allows a tool to make sure the tag is > ;; 'live', somewhere in a buffer. > (cond ((eq find-file-match 'name) > > - (or (semantic--tag-get-property ntag :filename) > > > > - (or (semantic-tag-file-name ntag) > (let ((f (semanticdb-full-filename nametable))) > (semantic--tag-put-property ntag :filename f)))) > ((and find-file-match ntab) > > > > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: Eric L. <er...@si...> - 2019-10-12 13:24:46
|
Hi all, I'm finally updating to using a version of CEDET that's built into Emacs. With the version from source-forge, emacs-lisp buffers used CEDET features by default, but this is not the case with the version built into Emacs. I feel it's important to include emacs lisp because other modes like srecode and some decoration features depend on it. My assumption is that this was left out on-purpose, so I enabled it (see first part of patch below) and started using it and looking to see what annoying things might have caused this to be removed. If you have any reasons why emacs-lisp-mode shoult stay unsupported by semantic by default (aside from what I'm fixing below) please let me know what they are. Maybe I can fix them. What I did find is a problem where completion-at-point (which I was using via company-mode) started parsing piles of files from Emacs' lisp directories. The second part of the below patch fixes this problem. It also speeds things up a bunch which is nice. Repro steps: emacs -q M-x semantic-mode RET ;; Edit /tmp/foo.el ;; Type in: ;; comment a ;; put cursor directly after "a" M-x completion-at-point RET You'll see a ton of parsing messages from semantic rolling by. Hit C-g and don't wait for it. This is a worst-case scenario. ;; Exit emacs In ~/.emacs.d/semanticdb you'll see lots of your emacs files tag caches stored away. Delete them. Apply the patch. When you try again, there may be a message or 2 rolling by but no parsing. In addition, no extra semanticdb files should be saved. How this patch works (if you care): The semantic parser parses buffers for tags. semanticdb is a tool that makes it possible to search tags from multiple files from multiple directories. It caches these into files in .emacs.d to speed up usage in future sessions, and allows searching of tags in files not in buffers. For Emacs lisp, there is a special database used during search that uses Emacs' internal symbol lookup to find tags that haven't been parsed. It can find the files they come from, and read tags from those files if needed. (ie - if you want to jump to that tag.) Completion doesn't need that feature. To convert the found tags from Emacs' internal search format to be useful, they need to be normalized, and that process was loading and parsing the extra files. This isn't necessary for completion, so instead of loading the tags, the patched normalization process for emacs-lisp just saves the filename in the found tag and moves on. The part the converts the tag list into the completion list then needs to access that filename more generically for cases where a found tag is already in a buffer. An alternative to the below patch, or perhaps in addition to it, would be to remove the (require 'semantic/db-el) from the end of semantic/bovine/el.el. There are many very good emacs-lisp based tools these days, so this feature is probably not necessary unless you are bought into the CEDET modes specifically. Thanks for any input Eric diff --git a/lisp/cedet/semantic.el b/lisp/cedet/semantic.el index 0b878cae52..e92c1ed363 100644 --- a/lisp/cedet/semantic.el +++ b/lisp/cedet/semantic.el @@ -269,6 +269,7 @@ semantic-inhibit-functions (defcustom semantic-new-buffer-setup-functions '((c-mode . semantic-default-c-setup) (c++-mode . semantic-default-c-setup) + (emacs-lisp-mode . semantic-default-elisp-setup) (html-mode . semantic-default-html-setup) (java-mode . wisent-java-default-setup) (js-mode . wisent-javascript-setup-parser) diff --git a/lisp/cedet/semantic/db-el.el b/lisp/cedet/semantic/db-el.el index 39d61fe789..70f023750c 100644 --- a/lisp/cedet/semantic/db-el.el +++ b/lisp/cedet/semantic/db-el.el @@ -176,15 +176,22 @@ emacs-lisp-mode ;; Is it a .gz file? (setq file (concat file ".gz")))) - (let* ((tab (semanticdb-file-table-object file)) + ;; Use DONTLOAD opt for finding table obj associated w/ these tags. + ;; If we did load these syms, then simple completions for "a" for + ;; as-you-type completion systems will load half the libraries in + ;; emacs. + (let* ((tab (semanticdb-file-table-object file t)) (newtags (when tab (semanticdb-find-tags-by-name-method tab (semantic-tag-name tag)))) (match nil)) - ;; We might not have a parsed tag in this file, because it - ;; might be generated through a macro like defstruct. + ;; We might not have a parsed tag in this file due to + ;; specifying DONTLOAD above, or the tag was generated with a + ;; macro. In that case, just use our found tag, and store + ;; the filename in it. (if (null newtags) - (setq match tag) - ;; Find the best match. + ;; In this case + (setq match (semantic--tag-put-property tag :filename file)) + ;; Find the best match in the found tags. (dolist (T newtags) (when (semantic-tag-similar-p T tag) (setq match T))) diff --git a/lisp/cedet/semantic/db-find.el b/lisp/cedet/semantic/db-find.el index 18c749b098..114534bbf0 100644 --- a/lisp/cedet/semantic/db-find.el +++ b/lisp/cedet/semantic/db-find.el @@ -882,7 +882,7 @@ semanticdb-strip-find-results ;; Find-file-match allows a tool to make sure the tag is ;; 'live', somewhere in a buffer. (cond ((eq find-file-match 'name) - (or (semantic--tag-get-property ntag :filename) + (or (semantic-tag-file-name ntag) (let ((f (semanticdb-full-filename nametable))) (semantic--tag-put-property ntag :filename f)))) ((and find-file-match ntab) |
From: Eric L. <er...@si...> - 2018-03-04 22:20:53
|
CEDET from the sourceforge repository doesn't work with newer versions of Emacs (25 and later). Fortunately, srecode is already part of Emacs, so you can try your install steps without the SF CEDET installed and probably get the basics all working right away. This is an indicator that I need to update the web site to indicate all this. Good Luck Eric On 02/12/2018 04:42 PM, Consciencia via Cedet-devel wrote: > Hello, > > after I tried to activate SRecode mode via (global-srecode-minor-mode > 1), I got > > Debugger entered--Lisp error: (error "There should be a mode declaration > in /home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt") > signal(error ("There should be a mode declaration in > /home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt")) > error("There should be a mode declaration in %s" > "/home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt") > > srecode-map-validate-file-for-mode("/home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt" > t) > srecode-map-update-map(t) > srecode-get-maps() > srecode-minor-mode(1) > #[nil " !\207" [mode arg] 2]() > mode-local-map-file-buffers(#[nil " !\207" [mode arg] 2] > semantic-active-p) > semantic-toggle-minor-mode-globally(srecode-minor-mode 1) > global-srecode-minor-mode(1) > eval((global-srecode-minor-mode 1) nil) > elisp--eval-last-sexp(t) > eval-last-sexp(t) > eval-print-last-sexp(nil) > funcall-interactively(eval-print-last-sexp nil) > #<subr call-interactively>(eval-print-last-sexp nil nil) > apply(#<subr call-interactively> eval-print-last-sexp (nil nil)) > call-interactively@ido-cr+-record-current-command(#<subr > call-interactively> eval-print-last-sexp nil nil) > apply(call-interactively@ido-cr+-record-current-command #<subr > call-interactively> (eval-print-last-sexp nil nil)) > call-interactively(eval-print-last-sexp nil nil) > command-execute(eval-print-last-sexp) > > > > I am using latest CEDET. > Also, when I try to compile make project via EDE (ede-compile-target), > this error happens too. > > I will be glad for any help. > > C > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Consciencia <con...@pr...> - 2018-02-12 21:43:19
|
Hello, after I tried to activate SRecode mode via (global-srecode-minor-mode 1), I got Debugger entered--Lisp error: (error "There should be a mode declaration in /home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt") signal(error ("There should be a mode declaration in /home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt")) error("There should be a mode declaration in %s" "/home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt") srecode-map-validate-file-for-mode("/home/box/.emacs.d/lisp/cedet/cedet/etc/srecode/android-java.srt" t) srecode-map-update-map(t) srecode-get-maps() srecode-minor-mode(1) #[nil " !\207" [mode arg] 2]() mode-local-map-file-buffers(#[nil " !\207" [mode arg] 2] semantic-active-p) semantic-toggle-minor-mode-globally(srecode-minor-mode 1) global-srecode-minor-mode(1) eval((global-srecode-minor-mode 1) nil) elisp--eval-last-sexp(t) eval-last-sexp(t) eval-print-last-sexp(nil) funcall-interactively(eval-print-last-sexp nil) #<subr call-interactively>(eval-print-last-sexp nil nil) apply(#<subr call-interactively> eval-print-last-sexp (nil nil)) call-interactively@ido-cr+-record-current-command(#<subr call-interactively> eval-print-last-sexp nil nil) apply(call-interactively@ido-cr+-record-current-command #<subr call-interactively> (eval-print-last-sexp nil nil)) call-interactively(eval-print-last-sexp nil nil) command-execute(eval-print-last-sexp) I am using latest CEDET. Also, when I try to compile make project via EDE (ede-compile-target), this error happens too. I will be glad for any help. C |
From: Eric L. <er...@si...> - 2017-02-25 23:16:50
|
Based on the way the error text is laid out, I suspect this is coming from semantic--tag-run-hooks which does error handling, but also reports the error using that format. This is used when linking/unlinking tags to a buffer which happens during timers and in after-change-hooks, so errors need to be ignored or the system starts falling apart. The hook is used primarily by the tag decoration system. Unfortunately, it didn't occur to me to add more diagnostic like which hook was being run since I never ran into this problem. Adding a call to (debug) in the catch block would show a stack that would be helpful in determining what the problem is. Eric On 02/24/2017 06:06 PM, Lee Hinman wrote: > Semantic is working fine a lot of the time, however, sometimes it gets > into a state where whenever I open any file where semantic is active, I > get spammed with thousands of these messages, for every other buffer > that's already open with semantic enabled: > > Error: (wrong-type-argument symbolp #<overlay from 832 to 890 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 891 to 924 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 925 to 990 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 991 to 1047 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1048 to 1096 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1097 to 1153 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1154 to 1229 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1230 to 1301 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1302 to 1343 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1344 to 1402 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1403 to 1454 in IndexRequest.java>) > Error: (wrong-type-argument symbolp #<overlay from 1455 to 1496 in IndexRequest.java>) > ... etc etc etc hundreds more ... > > I tried `debug-on-error` but it never shows a backtrace, is there some > way I can debug what's causing this? Usually I have to restart Emacs and > then it works okay for a while, then goes back to failing. > > -- > ;; Lee > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Lee H. <lee...@fa...> - 2017-02-24 23:06:33
|
Semantic is working fine a lot of the time, however, sometimes it gets into a state where whenever I open any file where semantic is active, I get spammed with thousands of these messages, for every other buffer that's already open with semantic enabled: Error: (wrong-type-argument symbolp #<overlay from 832 to 890 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 891 to 924 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 925 to 990 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 991 to 1047 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1048 to 1096 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1097 to 1153 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1154 to 1229 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1230 to 1301 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1302 to 1343 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1344 to 1402 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1403 to 1454 in IndexRequest.java>) Error: (wrong-type-argument symbolp #<overlay from 1455 to 1496 in IndexRequest.java>) ... etc etc etc hundreds more ... I tried `debug-on-error` but it never shows a backtrace, is there some way I can debug what's causing this? Usually I have to restart Emacs and then it works okay for a while, then goes back to failing. -- ;; Lee |
From: Eric L. <er...@si...> - 2017-02-18 17:20:10
|
Hi, Some previous reports of issues like this were caused by using an old EDE with the new EIEIO, or some other bad combination. You indicated you have only the emacs 25.1 setup. See if you have any old versions of any tools on your load path. I don't have experience using that version yet to help verify any problems all within Emacs 25. Eric On 02/15/2017 01:07 PM, Алексей Вьюшин wrote: > Greetings! There is a problem, when I use built-in EDE in > emacs-25.1.1. If I create any target, then open any file in created > project after closing emacs an error appeares: > > eieio-persistent-validate/fix-slot-value: Corrupt object on disk > > and project does not load. > With CEDET ( v 1.1) there are no problems. Help me, if you please. |
From: Алексей В. <anv...@gm...> - 2017-02-15 18:07:38
|
Greetings! There is a problem, when I use built-in EDE in emacs-25.1.1. If I create any target, then open any file in created project after closing emacs an error appeares: eieio-persistent-validate/fix-slot-value: Corrupt object on disk and project does not load. With CEDET ( v 1.1) there are no problems. Help me, if you please. |
From: Eric L. <er...@si...> - 2017-02-04 00:44:32
|
On 01/26/2017 10:48 PM, Lee Hinman wrote: > Hi Everyone, > > I currently use `semantic-symref` occasionally in my project, using the > "global" method. However, I've noticed that it can sometimes open > maaaaany buffers (like ~300). > > Is there a way to tell semantic-symref to close those buffers after it's > done with the analysis? I've noticed there is a > `semantic-symref-recently-opened-buffers` symbol, but I didn't see a > customization to automatically close those buffers. Hi, It has been a long while since I worked on this, but here are the basics. I'm using CEDET from sourceforge for reference. There is a function `semantic-symref-cleanup-recent-buffers-fcn' which is setup to run in a post-command-hook after getting some tag results. The function `semantic-symref-result-get-tags' gets tags out of a results buffer, and will auto-close the items in the list if the input argument `open-buffers' is specified as nil, otherwise it leaves them open, but sets the variable to nil. Thus, I'm unsure how you have a situation where the variable has a value, but the buffers are still open. It may be that the 'occasionally' in your statement means that an error got thrown in the post command hook. Starting there, perhaps instrumenting the cleanup function to detect errors might help debug what the problem is. Eric |
From: Mandar M. <man...@gm...> - 2017-01-27 07:20:49
|
Lee Hinman wrote (Thu, Jan 26, 2017 at 08:48:23PM -0700): > I currently use `semantic-symref` occasionally in my project, using the > "global" method. However, I've noticed that it can sometimes open > maaaaany buffers (like ~300). > > Is there a way to tell semantic-symref to close those buffers after it's > done with the analysis? I've noticed there is a > `semantic-symref-recently-opened-buffers` symbol, but I didn't see a > customization to automatically close those buffers. > > I can write something like: > > #+BEGIN_SRC emacs-lisp > (add-hook 'semantic-symref-results-mode-hook > (lambda () > (kill-buffers semantic-symref-recently-opened-buffers))) > #+END_SRC > > But I wanted to know if there was a built-in way to do this. > > If not, is that something people are interested in a patch for? I'm > happy to add that. That would be wonderful, many thanks! I didn't know about semantic-symref-recently-opened-buffers, so I currently do this using ibuffer, which is a pretty bad way. -mandar. |
From: Lee H. <lee...@fa...> - 2017-01-27 03:48:35
|
Hi Everyone, I currently use `semantic-symref` occasionally in my project, using the "global" method. However, I've noticed that it can sometimes open maaaaany buffers (like ~300). Is there a way to tell semantic-symref to close those buffers after it's done with the analysis? I've noticed there is a `semantic-symref-recently-opened-buffers` symbol, but I didn't see a customization to automatically close those buffers. I can write something like: #+BEGIN_SRC emacs-lisp (add-hook 'semantic-symref-results-mode-hook (lambda () (kill-buffers semantic-symref-recently-opened-buffers))) #+END_SRC But I wanted to know if there was a built-in way to do this. If not, is that something people are interested in a patch for? I'm happy to add that. -- ;; Lee |
From: Edward J. S. <edw...@gm...> - 2016-10-11 19:55:15
|
Vincent Semeria <vin...@gm...> writes: > Hello, > > On Sept 20 I sent you the previous mail about cedet not building on Windows. I managed to get the call stack leading to the error, if it can help you : > > error("Attempt to add non-object to master project list") > ede-add-project-to-global-list([eieio-class-tag--ede-proj-project "~/.emacs.d/cedet-git/lisp/Project.ede" nil "cedet-topdir" "1.1beta" "~/.emacs.d/cedet-git/lisp/" unbound nil ( > #[(this dir) "\303 \304\"\204 > #[385 " \301\302\303\304\305 !\306\"\307$\310K\311K\301\302\312\304\305 \"\313\"\307$\216\310 M\210\311 M > apply(#[385 " \301\302\303\304\305 !\306\"\307$\310K\311K\301\302\312\304\305 \"\313\"\307$\216\310 M\210\311 > #[128 "\302\300\303\304\305\306\307\301 \"\310\"\311\312% #\207" [#[385 " \301\302\303\304\305 !\306\"\307 > apply(#[128 "\302\300\303\304\305\306\307\301 \"\310\"\311\312% #\207" [#[385 " \301\302\303\304\305 !\306\"\307$\310K > ede-auto-load-project([eieio-class-tag--ede-project-autoload "Make" ede/proj "Project.ede" nil nil unbound nil ede-proj-load ede-proj-project nil t nil] "~/.emacs.d/cedet > ede-load-project-file("c:/users/inconnu/.emacs.d/cedet-git/lisp/") > (let* ((ede-project-directories t) (Tproj (ede-load-project-file (file-name-as-directory (expand-file-name d cedet-build-location))))) (cedet-build-project Tproj)) > (while --dolist-tail-- (setq d (car --dolist-tail--)) (cedet-build-msg "Building directory %s\n" d) (let* ((ede-project > (let ((--dolist-tail-- subdirs) d) (while --dolist-tail-- (setq d (car --dolist-tail--)) (cedet-build-msg "Building directory > (let ((buf (get-buffer-create "CEDET MAKE")) (pkgs nil) (subdirs (quote ("lisp")))) (cedet-build > cedet-build() > > Thanks, > Vincent > > On Tue, Sep 20, 2016 at 11:18 AM, Vincent Semeria <vin...@gm...> wrote: > > Hello, > > emacs -Q -l cedet-build.el -f cedet-build > fails after step 5 with the error > "Attempt to add non-object to master project list" > > Mind in on Windows 10, I don't know if it builds on other OS'es. > > Thanks, > Vincent > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel Hi Vincent, I mean to be taking a look at this fairly soon because I plan on contributing some work which will see (an up-to-date) CEDET packaged and distributed with the latest versions of Emacs. Until then I've found that a clean install gets rid of the error. You can do a clean build with gnuwin32 (make, makeinfo etc.). If you're not keen on installing gnuwin32, then perhaps try doing a git clean (which ought to remove all of the compiled elisp files since they aren't tracked) and then build. /I haven't tested this/. Otherwise you can try installing those gnuwin32 binaries somewhere in your path. To be clear I'm also using Windows 10 on one of my machines and with the clean build it seems to be fine for now. The problem lies in the fact that EIEIO is now (and has been for a while) developed in Emacs core. So changes to the API there need to be integrated with the CEDET project in order to avoid problems like this. Kind regards, Edward Steere |
From: Zhaohui Li <liz...@gm...> - 2016-10-06 03:11:10
|
Hello, I use stable version of cedet in Emacs 24.5. When I try to perform `semantic-grammar-create-package' on "c.by" buffer, it succeed. But when "c.by" buffer is renamed to "c.by • grammar" by plug-in "uniquify", I perform `semantic-grammar-create-package' on it, then an "Unbalanced parentheses" occurs. I have tested on other "by" files, finding that renaming buffer names in that style will lead the same error to appear. The "c.by" file is the file in emacs source code. |
From: Karthik G <xra...@gm...> - 2016-10-06 01:04:52
|
Hello, I tried installing the development version of cedet from the git repository( http://cedet.sourceforge.net/git-repo.shtml) but keep encountering *make compile Error 2*. I'm running OSX El Capitan Version 10.11.6 (15G1004). I tried running *make clean-all && make*. Gives me the same error. On running *make -d* I get the following error, Loading /Users/karthik/emacs-config/.emacs.d/cedet/cedet-remove-builtin.el (source)... Loading autoloads from CEDET development. Wrote /Users/karthik/emacs-config/.emacs.d/cedet/lisp/cedet/srecode/srt-wy.elc Reaping winning child 0x7fa7d1c11fa0 PID 1699 Removing child 0x7fa7d1c11fa0 PID 1699 from chain. Successfully remade target file `srt-wy.elc'. Finished prerequisites of target file `lang'. Must remake target `lang'. Successfully remade target file `lang'. Considering target file `srecode'. File `srecode' does not exist. Considering target file `mode.elc'. File `mode.elc' does not exist. Looking for an implicit rule for `mode.elc'. Trying pattern rule with stem `mode'. Trying implicit prerequisite `mode.el'. Found an implicit rule for `mode.elc'. Considering target file `mode.el'. Looking for an implicit rule for `mode.el'. Trying pattern rule with stem `mode.el'. Trying implicit prerequisite `mode.el,v'. Trying pattern rule with stem `mode.el'. Trying implicit prerequisite `RCS/mode.el,v'. Trying pattern rule with stem `mode.el'. Trying implicit prerequisite `RCS/mode.el'. Trying pattern rule with stem `mode.el'. Trying implicit prerequisite `s.mode.el'. Trying pattern rule with stem `mode.el'. Trying implicit prerequisite `SCCS/s.mode.el'. No implicit rule found for `mode.el'. Finished prerequisites of target file `mode.el'. No need to remake target `mode.el'. Finished prerequisites of target file `mode.elc'. Must remake target `mode.elc'. Putting child 0x7fa7d1d01080 (mode.elc) PID 1701 on the chain. Live child 0x7fa7d1d01080 (mode.elc) PID 1701 > mode.elc In toplevel form: mode.el:30:2:Error: Wrong type argument: listp, \.\.\. Reaping losing child 0x7fa7d1d01080 PID 1701 make[3]: *** [mode.elc] Error 1 Removing child 0x7fa7d1d01080 PID 1701 from chain. Reaping losing child 0x7f9573902a40 PID 1695 make[2]: *** [srecode] Error 2 Removing child 0x7f9573902a40 PID 1695 from chain. Reaping losing child 0x7fb8d8c04d50 PID 1649 make[1]: *** [cedet] Error 2 Removing child 0x7fb8d8c04d50 PID 1649 from chain. Reaping losing child 0x7fa363600660 PID 1633 make: *** [compile] Error 2 Removing child 0x7fa363600660 PID 1633 from chain. Thanks, Karthik |
From: Vincent S. <vin...@gm...> - 2016-10-01 10:23:44
|
Hello, On Sept 20 I sent you the previous mail about cedet not building on Windows. I managed to get the call stack leading to the error, if it can help you : error("Attempt to add non-object to master project list") ede-add-project-to-global-list([eieio-class-tag--ede-proj-project "~/.emacs.d/cedet-git/lisp/Project.ede" nil "cedet-topdir" "1.1beta" "~/.emacs.d/cedet-git/lisp/" unbound nil ( #[(this dir) "\303 \304\"\204 #[385 " \301\302\303\304\305 !\306\"\307$\310K\311K\301\302\312\304\305 \"\313\"\307$\216\310 M\210\311 M apply(#[385 " \301\302\303\304\305 !\306\"\307$\310K\311K\301\302\312\304\305 \"\313\"\307$\216\310 M\210\311 #[128 "\302\300\303\304\305\306\307\301 \"\310\"\311\312% #\207" [#[385 " \301\302\303\304\305 !\306\"\307 apply(#[128 "\302\300\303\304\305\306\307\301 \"\310\"\311\312% #\207" [#[385 " \301\302\303\304\305 !\306\"\307$\310K ede-auto-load-project([eieio-class-tag--ede-project-autoload "Make" ede/proj "Project.ede" nil nil unbound nil ede-proj-load ede-proj-project nil t nil] "~/.emacs.d/cedet ede-load-project-file("c:/users/inconnu/.emacs.d/cedet-git/lisp/") (let* ((ede-project-directories t) (Tproj (ede-load-project-file (file-name-as-directory (expand-file-name d cedet-build-location))))) (cedet-build-project Tproj)) (while --dolist-tail-- (setq d (car --dolist-tail--)) (cedet-build-msg "Building directory %s\n" d) (let* ((ede-project (let ((--dolist-tail-- subdirs) d) (while --dolist-tail-- (setq d (car --dolist-tail--)) (cedet-build-msg "Building directory (let ((buf (get-buffer-create "CEDET MAKE")) (pkgs nil) (subdirs (quote ("lisp")))) (cedet-build cedet-build() Thanks, Vincent On Tue, Sep 20, 2016 at 11:18 AM, Vincent Semeria <vin...@gm... > wrote: > Hello, > > emacs -Q -l cedet-build.el -f cedet-build > fails after step 5 with the error > "Attempt to add non-object to master project list" > > Mind in on Windows 10, I don't know if it builds on other OS'es. > > Thanks, > Vincent > |
From: Sunil M. <mat...@ya...> - 2016-07-11 16:30:55
|
I copied the cedet lisp setup and getting some strange errors.Any help would be appreciated as I am really looking forward to using this package for my c++ project! semantic-ia-fast-jump: seems to work most of the time. A couple of other commands produces strange error. I keep getting the following error message constantly on status bar, repeated every < 1 second.Error running timer `semantic-idle-scheduler-function': (wrong-type-argument number-or-marker-p "0x7f") When i exit emacs, i get the following prompt:Skip Error: number-or-marker-p ? (y or n) So not sure what is going on with my config. Obviously something wrong with my setup.PS. there were many setup commands that produced errors and therefore commented out. Can anyone provide any help with this ? Really looking forward to using this package !! System info:GNU Emacs 24.5.1Cedet (i beleive is built in)OS: Fedora 23Linux: 4.5.7-200.fc23.x86_64 Config lines related to cedet / symantic: (add-to-list 'load-path "/home/3plibs/lisp/cedet-bzr/contrib") (setq cedet-root-path (file-name-as-directory "/home/3plibs/lisp/cedet-bzr")) (require 'semantic/ia) ;; CC-mode (add-hook 'c-mode-hook '(lambda () (setq ac-sources (append '(ac-source-semantic) ac-sources)) (local-set-key (kbd "RET") 'newline-and-indent) (linum-mode t) (semantic-mode t))) (defun my-cedet-hook () (local-set-key [(control return)] 'semantic-ia-complete-symbol) (local-set-key "\C-c?" 'semantic-ia-complete-symbol-menu) (local-set-key "\C-c>" 'semantic-complete-analyze-inline) (local-set-key "\C-cj" 'semantic-ia-fast-jump) (local-set-key "\C-cq" 'semantic-ia-show-doc) (local-set-key "\C-cs" 'semantic-ia-show-summary) (local-set-key "\C-cp" 'semantic-analyze-proto-impl-toggle)) (add-hook 'c-mode-common-hook 'my-cedet-hook) (defun my-c-mode-cedet-hook () (local-set-key "\C-ct" 'eassist-switch-h-cpp) (local-set-key "\C-xt" 'eassist-switch-h-cpp) (local-set-key "\C-ce" 'eassist-list-methods) (local-set-key "\C-c\C-r" 'semantic-symref) ) (add-hook 'c-mode-common-hook 'my-c-mode-cedet-hook) (semanticdb-enable-gnu-global-databases 'c-mode t) (semanticdb-enable-gnu-global-databases 'c++-mode t) (setq global-semantic-tag-folding-mode 1) tia, |
From: Idar <id...@ho...> - 2016-06-27 13:09:18
|
Hello, I'm generating a compilation database from a Ninja file; the Ninja file itself having been generated by a homegrown build system. The resulting compilation database isn't directly usable by compdb, or indeed other Emacs tools. I have to "massage" it a bit first. There's already a `ede-compdb-project-rescan-hook' that is called for each buffer that is affected when the compilation database is reloaded. I'd like to suggest a `ede-compdb-project-rescan-updated-db-hook' that is called once, not per buffer, when the compilation database has been updated, but before it's processed, with the updated database as the current buffer. I'm using this to remove a couple of problematic flags from the compilation command - flags that aren't needed when used with compdb (or other Emacs tools). I'd also like to suggest a `ede-compdb-project-rescan-done-hook' that is called once when the compilation database has been fully processed. I'm using this to save the compilation database and handing it to irony-mode. These hooks are in the attached patch "0003-compdb-Adds-two-hooks-for-project-rescans-compdb.-up.patch". I've attached a couple of other patches as well. The two first are just nitpicking: - Harmonizes capitalization; Changes "Compilation Database" to "compilation database". Could have done it the other way around as well. - Skips "Reading .." message for Ninja projects and changes their "Building ..." message to a progress reporter. The fourth patch is towards an issue with which directory is used as the working directory when executing the Ninja command to build the compilation database. I've reported (and tried to explain) this issue here: <https://github.com/randomphrase/ede-compdb/issues/12> This last patch is NOT complete and will BREAK existing project setups, so I'm not suggesting applying it. It's just an example to better demonstrate the issue and what I had to change locally to make it work for my particular case. Sincerely, Idar Tollefsen |
From: Bastian B. <bas...@gm...> - 2016-06-18 10:55:18
|
CEDET / Semantic should use xref-push-marker-stack when jumping to a tag, this makes it easy to pop back to the original place. Patch for Emacs 25.0.95 is attached - but maybe there are more places that need fixing? There's also the option to put this in semantic-go-to-tag directly. |
From: Przemysław W. <esp...@cu...> - 2016-06-15 19:03:13
|
It has been a while, but... According to info:elisp#System Environment "path-separator" can be used for that purpose: -- Variable: path-separator This variable holds a string that says which character separates directories in a search path (as found in an environment variable). Its value is ‘":"’ for Unix and GNU systems, and ‘";"’ for MS systems. The simplest patch is in attachment. W dniu 14.04.2016 o 02:07, Eric Ludlam pisze: > Hi, > > I don't use maven or windows, so I don't have a good way to debug or > test. If there is a simple solution someone can verify, I'd be happy to > include the patch. > > Eric > > On 03/30/2016 04:04 AM, Przemysław Wojnowski wrote: >> I'm not a maintainer of this project, but guess that the simplest and >> fastest way would be to send a patch here. >> >> BTW the bug is reproducible only in Windows, because in >> "ede-jvm-get-classpath-from-command" there is hardcoded colon (":"), >> whereas it should be a call to a function that returns path separator or >> system dependent variable. >> >> Hope it helps. >> >> W dniu 30.03.2016 o 09:52, Vladimir Loshchin pisze: >>> All right. >>> The bug reproducing only in Windows. >>> But, how I can fix it? >>> >>> 30.03.2016 13:47, Przemysław Wojnowski пишет: >>>> Hi Vladimir, >>>> >>>> It looks like a bug, but a bit different. >>>> >>>> Maven outputs classpath using system dependent path separator (see >>>> https://docs.oracle.com/javase/8/docs/api/java/io/File.html#pathSeparatorChar), >>>> >>>> which should also be parsed in a system dependent way. On Windows it >>>> is ";", but on Linux it is ":". >>>> >>>> Cheers, >>>> Przemysław >>>> >>>> W dniu 28.03.2016 o 09:19, Владимир Лощин pisze: >>>>> Hi, everyone. Looks like, I found a bug in CEDET Maven2 support. >>>>> >>>>> When CEDET try to build java classpath, it execute /mvn >>>>> dependency:build-classpath/ (see maven2.el/ede-java-classpath). Then >>>>> CEDET parse result string splitting it by ":" separator (see: >>>>> java-base.el/ede-jvm-get-classpath-from-command). But, /mvn >>>>> dependency:build-classpath /output has ';' delimiter. >>>>> >>>>> So, the /delimiter/ parameter should be in >>>>> /ede-jvm-get-classpath-from-command /function. Or, this function >>>>> should >>>>> be overriden in /maven2.el/ module. >>>>> >>>>> How can I fix this? Email a path here? Or someone will give me >>>>> repository account? >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> Transform Data into Opportunity. >>>>> Accelerate data analysis in your applications with >>>>> Intel Data Analytics Acceleration Library. >>>>> Click to learn more. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Cedet-devel mailing list >>>>> Ced...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>>>> >>> >> >> ------------------------------------------------------------------------------ >> >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >> _______________________________________________ >> Cedet-devel mailing list >> Ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-devel >> |