cedet-semantic Mailing List for CEDET
Brought to you by:
zappo
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(44) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(15) |
Feb
(15) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(14) |
Jul
(7) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(11) |
Dec
(18) |
2003 |
Jan
(36) |
Feb
(21) |
Mar
(36) |
Apr
(17) |
May
(48) |
Jun
(8) |
Jul
(6) |
Aug
(10) |
Sep
(14) |
Oct
(12) |
Nov
(43) |
Dec
(61) |
2004 |
Jan
(40) |
Feb
(69) |
Mar
(44) |
Apr
(57) |
May
(48) |
Jun
(36) |
Jul
(45) |
Aug
(29) |
Sep
(11) |
Oct
(28) |
Nov
(19) |
Dec
(23) |
2005 |
Jan
(55) |
Feb
(37) |
Mar
(24) |
Apr
(17) |
May
(10) |
Jun
|
Jul
(19) |
Aug
(7) |
Sep
(19) |
Oct
(21) |
Nov
(13) |
Dec
(12) |
2006 |
Jan
(21) |
Feb
(15) |
Mar
(51) |
Apr
(5) |
May
(6) |
Jun
(25) |
Jul
(11) |
Aug
(13) |
Sep
(16) |
Oct
(16) |
Nov
(1) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(6) |
May
(28) |
Jun
(37) |
Jul
(19) |
Aug
(21) |
Sep
(25) |
Oct
(8) |
Nov
(4) |
Dec
(9) |
2008 |
Jan
(9) |
Feb
(40) |
Mar
(49) |
Apr
(28) |
May
(83) |
Jun
(17) |
Jul
(20) |
Aug
(12) |
Sep
(22) |
Oct
(29) |
Nov
(41) |
Dec
(67) |
2009 |
Jan
(12) |
Feb
(46) |
Mar
(67) |
Apr
(12) |
May
(25) |
Jun
(61) |
Jul
(44) |
Aug
(43) |
Sep
(35) |
Oct
(22) |
Nov
(27) |
Dec
(21) |
2010 |
Jan
(26) |
Feb
(24) |
Mar
(30) |
Apr
(23) |
May
(55) |
Jun
(21) |
Jul
(12) |
Aug
(28) |
Sep
(60) |
Oct
(38) |
Nov
(16) |
Dec
(10) |
2011 |
Jan
(15) |
Feb
(23) |
Mar
(9) |
Apr
(9) |
May
|
Jun
(21) |
Jul
(32) |
Aug
(45) |
Sep
(38) |
Oct
(28) |
Nov
(14) |
Dec
(4) |
2012 |
Jan
(8) |
Feb
(22) |
Mar
(17) |
Apr
(13) |
May
(7) |
Jun
(21) |
Jul
(18) |
Aug
(7) |
Sep
(46) |
Oct
(94) |
Nov
(17) |
Dec
(12) |
2013 |
Jan
(33) |
Feb
(30) |
Mar
(62) |
Apr
(64) |
May
(15) |
Jun
(22) |
Jul
(22) |
Aug
(8) |
Sep
(7) |
Oct
(15) |
Nov
(17) |
Dec
(11) |
2014 |
Jan
(1) |
Feb
(5) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(18) |
Oct
(24) |
Nov
(22) |
Dec
(23) |
2015 |
Jan
(11) |
Feb
(29) |
Mar
(7) |
Apr
(8) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(24) |
Sep
(2) |
Oct
(19) |
Nov
(13) |
Dec
(8) |
2016 |
Jan
(2) |
Feb
(22) |
Mar
(12) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(6) |
Sep
(14) |
Oct
(7) |
Nov
(1) |
Dec
|
2017 |
Jan
(9) |
Feb
(2) |
Mar
(1) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2018 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(4) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christian J. <chr...@cv...> - 2020-06-16 09:21:01
|
Hi, I found a work-around that seems to work in Wisent, just start grammar with %empty: () ; and the parser doesn't complain anymore on any %empty usage in grammar. I'm working on a Elisp tool that converts GNU Bison / YACC grammar into Wisent Elisp. The trickies parts are solved, at least for my usage, converting C into Elisp (from the offical PHP YACC grammar). I have some smaller items left before it's done though. https://github.com/cjohansson/emacs-wisent-grammar-converter Best regards Christian On 16/06/2020 02:46, Eric Ludlam wrote: > I wasn't familiar with %empty, but based on what I read for bison, you > can just omit it. Even in bison, you need a special flag in order to > get warnings indicating you need to add the %empty in. > > Hopefully that works for you. I haven't done any coding in this tool > in a long time and am not the original wisent author either. :( > > Eric > > On 6/14/20 5:32 PM, Christian Johansson wrote: >> Hi Eric! >> >> Alright, I don’t just want to create tags, I would like to build a >> complete AST equivalent of the PHP AST. Can you improve the Wisent >> parser to fully support GNU Bison? Or is there a work-around I can >> use to make the gramnar work? >> >> Ideally I would like to spot code parser errors in Elisp without >> having to run the code via a PHP runtime executable. >> >> Best regards >> Christian >> >> 14 juni 2020 kl. 22:21 skrev Christian Johansson <chr...@cv... >> <mailto:chr...@cv...>>: >> >>> Hi Eric! >>> >>> Alright, I don’t just want to create tags, I would like to build a >>> complete AST equivalent of the PHP AST. Can you improve the Wisent q >>> >>>> 13 juni 2020 kl. 21:36 skrev Eric Ludlam <er...@si... >>>> <mailto:er...@si...>>: >>>> >>>> Hi Christian, >>>> >>>> Using %prec, etc doesn't occur much in Wisent grammars because the >>>> usual use case is to generate tags, and not evaluate code that >>>> requires precedence. If your goal is to just generate tags, there >>>> is a good chance you can just ignore the %prec pieces of the rule. >>>> If the precedence is not used in expressions used after an equal, >>>> then you may be able to just delete the whole rule backup_fn_flags. >>>> >>>> A quick read of bison %empty indicates it can be safely left out as >>>> well, so if you need to keep the rule, just delete %empty. >>>> >>>> Hope this helps. >>>> Eric >>>> >>>>> On 6/6/20 1:47 AM, Christian Johansson wrote: >>>>> Hi! >>>>> I'm translating the PHP bison grammar to wisent and currently I'm >>>>> stuck at a rule that looks like this: >>>>> backup_fn_flags: >>>>> %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); >>>>> CG(extra_fn_flags) = 0; } >>>>> ; >>>>> The %prec symbol seems to work with Wisent but for the %empty I >>>>> get the message "wisent-parse-nonterminals: Symbol ‘%empty’ is >>>>> used, but is not defined as a token and has no rules" >>>>> Is it possible to solve this? >>>>> For empty %empty rules I just replace %empty with ;; empty\n but I >>>>> don't know what to do when there are other nonterminals in the rule >>> >>> >>> >>> _______________________________________________ >>> cedet-semantic mailing list >>> ced...@li... >>> <mailto:ced...@li...> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic |
From: Eric L. <er...@si...> - 2020-06-16 00:46:31
|
I wasn't familiar with %empty, but based on what I read for bison, you can just omit it. Even in bison, you need a special flag in order to get warnings indicating you need to add the %empty in. Hopefully that works for you. I haven't done any coding in this tool in a long time and am not the original wisent author either. :( Eric On 6/14/20 5:32 PM, Christian Johansson wrote: > Hi Eric! > > Alright, I don’t just want to create tags, I would like to build a > complete AST equivalent of the PHP AST. Can you improve the Wisent > parser to fully support GNU Bison? Or is there a work-around I can use > to make the gramnar work? > > Ideally I would like to spot code parser errors in Elisp without having > to run the code via a PHP runtime executable. > > Best regards > Christian > > 14 juni 2020 kl. 22:21 skrev Christian Johansson <chr...@cv... > <mailto:chr...@cv...>>: > >> Hi Eric! >> >> Alright, I don’t just want to create tags, I would like to build a >> complete AST equivalent of the PHP AST. Can you improve the Wisent q >> >>> 13 juni 2020 kl. 21:36 skrev Eric Ludlam <er...@si... >>> <mailto:er...@si...>>: >>> >>> Hi Christian, >>> >>> Using %prec, etc doesn't occur much in Wisent grammars because the >>> usual use case is to generate tags, and not evaluate code that >>> requires precedence. If your goal is to just generate tags, there is >>> a good chance you can just ignore the %prec pieces of the rule. If >>> the precedence is not used in expressions used after an equal, then >>> you may be able to just delete the whole rule backup_fn_flags. >>> >>> A quick read of bison %empty indicates it can be safely left out as >>> well, so if you need to keep the rule, just delete %empty. >>> >>> Hope this helps. >>> Eric >>> >>>> On 6/6/20 1:47 AM, Christian Johansson wrote: >>>> Hi! >>>> I'm translating the PHP bison grammar to wisent and currently I'm >>>> stuck at a rule that looks like this: >>>> backup_fn_flags: >>>> %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); >>>> CG(extra_fn_flags) = 0; } >>>> ; >>>> The %prec symbol seems to work with Wisent but for the %empty I get >>>> the message "wisent-parse-nonterminals: Symbol ‘%empty’ is used, but >>>> is not defined as a token and has no rules" >>>> Is it possible to solve this? >>>> For empty %empty rules I just replace %empty with ;; empty\n but I >>>> don't know what to do when there are other nonterminals in the rule >> >> >> >> _______________________________________________ >> cedet-semantic mailing list >> ced...@li... >> <mailto:ced...@li...> >> https://lists.sourceforge.net/lists/listinfo/cedet-semantic |
From: Christian J. <chr...@cv...> - 2020-06-15 10:51:15
|
Ok thanks, I’ll check it out. I’ll consider what alternative is the most feasible.. maybe a reduced grammar would be good enough to spot syntax errors in a buffer Regards Christian > 15 juni 2020 kl. 11:42 skrev Stephen Leake <ste...@st...>: > > Christian Johansson <chr...@cv...> writes: > >> Alright, I don’t just want to create tags, I would like to build a >> complete AST equivalent of the PHP AST. Can you improve the Wisent >> parser to fully support GNU Bison? Or is there a work-around I can use >> to make the gramnar work? > > You can use the GNU ELPA wisi package; it provides an error correcting > LR grammar generator and parser (equivalent to Bison, possibly better > error correction). It does not provide the AST to elisp (the AST is used > internally to compute indentation, navigation, faces), but it would be > straight-forward to add that. It does provide parse errors to elisp, as > both a text message and edit instructions. > >> Ideally I would like to spot code parser errors in Elisp without >> having to run the code via a PHP runtime executable. > > The wisi parser is implemented in Ada and runs in a background process; > I'm not clear if that is better than running PHP in a background process. > > -- > -- Stephe |
From: Stephen L. <ste...@st...> - 2020-06-15 10:05:46
|
Christian Johansson <chr...@cv...> writes: > Alright, I don’t just want to create tags, I would like to build a > complete AST equivalent of the PHP AST. Can you improve the Wisent > parser to fully support GNU Bison? Or is there a work-around I can use > to make the gramnar work? You can use the GNU ELPA wisi package; it provides an error correcting LR grammar generator and parser (equivalent to Bison, possibly better error correction). It does not provide the AST to elisp (the AST is used internally to compute indentation, navigation, faces), but it would be straight-forward to add that. It does provide parse errors to elisp, as both a text message and edit instructions. > Ideally I would like to spot code parser errors in Elisp without > having to run the code via a PHP runtime executable. The wisi parser is implemented in Ada and runs in a background process; I'm not clear if that is better than running PHP in a background process. -- -- Stephe |
From: Christian J. <chr...@cv...> - 2020-06-14 21:33:06
|
Hi Eric! Alright, I don’t just want to create tags, I would like to build a complete AST equivalent of the PHP AST. Can you improve the Wisent parser to fully support GNU Bison? Or is there a work-around I can use to make the gramnar work? Ideally I would like to spot code parser errors in Elisp without having to run the code via a PHP runtime executable. Best regards Christian > 14 juni 2020 kl. 22:21 skrev Christian Johansson <chr...@cv...>: > > Hi Eric! > > Alright, I don’t just want to create tags, I would like to build a complete AST equivalent of the PHP AST. Can you improve the Wisent q > >> 13 juni 2020 kl. 21:36 skrev Eric Ludlam <er...@si...>: >> >> Hi Christian, >> >> Using %prec, etc doesn't occur much in Wisent grammars because the usual use case is to generate tags, and not evaluate code that requires precedence. If your goal is to just generate tags, there is a good chance you can just ignore the %prec pieces of the rule. If the precedence is not used in expressions used after an equal, then you may be able to just delete the whole rule backup_fn_flags. >> >> A quick read of bison %empty indicates it can be safely left out as well, so if you need to keep the rule, just delete %empty. >> >> Hope this helps. >> Eric >> >>> On 6/6/20 1:47 AM, Christian Johansson wrote: >>> Hi! >>> I'm translating the PHP bison grammar to wisent and currently I'm stuck at a rule that looks like this: >>> backup_fn_flags: >>> %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); CG(extra_fn_flags) = 0; } >>> ; >>> The %prec symbol seems to work with Wisent but for the %empty I get the message "wisent-parse-nonterminals: Symbol ‘%empty’ is used, but is not defined as a token and has no rules" >>> Is it possible to solve this? >>> For empty %empty rules I just replace %empty with ;; empty\n but I don't know what to do when there are other nonterminals in the rule > > > > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic |
From: Christian J. <chr...@cv...> - 2020-06-14 20:38:29
|
Hi Eric! Alright, I don’t just want to create tags, I would like to build a complete AST equivalent of the PHP AST. Can you improve the Wisent q > 13 juni 2020 kl. 21:36 skrev Eric Ludlam <er...@si...>: > > Hi Christian, > > Using %prec, etc doesn't occur much in Wisent grammars because the usual use case is to generate tags, and not evaluate code that requires precedence. If your goal is to just generate tags, there is a good chance you can just ignore the %prec pieces of the rule. If the precedence is not used in expressions used after an equal, then you may be able to just delete the whole rule backup_fn_flags. > > A quick read of bison %empty indicates it can be safely left out as well, so if you need to keep the rule, just delete %empty. > > Hope this helps. > Eric > >> On 6/6/20 1:47 AM, Christian Johansson wrote: >> Hi! >> I'm translating the PHP bison grammar to wisent and currently I'm stuck at a rule that looks like this: >> backup_fn_flags: >> %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); CG(extra_fn_flags) = 0; } >> ; >> The %prec symbol seems to work with Wisent but for the %empty I get the message "wisent-parse-nonterminals: Symbol ‘%empty’ is used, but is not defined as a token and has no rules" >> Is it possible to solve this? >> For empty %empty rules I just replace %empty with ;; empty\n but I don't know what to do when there are other nonterminals in the rule |
From: Eric L. <er...@si...> - 2020-06-13 19:36:20
|
Hi Christian, Using %prec, etc doesn't occur much in Wisent grammars because the usual use case is to generate tags, and not evaluate code that requires precedence. If your goal is to just generate tags, there is a good chance you can just ignore the %prec pieces of the rule. If the precedence is not used in expressions used after an equal, then you may be able to just delete the whole rule backup_fn_flags. A quick read of bison %empty indicates it can be safely left out as well, so if you need to keep the rule, just delete %empty. Hope this helps. Eric On 6/6/20 1:47 AM, Christian Johansson wrote: > Hi! > > I'm translating the PHP bison grammar to wisent and currently I'm stuck > at a rule that looks like this: > > backup_fn_flags: > %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); > CG(extra_fn_flags) = 0; } > ; > > The %prec symbol seems to work with Wisent but for the %empty I get the > message "wisent-parse-nonterminals: Symbol ‘%empty’ is used, but is not > defined as a token and has no rules" > > Is it possible to solve this? > > For empty %empty rules I just replace %empty with ;; empty\n but I don't > know what to do when there are other nonterminals in the rule > |
From: Christian J. <chr...@cv...> - 2020-06-06 06:22:22
|
Hi! I'm translating the PHP bison grammar to wisent and currently I'm stuck at a rule that looks like this: backup_fn_flags: %prec PREC_ARROW_FUNCTION %empty { $$ = CG(extra_fn_flags); CG(extra_fn_flags) = 0; } ; The %prec symbol seems to work with Wisent but for the %empty I get the message "wisent-parse-nonterminals: Symbol ‘%empty’ is used, but is not defined as a token and has no rules" Is it possible to solve this? For empty %empty rules I just replace %empty with ;; empty\n but I don't know what to do when there are other nonterminals in the rule -- Hälsningar / Best Regards Christian |
From: Anand T. <ata...@gm...> - 2019-12-05 13:09:32
|
Auto-completion in overloading scenario. |
From: Anand T. <ata...@gm...> - 2019-12-02 06:10:30
|
Hi Eric, I have posted the announcement on emacs DL. CEDET definitely needs more eyeballs even if it doesn't get adoption. It was way ahead of its time. So it surprises me that LSP has generated more buzz than CEDET even in emacs circle. Regards, Anand On Mon, Dec 2, 2019 at 3:16 AM Eric Ludlam <er...@si...> wrote: > Hi Anand, > > Looks good! It is nice to see the tools let you work across langauges > as well. These are the types of tools cedet was meant to support, even > though I never got that far. > > It would be nice to share the tools in broader circles in case others > can adapt to even more languages. I'm not sure how many are left on > this mailing list. > > Eric > > On 12/1/19 3:55 AM, Anand Tamariya wrote: > > Hi, > > I've implemented following refactoring commands for Java. > > - Extract method > > - Extract interface > > - Implement interface > > - Pull up method > > - Find references > > - Rename variables and methods > > > > The video also demonstrates power of CEDET semantic. Same command is > > used to extract method both from Java and Lisp code. It might still be > > rough around the edges. Patches and feedback are welcome. > > > > Demo: > > https://youtu.be/zmRac_BNbv0 > > > > Regards, > > Anand > > > > > > _______________________________________________ > > cedet-semantic mailing list > > ced...@li... > > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > > > |
From: Eric L. <er...@si...> - 2019-12-01 21:46:57
|
Hi Anand, Looks good! It is nice to see the tools let you work across langauges as well. These are the types of tools cedet was meant to support, even though I never got that far. It would be nice to share the tools in broader circles in case others can adapt to even more languages. I'm not sure how many are left on this mailing list. Eric On 12/1/19 3:55 AM, Anand Tamariya wrote: > Hi, > I've implemented following refactoring commands for Java. > - Extract method > - Extract interface > - Implement interface > - Pull up method > - Find references > - Rename variables and methods > > The video also demonstrates power of CEDET semantic. Same command is > used to extract method both from Java and Lisp code. It might still be > rough around the edges. Patches and feedback are welcome. > > Demo: > https://youtu.be/zmRac_BNbv0 > > Regards, > Anand > > > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > |
From: Anand T. <ata...@gm...> - 2019-12-01 08:55:26
|
Hi, I've implemented following refactoring commands for Java. - Extract method - Extract interface - Implement interface - Pull up method - Find references - Rename variables and methods The video also demonstrates power of CEDET semantic. Same command is used to extract method both from Java and Lisp code. It might still be rough around the edges. Patches and feedback are welcome. Demo: https://youtu.be/zmRac_BNbv0 Regards, Anand |
From: Eric L. <er...@si...> - 2019-11-25 16:07:14
|
On 11/25/19 10:40 AM, Dmitry Gutov wrote: > On 25.11.2019 17:32, Eric Ludlam wrote: > >> They already are minor modes. You have to turn them on, and they >> happen to depend on CEDET. > > I meant to make them not depend on CEDET, and move into core Emacs, for > instance. CEDET could still configure resulting modes (when installed) > via hooks. > Several are all in core Emacs already. Not sure how they could not depend on CEDET. They are all about using the data it provides. This is my setup with nothing extra installed: (require 'semantic) (add-to-list 'semantic-new-buffer-setup-functions '(emacs-lisp-mode . semantic-default-elisp-setup) t) ;; Enable Semantic (semantic-mode 1) (global-semantic-stickyfunc-mode 1) (global-semantic-idle-summary-mode 1) (global-semantic-highlight-func-mode 1) (global-semantic-decoration-mode 1) (global-semantic-show-unmatched-syntax-mode 0) ;;(global-semantic-highlight-edits-mode 1) >> The bookmark feature takes a different angle on it, being more about >> remembering where semantically you are, vs some exact line. > > That's interesting, but a complex topic. I'm generally dissatisfied with > different navigation tools offered by Emacs, especially the basics like > mark rings. Xref marker ring is better, but also limited in terms of modes of navigation. You could try the one that comes with semantic to see what you think. If you use the above, also add this: (global-semantic-mru-bookmark-mode 1) This is stealthy. It tracks where you edit code. Then use C-xB (capital B) and scroll through places you've been by name of function and select a place to go. Eric |
From: Dmitry G. <dg...@ya...> - 2019-11-25 15:43:09
|
On 25.11.2019 17:40, Dmitry Gutov wrote: > That's interesting, but a complex topic. I'm generally dissatisfied with > different navigation tools offered by Emacs, especially the basics like ...like mark rings. Xref marker ring is better, but also limited in terms of modes of navigation. |
From: Dmitry G. <dg...@ya...> - 2019-11-25 15:40:58
|
On 25.11.2019 17:32, Eric Ludlam wrote: > They already are minor modes. You have to turn them on, and they happen > to depend on CEDET. I meant to make them not depend on CEDET, and move into core Emacs, for instance. CEDET could still configure resulting modes (when installed) via hooks. > The bookmark feature takes a different angle on it, being more about > remembering where semantically you are, vs some exact line. That's interesting, but a complex topic. I'm generally dissatisfied with different navigation tools offered by Emacs, especially the basics like >>> There are a few other tools on top of CEDET that could also provide >>> benefits. When a new tools is built on something like global, >>> idutils, rtags, etc, then it is restricted to that tool. When the >>> core tool starts to die, then those features in Emacs are lost. >> >> I'm always happy for a good abstraction. CEDET goes the "framework" >> route for this, but the "library" way might be able to hit a larger >> audience. > > I'm not sure I understand this statement. > > It is true that a simple wrapper around some external tool ends up with > a small install footprint, and users of it won't need to know CEDET, so > in that case, it would hit a larger audience. s/simple/flexible, so that different frameworks than CEDET, or even complex user configurations, could incorporate them as well. > The bigger problem is > just getting CEDET up and running seems scary to some, and the fact that > they don't realize it isn't that bad to get the basics. Suffice it to say, the potential benefits of using CEDET with Ruby or Elixir seem illusive compared to the work required. |
From: Eric L. <er...@si...> - 2019-11-25 15:33:00
|
On 11/25/19 10:10 AM, Dmitry Gutov wrote: > Thanks, Eric. > > I think of this subject like this: > > On 25.11.2019 16:56, Eric Ludlam wrote: >> There are a lot of small modes and conveniences, such as decorations >> modes, include navigation, bookmarks, and code gen with srecode. > > Sounds like we could extract some of these pieces of functionality into > minor modes with flexible hook which would be used to implement their > behaviors, in CEDET or with other tools directly. That already works > with navigation (xref), decorations and codegen might be applicable as > well. And don't we have bookmarks in Emacs already? Hi Dmitry, They already are minor modes. You have to turn them on, and they happen to depend on CEDET. The bookmark feature takes a different angle on it, being more about remembering where semantically you are, vs some exact line. >> There are a few other tools on top of CEDET that could also provide >> benefits. When a new tools is built on something like global, idutils, >> rtags, etc, then it is restricted to that tool. When the core tool >> starts to die, then those features in Emacs are lost. > > I'm always happy for a good abstraction. CEDET goes the "framework" > route for this, but the "library" way might be able to hit a larger > audience. I'm not sure I understand this statement. It is true that a simple wrapper around some external tool ends up with a small install footprint, and users of it won't need to know CEDET, so in that case, it would hit a larger audience. The bigger problem is just getting CEDET up and running seems scary to some, and the fact that they don't realize it isn't that bad to get the basics. Eric |
From: Dmitry G. <dg...@ya...> - 2019-11-25 15:10:16
|
Thanks, Eric. I think of this subject like this: On 25.11.2019 16:56, Eric Ludlam wrote: > There are a lot of small modes and conveniences, such as decorations > modes, include navigation, bookmarks, and code gen with srecode. Sounds like we could extract some of these pieces of functionality into minor modes with flexible hook which would be used to implement their behaviors, in CEDET or with other tools directly. That already works with navigation (xref), decorations and codegen might be applicable as well. And don't we have bookmarks in Emacs already? > There > are a few other tools on top of CEDET that could also provide benefits. > When a new tools is built on something like global, idutils, rtags, etc, > then it is restricted to that tool. When the core tool starts to die, > then those features in Emacs are lost. I'm always happy for a good abstraction. CEDET goes the "framework" route for this, but the "library" way might be able to hit a larger audience. |
From: Eric L. <er...@si...> - 2019-11-25 14:56:46
|
On 11/25/19 9:22 AM, Dmitry Gutov wrote: > Hi Eric, > > On 23.11.2019 15:32, Eric Ludlam wrote: >> This would be a big win for CEDET, as these backends are becoming >> quite popular, and would let people use CEDET tools as the interface > > I'm curious. Are there particular features that one would want to use in > CEDET on top of LSP? Because I've always thought of CEDET as a way to > get roughly same capabilities as LSP provides (completion, navigation, > documentation display). I think of CEDET as a providing a generic interface to language services, in addition to a base implementation of those language services. Ideally, if someone wants to write a nice high-level tool, like code navigation (eassist), completion (company), or a refactoring tool, it should be possible to write it once against CEDET. Then when some new tool comes along (like lsp) that does something new (support a new language, faster queries, better accuracy) the tool author need do nothing if that tool is integrated as a back-end for CEDET. CEDET will always provide a base all-emacs implementation, but it has scaling issues. When an external tool exists that can handle the scaling issues, it would provide a nice back-end for CEDET to get the same benefit. Those external tools (like lsp) will often have large user bases that extend past Emacs, which means Emacs would also gain the benefits that larger user group can provide. There are several parts of CEDET that are better than most generic tools. This is why the back-ends often just help with code analytics that haven't been brought into Emacs' workspace yet. Once a particular file is identified, the core CEDET functionality takes over, and the additional data is extracted an used. So, to your original question, what would you use from CEDET on top of lsp? There are a lot of small modes and conveniences, such as decorations modes, include navigation, bookmarks, and code gen with srecode. There are a few other tools on top of CEDET that could also provide benefits. When a new tools is built on something like global, idutils, rtags, etc, then it is restricted to that tool. When the core tool starts to die, then those features in Emacs are lost. Of course, this all depends on individuals volunteering to create CEDET backends when new stuff shows up. Does that make sense? Eric |
From: Dmitry G. <dg...@ya...> - 2019-11-25 14:22:58
|
Hi Eric, On 23.11.2019 15:32, Eric Ludlam wrote: > This would be a big win for CEDET, as these backends are becoming quite > popular, and would let people use CEDET tools as the interface I'm curious. Are there particular features that one would want to use in CEDET on top of LSP? Because I've always thought of CEDET as a way to get roughly same capabilities as LSP provides (completion, navigation, documentation display). |
From: Eric L. <er...@si...> - 2019-11-25 13:29:57
|
Thanks Anand, I wasn't trying to suggest using only lsp. Only that lsp servers sometimes have useful features that would serve as a good backend to CEDET. In the same way you can adapt the output of 'grep' for used with semantic-symref, if any particular lsp server happens to have a similar feature, it too could be adapted. In that light, you might also consider using idutils backend for semantic symref. It supports C/C++ which has roughly the same lexical syntax as Java, and basically provides a grep like output. I was looking through the symref code to remind myself what was there. There is already a grep back-end which is used if no other tool is identified. Maybe you used it already, but it needs improvement? Eric On 11/25/19 2:21 AM, Anand Tamariya wrote: > Hi Eric, > IMHO LSP is to VSCode what CEDET is to Emacs. Only CEDET is a tad > better. LSP offloads all language related editing to a language specific > external service. This overlooks the fact that programming languages are > more similar in their structure than there are differences. CEDET seems > to have beautifully captured this idea. For a demo, I've been able to > use the refactoring logic to extract method that I'd written for Java to > refactor Elisp code!! > > The last thing remaining is the symref backend. In absence of any API, > I'm thinking of post-processing results from grep tool for semantic > references. This should give us a quick win. > > Regards, > Anand > > On Sat, Nov 23, 2019 at 7:02 PM Eric Ludlam <er...@si... > <mailto:er...@si...>> wrote: > > Hi Anand, > > Of the tools I had integrted, none were particularly spectacular for > very large code bases, but ok for smaller ones. > > I'm not familiar with any symref level external tools for Java other > than the core java tools themselves. (ie - the jar files.) There is > some support in CEDET already with some jar based semanticdb tables, > but > I never wrote any introspection tools for symrefs. > > A new thing that has appeared recently are LSP servers for different > languages. A good bet would be to look for an LSP server for Java, and > see what it supports. Supporting LSP as a backend for CEDET would be a > nice addition. This one: https://github.com/emacs-lsp/lsp-java looks > like it supports references. > > The trick would then be to write a semanticdb backend, and a symref > backend over one of these lsp servers Emacs interfaces. This would > be a > big win for CEDET, as these backends are becoming quite popular, and > would let people use CEDET tools as the interface. > > > Eric > > On 11/21/19 11:24 PM, Anand Tamariya wrote: > > Hi Eric, > > I've looked at some third party scripts. I realized that they > can't work > > across multiple languages without context awareness - my language of > > interest being Java. > > > > Your efforts with these tools is in the right direction and really > > commendable. They provide great starting points for adding > support for > > new languages. Do you recall any API which would help me do a global > > search as grep / cscope tools do which can then be fed into > semantic-symref? > > > > Regards, > > Anand > > > > On Thu, Nov 21, 2019 at 8:43 AM Eric Ludlam > <er...@si... <mailto:er...@si...> > > <mailto:er...@si... <mailto:er...@si...>>> wrote: > > > > On 11/19/19 11:33 PM, Anand Tamariya wrote: > > > Hi Eric, > > > What are your thoughts about integrating semantic parsing with > > symref > > > for refactoring? Is it possible/desirable? > > > > Hi Anand, > > > > That was one of my goals with those two tools. You may > notice that > > in a > > symref buffer, there are some options in the menu for doing > renames. I > > didn't get very far with this project. > > > > Someone else started a refactoring tool using a mix of semantic, > > symref, > > and srecode. > > > > https://github.com/tuhdo/semantic-refactor > > > > I haven't done any coding in a while so haven't tried this > much myself. > > > > Eric > > > |
From: Anand T. <ata...@gm...> - 2019-11-25 07:21:57
|
Hi Eric, IMHO LSP is to VSCode what CEDET is to Emacs. Only CEDET is a tad better. LSP offloads all language related editing to a language specific external service. This overlooks the fact that programming languages are more similar in their structure than there are differences. CEDET seems to have beautifully captured this idea. For a demo, I've been able to use the refactoring logic to extract method that I'd written for Java to refactor Elisp code!! The last thing remaining is the symref backend. In absence of any API, I'm thinking of post-processing results from grep tool for semantic references. This should give us a quick win. Regards, Anand On Sat, Nov 23, 2019 at 7:02 PM Eric Ludlam <er...@si...> wrote: > Hi Anand, > > Of the tools I had integrted, none were particularly spectacular for > very large code bases, but ok for smaller ones. > > I'm not familiar with any symref level external tools for Java other > than the core java tools themselves. (ie - the jar files.) There is > some support in CEDET already with some jar based semanticdb tables, but > I never wrote any introspection tools for symrefs. > > A new thing that has appeared recently are LSP servers for different > languages. A good bet would be to look for an LSP server for Java, and > see what it supports. Supporting LSP as a backend for CEDET would be a > nice addition. This one: https://github.com/emacs-lsp/lsp-java looks > like it supports references. > > The trick would then be to write a semanticdb backend, and a symref > backend over one of these lsp servers Emacs interfaces. This would be a > big win for CEDET, as these backends are becoming quite popular, and > would let people use CEDET tools as the interface. > > > Eric > > On 11/21/19 11:24 PM, Anand Tamariya wrote: > > Hi Eric, > > I've looked at some third party scripts. I realized that they can't work > > across multiple languages without context awareness - my language of > > interest being Java. > > > > Your efforts with these tools is in the right direction and really > > commendable. They provide great starting points for adding support for > > new languages. Do you recall any API which would help me do a global > > search as grep / cscope tools do which can then be fed into > semantic-symref? > > > > Regards, > > Anand > > > > On Thu, Nov 21, 2019 at 8:43 AM Eric Ludlam <er...@si... > > <mailto:er...@si...>> wrote: > > > > On 11/19/19 11:33 PM, Anand Tamariya wrote: > > > Hi Eric, > > > What are your thoughts about integrating semantic parsing with > > symref > > > for refactoring? Is it possible/desirable? > > > > Hi Anand, > > > > That was one of my goals with those two tools. You may notice that > > in a > > symref buffer, there are some options in the menu for doing > renames. I > > didn't get very far with this project. > > > > Someone else started a refactoring tool using a mix of semantic, > > symref, > > and srecode. > > > > https://github.com/tuhdo/semantic-refactor > > > > I haven't done any coding in a while so haven't tried this much > myself. > > > > Eric > > > |
From: Eric L. <er...@si...> - 2019-11-23 13:32:39
|
Hi Anand, Of the tools I had integrted, none were particularly spectacular for very large code bases, but ok for smaller ones. I'm not familiar with any symref level external tools for Java other than the core java tools themselves. (ie - the jar files.) There is some support in CEDET already with some jar based semanticdb tables, but I never wrote any introspection tools for symrefs. A new thing that has appeared recently are LSP servers for different languages. A good bet would be to look for an LSP server for Java, and see what it supports. Supporting LSP as a backend for CEDET would be a nice addition. This one: https://github.com/emacs-lsp/lsp-java looks like it supports references. The trick would then be to write a semanticdb backend, and a symref backend over one of these lsp servers Emacs interfaces. This would be a big win for CEDET, as these backends are becoming quite popular, and would let people use CEDET tools as the interface. Eric On 11/21/19 11:24 PM, Anand Tamariya wrote: > Hi Eric, > I've looked at some third party scripts. I realized that they can't work > across multiple languages without context awareness - my language of > interest being Java. > > Your efforts with these tools is in the right direction and really > commendable. They provide great starting points for adding support for > new languages. Do you recall any API which would help me do a global > search as grep / cscope tools do which can then be fed into semantic-symref? > > Regards, > Anand > > On Thu, Nov 21, 2019 at 8:43 AM Eric Ludlam <er...@si... > <mailto:er...@si...>> wrote: > > On 11/19/19 11:33 PM, Anand Tamariya wrote: > > Hi Eric, > > What are your thoughts about integrating semantic parsing with > symref > > for refactoring? Is it possible/desirable? > > Hi Anand, > > That was one of my goals with those two tools. You may notice that > in a > symref buffer, there are some options in the menu for doing renames. I > didn't get very far with this project. > > Someone else started a refactoring tool using a mix of semantic, > symref, > and srecode. > > https://github.com/tuhdo/semantic-refactor > > I haven't done any coding in a while so haven't tried this much myself. > > Eric > |
From: Anand T. <ata...@gm...> - 2019-11-22 04:24:27
|
Hi Eric, I've looked at some third party scripts. I realized that they can't work across multiple languages without context awareness - my language of interest being Java. Your efforts with these tools is in the right direction and really commendable. They provide great starting points for adding support for new languages. Do you recall any API which would help me do a global search as grep / cscope tools do which can then be fed into semantic-symref? Regards, Anand On Thu, Nov 21, 2019 at 8:43 AM Eric Ludlam <er...@si...> wrote: > On 11/19/19 11:33 PM, Anand Tamariya wrote: > > Hi Eric, > > What are your thoughts about integrating semantic parsing with symref > > for refactoring? Is it possible/desirable? > > Hi Anand, > > That was one of my goals with those two tools. You may notice that in a > symref buffer, there are some options in the menu for doing renames. I > didn't get very far with this project. > > Someone else started a refactoring tool using a mix of semantic, symref, > and srecode. > > https://github.com/tuhdo/semantic-refactor > > I haven't done any coding in a while so haven't tried this much myself. > > Eric > |
From: Eric L. <er...@si...> - 2019-11-21 03:13:40
|
On 11/19/19 11:33 PM, Anand Tamariya wrote: > Hi Eric, > What are your thoughts about integrating semantic parsing with symref > for refactoring? Is it possible/desirable? Hi Anand, That was one of my goals with those two tools. You may notice that in a symref buffer, there are some options in the menu for doing renames. I didn't get very far with this project. Someone else started a refactoring tool using a mix of semantic, symref, and srecode. https://github.com/tuhdo/semantic-refactor I haven't done any coding in a while so haven't tried this much myself. Eric |
From: Anand T. <ata...@gm...> - 2019-11-20 04:34:14
|
Hi Eric, What are your thoughts about integrating semantic parsing with symref for refactoring? Is it possible/desirable? Regards, Anand |