cedet-semantic — Discussion and help for Semantic, a parser generator for Emacs

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Christian J. <chr...@cv...>]

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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Eric L. <er...@si...>]

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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Christian J. <chr...@cv...>]

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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Stephen L. <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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Christian J. <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 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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Christian J. <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

Re: [cedet-semantic] Is there a wisent analog to Bison %empty non-empty rule?

[Eric L. <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] Is there a wisent analog to Bison %empty non-empty rule?

[Christian J. <chr...@cv...>]

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

Re: [cedet-semantic] GNU Emacs as a lightweight Java IDE - 2 (Refactoring)

[Anand T. <ata...@gm...>]

Auto-completion in overloading scenario.

Re: [cedet-semantic] GNU Emacs as a lightweight Java IDE - 2 (Refactoring)

[Anand T. <ata...@gm...>]

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
> >
>

Re: [cedet-semantic] GNU Emacs as a lightweight Java IDE - 2 (Refactoring)

[Eric L. <er...@si...>]

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
> 

[cedet-semantic] GNU Emacs as a lightweight Java IDE - 2 (Refactoring)

[Anand T. <ata...@gm...>]

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

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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

Re: [cedet-semantic] semantic-symref question

[Dmitry G. <dg...@ya...>]

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.

Re: [cedet-semantic] semantic-symref question

[Dmitry G. <dg...@ya...>]

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.

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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

Re: [cedet-semantic] semantic-symref question

[Dmitry G. <dg...@ya...>]

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.

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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

Re: [cedet-semantic] semantic-symref question

[Dmitry G. <dg...@ya...>]

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).

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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
>      >
> 

Re: [cedet-semantic] semantic-symref question

[Anand T. <ata...@gm...>]

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
> >
>

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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
> 

Re: [cedet-semantic] semantic-symref question

[Anand T. <ata...@gm...>]

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
>

Re: [cedet-semantic] semantic-symref question

[Eric L. <er...@si...>]

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

[cedet-semantic] semantic-symref question

[Anand T. <ata...@gm...>]

Hi Eric,
What are your thoughts about integrating semantic parsing with symref for
refactoring? Is it possible/desirable?

Regards,
Anand