cedet-devel Mailing List for CEDET (Page 3)
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...> - 2016-06-15 00:27:01
|
On 06/12/2016 11:24 AM, Alastair Rankine wrote: > Hi all, > > I have some ideas and suggestions for advancing CEDET. Some of these > have probably been brought up before, if so I apologise for the > duplication. However there may be some relatively simple steps we can > take to make CEDET more accesible, and hence more widely used. > > My impression is that there is still some reluctance to embrace CEDET, > as it has something of a reputation for being difficult to set up and > configure. Whether this reputation is justified or not, I think there > are things we can do to make CEDET more successful. Thanks for the idea list Alastair! I think this is indeed true. CEDET developed slowly over many years. A side effect is that it is a bit eclectic, and has some bad reviews of old versions out there. > 1. Packaging > > I think it would be good for CEDET to embrace packaging infrastructure > such as MELPA, in order to provide updates prior to official GNU Emacs > releases. I'm not even sure how the CEDET code migrates into Emacs, or > what the next version is going to contain. However I think that > packaging via MELPA would make this irrelevant, and significantly > lowers the barrier to installation. David Engster used to handle cross merging between the CEDET repository and Emacs, but that became more difficult over time. Once Emacs did some major refactoring to eieio, our ability to support older and newer Emacsen at the same time broke down. The next major step is to do one final merge from CEDET repository up to Emacs, or something that gets the two systems in parity. All the pieces of CEDET that are not part of Emacs would indeed work well in some other packaging scheme. > 2. Modern project hosting > > I can't be the only one who views sourceforge's increasingly dated > website as a barrier to attracting contributions to the CEDET project. > Github (or equivalent) would provide key features which we currently > lack such as a wiki, issue tracking, etc. Perhaps these features are > available with sourceforge, but regardless the user experience is far > better on Github. It was proposed to just use Emacs' repository (ie - don't have a separate repository with cross merging needed.) which I am ok with. I've been using sourceforge for a long time and it is familiar, but in the end I mostly just use the VCS which doesn't change much. > 3. Online documentation > > Sites such as readthedocs.org provide a great place to host online > documentation in a way which is navigable and usable. I think the CEDET > project has great documentation in general - but publishing it online > would make it far more accessible to people. I am not familiar with that system, but sounds interesting. I tried reading Emacs' doc (which might be there?) but couldn't figure it out in 30 seconds or less due to all the versioning hoops it asked me about. > 4. Third-party package integration > > In contributing to ede/compdb I have added some optional support for > widely used third-party packages such as Projectile, Company, etc. In > order to do this without introducing dependencies on the core CEDET > code, I think it may be possible to create non-core "glue" packages, > which provide the integration, or at least interop, with popular and > relevant third-party packages. EDE and Projectile are the main suspects > here - but there are others. The idea of creating mini packages to glue external tools into CEDET workflows was always a goal. To keep the unit together, things tended to integrate into CEDET so users could find them. With CEDET in Emacs, and many of the interfaces have been stable for a long time, having a way allow such packages to just depend on Emacs would be reasonable. > I am willing to help out where I can to enable some of these changes, > provided there is a willingness to do so. Comments appreciated. Help is what is needed most. Resolving the last merge up into Emacs, and setting up guidelines for continued development is what is most needed. I'm not too picky as long as I can keep submitting my patches and tests somewhere meaningful. Eric |
From: Alastair R. <ala...@gi...> - 2016-06-12 15:37:49
|
Hi all, I have some ideas and suggestions for advancing CEDET. Some of these have probably been brought up before, if so I apologise for the duplication. However there may be some relatively simple steps we can take to make CEDET more accesible, and hence more widely used. My impression is that there is still some reluctance to embrace CEDET, as it has something of a reputation for being difficult to set up and configure. Whether this reputation is justified or not, I think there are things we can do to make CEDET more successful. 1. Packaging I think it would be good for CEDET to embrace packaging infrastructure such as MELPA, in order to provide updates prior to official GNU Emacs releases. I'm not even sure how the CEDET code migrates into Emacs, or what the next version is going to contain. However I think that packaging via MELPA would make this irrelevant, and significantly lowers the barrier to installation. 2. Modern project hosting I can't be the only one who views sourceforge's increasingly dated website as a barrier to attracting contributions to the CEDET project. Github (or equivalent) would provide key features which we currently lack such as a wiki, issue tracking, etc. Perhaps these features are available with sourceforge, but regardless the user experience is far better on Github. 3. Online documentation Sites such as readthedocs.org provide a great place to host online documentation in a way which is navigable and usable. I think the CEDET project has great documentation in general - but publishing it online would make it far more accessible to people. 4. Third-party package integration In contributing to ede/compdb I have added some optional support for widely used third-party packages such as Projectile, Company, etc. In order to do this without introducing dependencies on the core CEDET code, I think it may be possible to create non-core "glue" packages, which provide the integration, or at least interop, with popular and relevant third-party packages. EDE and Projectile are the main suspects here - but there are others. I am willing to help out where I can to enable some of these changes, provided there is a willingness to do so. Comments appreciated. Thanks, |
From: Eric L. <er...@si...> - 2016-06-04 21:34:58
|
On 06/01/2016 03:46 PM, Servilio Afre Puentes wrote: > Hi, > > I'd like to start working on having proper Ruby language support in > CEDET. I have read the documentation and the current code in contrib, > but before I start I'd like to know if someone is already working on > this and decide on: I think someone named Dan Debertin was looking into it around 2010, but I haven't heard much about it since. He was thinking of pulling output from an external grammar into Semantic, similar to how ectags works for C++. https://sourceforge.net/p/cedet/mailman/message/25902195/ > - should I start anew? seems like things in contrib might have issues > with future maintainance[1], I'd rather avoid that if possible; The stuff in contrib cannot be integrated up into emacs, so starting fresh is important. > - what papers would I need to sign for my contribution to avoid the > issue currently faced by things in contrib? I've attached a template that can get you started. Please email to the address in the template, do not reply to this email after filling in the template. > - would it be better to start with an elpa package instead of creating > the support as part of CEDET? Any of those solutions is fine with me. If you work directly with the emacs version, that will make the below easier for us. > [1] https://sourceforge.net/p/cedet/mailman/message/34556390/ Yes, we still want to move main development up into Emacs, but it hasn't happened yet, and there is a backlog of fixes in the CEDET repository that still needs to be integrated upstream. Massive changes in eieio in Emacs has made that more difficult. I haven't really done much in CEDET lately because I feel like I'm in limbo, and don't have the time or skills to make it happen. Eric |
From: Servilio A. P. <ser...@gm...> - 2016-06-01 19:46:41
|
Hi, I'd like to start working on having proper Ruby language support in CEDET. I have read the documentation and the current code in contrib, but before I start I'd like to know if someone is already working on this and decide on: - should I start anew? seems like things in contrib might have issues with future maintainance[1], I'd rather avoid that if possible; - what papers would I need to sign for my contribution to avoid the issue currently faced by things in contrib? - would it be better to start with an elpa package instead of creating the support as part of CEDET? Servilio Footnotes: [1] https://sourceforge.net/p/cedet/mailman/message/34556390/ |
From: Simon B. <li...@70...> - 2016-04-25 10:42:16
|
Hi Eric, On Thu, 14 Apr 2016, at 12:45 AM, Eric Ludlam wrote: > On 03/24/2016 02:55 AM, Mandar Mitra wrote: > > Simon Brown wrote (Wed, Mar 23, 2016 at 07:13:23PM +0000): > >> Hello, > >> > >> With latest cedet (4b41ea6) There seems to be an interaction problem > >> with code completion. In the attached file if you try to complete line > >> 15 with C-M-i you get an error: > >> > >> completion-in-region: Assertion failed: (<= start (point)), #<marker at > >> 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 > >> > >> I use company mode for completion and when this happens the point jumps > >> to the start of line 6 which is annoying. If I switch to built in cedet > >> the problem goes away. I don't know if this is a cedet bug or if it > >> belongs elsewhere. It was reported to the company mode project here: > >> https://github.com/company-mode/company-mode/issues/419 > >> > >> So it's been present for some months. Any suggestions on how to debug > >> it? > > > > > > I've observed a possibly related problem, but didn't know where to report it / how to debug it. > > > > I have "." and ">" bound to a variant of semantic-complete-self-insert for completion of struct fields. When I type "x." or "x->" a menu of possible fields comes up, but on selecting one of them, point jumps to the structure definition instead of filling in the field name. I can't even go back where I was with C-u C-SPC. > > Hi Simon and Mandar, > > Sorry for a late reply. > > I fixed a bug similar to what Mandar is reporting in March, though I > found it in Java, and specifically if the object field I was expanding > was inside a call to another function. ie - > > obj.method(obj2.completeme > > I submitted that fix in 4a4801. > > I wasn't able to reproduced Simon's problem, perhaps because of this > fix. That isn't clear to me. > > Can you guys try out the latest version to see if that helps? With 4a4801 I'm not seeing the bug any more with the test app, thank you. If I see it again elsewhere I'll come back to this thread. Simon |
From: Eric L. <er...@si...> - 2016-04-14 00:07:19
|
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 > |
From: Eric L. <er...@si...> - 2016-04-13 23:45:16
|
On 03/24/2016 02:55 AM, Mandar Mitra wrote: > Simon Brown wrote (Wed, Mar 23, 2016 at 07:13:23PM +0000): >> Hello, >> >> With latest cedet (4b41ea6) There seems to be an interaction problem >> with code completion. In the attached file if you try to complete line >> 15 with C-M-i you get an error: >> >> completion-in-region: Assertion failed: (<= start (point)), #<marker at >> 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 >> >> I use company mode for completion and when this happens the point jumps >> to the start of line 6 which is annoying. If I switch to built in cedet >> the problem goes away. I don't know if this is a cedet bug or if it >> belongs elsewhere. It was reported to the company mode project here: >> https://github.com/company-mode/company-mode/issues/419 >> >> So it's been present for some months. Any suggestions on how to debug >> it? > > > I've observed a possibly related problem, but didn't know where to report it / how to debug it. > > I have "." and ">" bound to a variant of semantic-complete-self-insert for completion of struct fields. When I type "x." or "x->" a menu of possible fields comes up, but on selecting one of them, point jumps to the structure definition instead of filling in the field name. I can't even go back where I was with C-u C-SPC. Hi Simon and Mandar, Sorry for a late reply. I fixed a bug similar to what Mandar is reporting in March, though I found it in Java, and specifically if the object field I was expanding was inside a call to another function. ie - obj.method(obj2.completeme I submitted that fix in 4a4801. I wasn't able to reproduced Simon's problem, perhaps because of this fix. That isn't clear to me. Can you guys try out the latest version to see if that helps? Thanks Eric |
From: Przemysław W. <esp...@cu...> - 2016-03-30 08:06:16
|
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 > |
From: Przemysław W. <esp...@cu...> - 2016-03-30 08:04:22
|
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 >>> > |
From: Vladimir L. <vla...@gm...> - 2016-03-30 07:52:07
|
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 >> |
From: Edward S. <edw...@gm...> - 2016-03-29 18:07:50
|
Hi All, Found a mistake in my original patch. I used `projectile-all-project-files’ but I should have been using `projectile-current-project-files’. Please find an updated patch attached. Kind regards, Edward Steere |
From: Владимир Л. <vla...@gm...> - 2016-03-28 07:19:22
|
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? |
From: Edward S. <edw...@gm...> - 2016-03-26 20:17:30
|
Hi, I was able to reproduce this locally and found that the problem stems from the `semantic-analyse-possible-completions-default’ function. The problem appears to be that something in there is moving the point outside of a `save-excursion’. To confirm my theory I evaluated the following snippet: (advice-add 'semantic-analyze-possible-completions-default :around '(lambda (orig-fun &rest args) (save-excursion (apply orig-fun args)))) And with that it appears to be working again. I can take a deeper look and find out what’s going wrong when I get time, but for now this hack should mask the problem. You can add that to your .emacs and your completions should be working as normal in the interim. Kind regards, Edward Steere > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Mar 2016 19:13:23 +0000 > From: Simon Brown <li...@70...> > Subject: [CEDET-devel] BUG completion in region > To: ced...@li... > Message-ID: > <145...@we...> > Content-Type: text/plain; charset="us-ascii" > > Hello, > > With latest cedet (4b41ea6) There seems to be an interaction problem > with code completion. In the attached file if you try to complete line > 15 with C-M-i you get an error: > > completion-in-region: Assertion failed: (<= start (point)), #<marker at > 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 > > I use company mode for completion and when this happens the point jumps > to the start of line 6 which is annoying. If I switch to built in cedet > the problem goes away. I don't know if this is a cedet bug or if it > belongs elsewhere. It was reported to the company mode project here: > https://github.com/company-mode/company-mode/issues/419 > > So it's been present for some months. Any suggestions on how to debug > it? > > Simon > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: cedetBug.c > Type: text/x-csrc > Size: 249 bytes > Desc: not available > > ------------------------------ > > Message: 2 > Date: Thu, 24 Mar 2016 12:25:02 +0530 > From: Mandar Mitra <man...@gm...> > Subject: Re: [CEDET-devel] BUG completion in region > To: Simon Brown <li...@70...> > Cc: ced...@li... > Message-ID: <201...@gm...> > Content-Type: text/plain; charset=us-ascii > > Simon Brown wrote (Wed, Mar 23, 2016 at 07:13:23PM +0000): >> Hello, >> >> With latest cedet (4b41ea6) There seems to be an interaction problem >> with code completion. In the attached file if you try to complete line >> 15 with C-M-i you get an error: >> >> completion-in-region: Assertion failed: (<= start (point)), #<marker at >> 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 >> >> I use company mode for completion and when this happens the point jumps >> to the start of line 6 which is annoying. If I switch to built in cedet >> the problem goes away. I don't know if this is a cedet bug or if it >> belongs elsewhere. It was reported to the company mode project here: >> https://github.com/company-mode/company-mode/issues/419 >> >> So it's been present for some months. Any suggestions on how to debug >> it? > > > I've observed a possibly related problem, but didn't know where to report it / how to debug it. > > I have "." and ">" bound to a variant of semantic-complete-self-insert for completion of struct fields. When I type "x." or "x->" a menu of possible fields comes up, but on selecting one of them, point jumps to the structure definition instead of filling in the field name. I can't even go back where I was with C-u C-SPC. |
From: Edward S. <edw...@gm...> - 2016-03-26 18:07:50
|
Hi Again, After submitting I noticed a typo I made. Please find an updated version of the patch attached. Kind regards, Edward Steere |
From: Edward S. <edw...@gm...> - 2016-03-26 14:50:14
|
Hi All, Patch 4/4. This one is super simple. I just added three items to the .gitignore to clean up the view from git’s perspective. Kind Regards, Edward Steere |
From: Edward S. <edw...@gm...> - 2016-03-26 14:50:02
|
Hi All, This is patch 3/4. I found that the performance of semantic for navigating between project files using ia fast jump left a lot to be desired in large java projects. The major culprit appears to be file-truename. Both for the amount of memory it allocates (and therefore automatic GC time it triggers) and for the time it takes to check for symlinks in the file system etc. This patch adds a global switch (`ede-ignore-symlinks’) across CEDET which will use `expand-filename’ when the switch is non-nil. An alternative to this might be to add it to the base project object as a switch so that one can control the behaviour on a per-project basis. I’d be happy to implement the later or a combination depending on what is decided. Kind regards, Edward Steere |
From: Edward S. <edw...@gm...> - 2016-03-26 14:49:52
|
Hi All, This is patch 2/4. It's a fix for overlays from the decorate package. It looks like the interface to `semantic-tag-create-secondary-overlay' changed somewhere along the line. When tags are linked to the buffer, the overlays are removed and then re-added using the unlink/link hooks. `semantic—tag-link-secondary-overlays’ tried to fetch the list of secondary overlays on a tag, remove them from the tag object and then re add each of them in turn. However, it passed the tag and the overlay to the `semantic-tag-create-secondary-overlay’ which should instead accept the tag and a link hook to run once the secondary overlay has been created. This produces several error messages similar to the following “Error wrong type argument: symbolp #<overlay …" I’m unsure whether by making my change I’ve broken the intended way for this to work — i.e. that there are multiple overlays which ought to be added one after the other — but it does look like it wasn’t working altogether without this fix. Kind regards, Edward Steere |
From: Edward S. <edw...@gm...> - 2016-03-26 14:49:45
|
Hi All, This is the first in a series of four patches I’m submitting today. This one adds support for projectile to EDE-locate. The implementation is very simple, it just uses projectile as a way of getting a list of files for this project. When we search for a file it just runs filesubstring as a regular expression against all those files. Usage: (setq ede-locate-setup-options '(ede-locate-projectile ede-locate-base)) Originally I wanted to store the files in a trie using the trie library, but that seems to run into problems with the size of keys (absolute paths) for java projects. I find that this implementation works well enough ito performance across the various machines which I use. Kind regards, Edward Steere |
From: Mandar M. <man...@gm...> - 2016-03-24 06:54:46
|
Simon Brown wrote (Wed, Mar 23, 2016 at 07:13:23PM +0000): > Hello, > > With latest cedet (4b41ea6) There seems to be an interaction problem > with code completion. In the attached file if you try to complete line > 15 with C-M-i you get an error: > > completion-in-region: Assertion failed: (<= start (point)), #<marker at > 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 > > I use company mode for completion and when this happens the point jumps > to the start of line 6 which is annoying. If I switch to built in cedet > the problem goes away. I don't know if this is a cedet bug or if it > belongs elsewhere. It was reported to the company mode project here: > https://github.com/company-mode/company-mode/issues/419 > > So it's been present for some months. Any suggestions on how to debug > it? I've observed a possibly related problem, but didn't know where to report it / how to debug it. I have "." and ">" bound to a variant of semantic-complete-self-insert for completion of struct fields. When I type "x." or "x->" a menu of possible fields comes up, but on selecting one of them, point jumps to the structure definition instead of filling in the field name. I can't even go back where I was with C-u C-SPC. |
From: Simon B. <li...@70...> - 2016-03-23 19:13:30
|
Hello, With latest cedet (4b41ea6) There seems to be an interaction problem with code completion. In the attached file if you try to complete line 15 with C-M-i you get an error: completion-in-region: Assertion failed: (<= start (point)), #<marker at 228 in /home/smb/Desktop/Cedet Bug/cedetBug.c>, 66 I use company mode for completion and when this happens the point jumps to the start of line 6 which is annoying. If I switch to built in cedet the problem goes away. I don't know if this is a cedet bug or if it belongs elsewhere. It was reported to the company mode project here: https://github.com/company-mode/company-mode/issues/419 So it's been present for some months. Any suggestions on how to debug it? Simon |
From: Eric L. <er...@si...> - 2016-03-19 20:53:10
|
On 03/14/2016 09:28 PM, Chream wrote: > The core jar on OS X elcapitain > > ProductName:Mac OS X > ProductVersion:10.11.3 > BuildVersion:15D21 > > is now in the same path as for other operating systems. > Not sure when this happened and I am not sure how to check for OS X > version in emacs. > My modified code now works for for cedet to locate the rt.jar. > > *Current cedet code::* > > (defvar cedet-java-core-jar-name (if (eq system-type 'darwin) > "Contents/Classes/classes.jar" > (concat (file-name-as-directory > (concat (file-name-as-directory "jre") "lib")) > "rt.jar")) > "Name of Java core jar file. > File name is rt.jar on Linux & Windows, and classes.jar on Mac OS X") > > *Modified code::* > > (defvar cedet-java-core-jar-name (concat (file-name-as-directory > (concat > (file-name-as-directory "jre") "lib")) > "rt.jar") > "Name of Java core jar file. > File name is rt.jar on Linux & Windows, and classes.jar on Mac OS X") I need some help from Java users to evaluate this. There is a bunch of code for detecting the root, and identifying the core jar file. It looks like we could try to support both variants on Mac if it is worth while. Thanks Eric |
From: Chream <chr...@gm...> - 2016-03-15 01:28:48
|
The core jar on OS X elcapitain ProductName: Mac OS X ProductVersion: 10.11.3 BuildVersion: 15D21 is now in the same path as for other operating systems. Not sure when this happened and I am not sure how to check for OS X version in emacs. My modified code now works for for cedet to locate the rt.jar. Current cedet code:: (defvar cedet-java-core-jar-name (if (eq system-type 'darwin) "Contents/Classes/classes.jar" (concat (file-name-as-directory (concat (file-name-as-directory "jre") "lib")) "rt.jar")) "Name of Java core jar file. File name is rt.jar on Linux & Windows, and classes.jar on Mac OS X") Modified code:: (defvar cedet-java-core-jar-name (concat (file-name-as-directory (concat (file-name-as-directory "jre") "lib")) "rt.jar") "Name of Java core jar file. File name is rt.jar on Linux & Windows, and classes.jar on Mac OS X") |
From: Edward S. <edw...@gm...> - 2016-03-08 15:40:36
|
Hi Eric, I replied a few days ago and accidentally left out the mailing list... If I evaluate (file-name-directory (directory-file-name "~/")) on my system I get nil. This will be the value bound to updir in ede--detect-ldf-root-predicate. It looks like on my systems this will only happen when the project is contained in my home directory. Just tested root (i.e. "/") and I actually get "/" so I was wrong about that one -- works with lettered drives in Windows too by the looks of things. I run into the same problem without this patch on all my machines: - Desktop running Emacs 24.5.1 and Windows 10 - Laptop running Emacs 24.5.1 and Windows 8 - Desktop running Emacs 24.5.1 and Windows 7 - Macbook running Emacs 24.5 (I think) and Yosemite Kind Regards, Ed > On 03 Mar 2016, at 3:32 AM, Eric Ludlam <er...@si...> wrote: > > On 02/27/2016 03:54 PM, Edward Steere wrote: >> Hi All, >> >> My name is Edward and I’m an avid Emacs user. >> I enjoy using CEDET and I’ve decided to take the plunge and see if I can be helpful re. bug fixes and the like. >> >> Please find attached a patch for generic projects detection. >> This feature outright didn’t work on any of my machines until I made these changes (see attached backtrace). >> If I’ve missed something (e.g. I should have turned on a feature to make this work) then please let me know and I’d be happy to test it and report back. > > Thanks Ed, > > I have the generic project system turned on (as I run all the things for random testing purposes) and never ran into this case. What platform are you on? Is there anything special about your system that lets emacs return nil for some of it's file system calls? > > I installed your patch locally, and it passes all the tests, which didn't surprise me. I'm mostly curious what the special case might be so I can add it into my checkin comments. > > Thanks > Eric |
From: Eric L. <er...@si...> - 2016-03-03 01:32:18
|
On 02/27/2016 03:54 PM, Edward Steere wrote: > Hi All, > > My name is Edward and I’m an avid Emacs user. > I enjoy using CEDET and I’ve decided to take the plunge and see if I can be helpful re. bug fixes and the like. > > Please find attached a patch for generic projects detection. > This feature outright didn’t work on any of my machines until I made these changes (see attached backtrace). > If I’ve missed something (e.g. I should have turned on a feature to make this work) then please let me know and I’d be happy to test it and report back. Thanks Ed, I have the generic project system turned on (as I run all the things for random testing purposes) and never ran into this case. What platform are you on? Is there anything special about your system that lets emacs return nil for some of it's file system calls? I installed your patch locally, and it passes all the tests, which didn't surprise me. I'm mostly curious what the special case might be so I can add it into my checkin comments. Thanks Eric |
From: Edward S. <edw...@gm...> - 2016-02-27 20:54:44
|
Hi All, My name is Edward and I’m an avid Emacs user. I enjoy using CEDET and I’ve decided to take the plunge and see if I can be helpful re. bug fixes and the like. Please find attached a patch for generic projects detection. This feature outright didn’t work on any of my machines until I made these changes (see attached backtrace). If I’ve missed something (e.g. I should have turned on a feature to make this work) then please let me know and I’d be happy to test it and report back. Kind regards, Ed |