Re: CEDET, future and Emacs
Fermin <[email protected]> Mon, 29 Mar 2021 21:59:10 +0200
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7263997387576777917== Content-Type: multipart/alternative; boundary="------------2B9D6A3FAB87E351504D015C" Content-Language: en-GB This is a multi-part message in MIME format. --------------2B9D6A3FAB87E351504D015C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > I'm thinking that it is not really feasible to compete with systems > that deliberately aim at supporting IDE-like behaviour. (I.e. LSP) Even tho I also don't think that CEDET can achieve the same level of functionalities/speed, I think that Emacs need to have an independent way of of IDE-like behaviour and not always relying on 3th party tools, and (personally) I'm not a big fan of LSP, so I would like to have an alternative even if that is a little inferior. > I think that CEDET's (or, rather, semantic's) potential strength > rather lies in supporting the modes that are unlikely to ever get LSP > support. > That's why I was speaking about Scheme, since the Scheme ecosystem > consists of hundreds of almost unmaintained components. > And what's more, there _are_ Scheme standards that are expected to be > the "lingua franca" but do not have any "actual software" implementing > them which would expose it's parser through the lsp, so when I am > programming some obscure (but very useful in niche cases) Scheme > system, I would be able to tell Emacs "well, it's more or less r7rs, > do your best". Agree, Emacs has a lot of facilities to deal with s-expression languages, supporting Scheme wouldn't be that hard and can bring great benefits. But as I said, improving the infrastructure is critical right now, the speed that Emacs Lisp have is not (near) the speed of other interpreted languages, but once the infrastructure become faster, implementing new languages would be the next thing to do. > awk is unlikely to ever get support for lsp, xml/sgml, json, that kind > of guys that don't have a 'single source of authority', or if they > have one, it's not being universally obeyed. Many of them do have > their own "modes" at the moment, but I suspect them to be collections > of regexp tricks rather than semantically consistent parsers. (OTOH, > speed may be a bottleneck here) It is interesting that LSP have support for xml,json and such, but it is totally an overkill, but yes, writing parser for markup languages is easy enough that CEDET can do it quite easily and can provide a great tools giving that the semantic meaning is easily extracted. But again, there is need for documentation for new people, and speed improvements. Thank you for all the suggestions btw. Regards, Fermin On 29/03/2021 04:53, Vladimir Nikishkin wrote: > I'm thinking that it is not really feasible to compete with systems > that deliberately aim at supporting IDE-like behaviour. (I.e. LSP) > > I think that CEDET's (or, rather, semantic's) potential strength > rather lies in supporting the modes that are unlikely to ever get LSP > support. > That's why I was speaking about Scheme, since the Scheme ecosystem > consists of hundreds of almost unmaintained components. > And what's more, there _are_ Scheme standards that are expected to be > the "lingua franca" but do not have any "actual software" implementing > them which would expose it's parser through the lsp, so when I am > programming some obscure (but very useful in niche cases) Scheme > system, I would be able to tell Emacs "well, it's more or less r7rs, > do your best". > > awk is unlikely to ever get support for lsp, xml/sgml, json, that kind > of guys that don't have a 'single source of authority', or if they > have one, it's not being universally obeyed. Many of them do have > their own "modes" at the moment, but I suspect them to be collections > of regexp tricks rather than semantically consistent parsers. (OTOH, > speed may be a bottleneck here) > > > On Mon, 29 Mar 2021 at 02:18, Fermin <[email protected] > <mailto:[email protected]>> wrote: > >> I think that you can also look into reusing LSP if it's >> available, but expand on the "traditional" IDE features - >> refactoring (maybe starting with simple rename, method extract, >> etc.), more templates for code, etc. - for these things we may >> not need to have full-blown parsers. > The thing is that, there is already a GNU Emacs LSP client (eglot) > that is probably going to be merge into Emacs, so I'm not a big > fan of overlapping functionalities, and giving that LSP doesn't > expose the AST, I don't think it can be THAT usefull. > >> Another area is support for build tools, like, Maven for Java, >> etc. - these tools bring more context for code completion, etc. >> I had a private branch of CEDET that had better support for >> Maven, Leiningen, and other build tools: >> https://github.com/alexott/cedet/tree/devel >> <https://github.com/alexott/cedet/tree/devel> - for example, I >> had working completion for Java when using 3rd party libraries: >> https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html >> <https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html> > That's great! I will look further if we can merge this changes, I > also think that support more static/easy to parse languages can > also be a nice and easy addition. > >> P.S. Unfortunately, right now I don't have much free time, so I >> surrended & using Idea for Java/Scala code > I can totally understand this, no problem, I saw that the history > of Emacs and java is... interesting to say the least 😅 > On 28/03/2021 20:08, Alex Ott wrote: >> I think that you can also look into reusing LSP if it's >> available, but expand on the "traditional" IDE features - >> refactoring (maybe starting with simple rename, method extract, >> etc.), more templates for code, etc. - for these things we may >> not need to have full-blown parsers. >> >> Another area is support for build tools, like, Maven for Java, >> etc. - these tools bring more context for code completion, etc. >> I had a private branch of CEDET that had better support for >> Maven, Leiningen, and other build tools: >> https://github.com/alexott/cedet/tree/devel >> <https://github.com/alexott/cedet/tree/devel> - for example, I >> had working completion for Java when using 3rd party libraries: >> https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html >> <https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html> >> >> P.S. Unfortunately, right now I don't have much free time, so I >> surrended & using Idea for Java/Scala code >> >> On Sun, Mar 28, 2021 at 8:00 PM Fermin <[email protected] >> <mailto:[email protected]>> wrote: >> >> You are right, keeping up with new languages is quite hard, I >> think this is why CEDET need more people involve, we can >> never match >> the level of adoption of LSP, but we can provide a decent >> programming experience for a variety of languages. >> >> Focusing on a balance between popular (to attract users) and >> stable (languages that don't require a lot of changes over >> time) can be >> an interesting strategy, I'm not saying to focus all the >> energy into writing a javascript production parser or a Ada >> parser, something in >> between, that can be stable enough and popular enough. >> >> For now, I think improving the actual parsing infrastructure >> is more critical that supporting new languages, giving the >> synchronous nature >> of CEDET, right now is not well suited for large projects, >> Emacs now support (partially, and in a hackish way) >> asynchronous processing >> <https://elpa.gnu.org/packages/async.html>, >> and I hope in the near future, with native compilation >> <https://www.emacswiki.org/emacs/GccEmacs>, the elisp >> performance can improve drastically ,which can really play >> really well if CEDET is prepared to take advantage of this >> changes. >> >> >> >> On 28/03/2021 19:13, Alex Ott wrote: >>> Imho, LSP is still required - it's quite hard to build >>> grammars for multiple languages, and maintain them as >>> languages evolve... >>> >>> On Sun, Mar 28, 2021 at 6:15 PM Pankaj Jangid >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Vladimir Nikishkin <[email protected] >>> <mailto:[email protected]>> writes: >>> >>> > Things are actually moving (albeit not super fast), >>> just not inside the SF >>> > repo. Since cedet was merged into the main emacs tree, >>> you need to grep >>> > emacs' git log, not sf repos. >>> >>> Yup. Just saw one more commit today. I build >>> emacs-master daily for my >>> personal use. >>> >>> By "not moving" I meant that the expectations are high. >>> Things like LSP >>> would not be required if CEDET is seriously taken care of. >>> >>> >>> >>> >>> _______________________________________________ >>> Cedet-devel mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>> <https://lists.sourceforge.net/lists/listinfo/cedet-devel> >>> >>> >>> >>> -- >>> With best wishes, Alex Ott >>> http://alexott.net/ <http://alexott.net/> >>> Twitter: alexott_en (English), alexott (Russian) >>> >>> >>> _______________________________________________ >>> Cedet-devel mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/cedet-devel <https://lists.sourceforge.net/lists/listinfo/cedet-devel> >> _______________________________________________ >> Cedet-devel mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/cedet-devel >> <https://lists.sourceforge.net/lists/listinfo/cedet-devel> >> >> >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ <http://alexott.net/> >> Twitter: alexott_en (English), alexott (Russian) > _______________________________________________ > Cedet-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/cedet-devel > <https://lists.sourceforge.net/lists/listinfo/cedet-devel> > > > > -- > Yours sincerely, Vladimir Nikishkin > (Sent from GMail web interface.) > --------------2B9D6A3FAB87E351504D015C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p> <blockquote type="cite">I'm thinking that it is not really feasible to compete with systems that deliberately aim at supporting IDE-like behaviour. (I.e. LSP)</blockquote> Even tho I also don't think that CEDET can achieve the same level of functionalities/speed, I think that Emacs need to have an independent way of<br> of IDE-like behaviour and not always relying on 3th party tools, and (personally) I'm not a big fan of LSP, so I would like to have an alternative<br> even if that is a little inferior.</p> <p> <blockquote type="cite"> <div>I think that CEDET's (or, rather, semantic's) potential strength rather lies in supporting the modes that are unlikely to ever get LSP support.</div> <div>That's why I was speaking about Scheme, since the Scheme ecosystem consists of hundreds of almost unmaintained components.</div> <div>And what's more, there _are_ Scheme standards that are expected to be the "lingua franca" but do not have any "actual software" implementing them which would expose it's parser through the lsp, so when I am programming some obscure (but very useful in niche cases) Scheme system, I would be able to tell Emacs "well, it's more or less r7rs, do your best".</div> </blockquote> Agree, Emacs has a lot of facilities to deal with s-expression languages, supporting Scheme wouldn't be that hard and can bring great benefits. But as I said, improving<br> the infrastructure is critical right now, the speed that Emacs Lisp have is not (near) the speed of other interpreted languages, but once the infrastructure become <br> faster, implementing new languages would be the next thing to do.</p> <p> <blockquote type="cite">awk is unlikely to ever get support for lsp, xml/sgml, json, that kind of guys that don't have a 'single source of authority', or if they have one, it's not being universally obeyed. Many of them do have their own "modes" at the moment, but I suspect them to be collections of regexp tricks rather than semantically consistent parsers. (OTOH, speed may be a bottleneck here)</blockquote> It is interesting that LSP have support for xml,json and such, but it is totally an overkill, but yes, writing parser for markup languages is easy enough that CEDET can do it<br> quite easily and can provide a great tools giving that the semantic meaning is easily extracted. But again, there is need for documentation for new people, and speed improvements.</p> <p>Thank you for all the suggestions btw.</p> <p>Regards,</p> <p>Fermin<br> </p> <div class="moz-cite-prefix">On 29/03/2021 04:53, Vladimir Nikishkin wrote:<br> </div> <blockquote type="cite" cite="mid:CA+A2iZbXkScRMNbpr+BtovS3ritFzkjJ34TWA60ytKA5bQkr6A@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr">I'm thinking that it is not really feasible to compete with systems that deliberately aim at supporting IDE-like behaviour. (I.e. LSP) <div><br> </div> <div>I think that CEDET's (or, rather, semantic's) potential strength rather lies in supporting the modes that are unlikely to ever get LSP support.</div> <div>That's why I was speaking about Scheme, since the Scheme ecosystem consists of hundreds of almost unmaintained components.</div> <div>And what's more, there _are_ Scheme standards that are expected to be the "lingua franca" but do not have any "actual software" implementing them which would expose it's parser through the lsp, so when I am programming some obscure (but very useful in niche cases) Scheme system, I would be able to tell Emacs "well, it's more or less r7rs, do your best".</div> <div><br> </div> <div>awk is unlikely to ever get support for lsp, xml/sgml, json, that kind of guys that don't have a 'single source of authority', or if they have one, it's not being universally obeyed. Many of them do have their own "modes" at the moment, but I suspect them to be collections of regexp tricks rather than semantically consistent parsers. (OTOH, speed may be a bottleneck here)</div> <div><br> </div> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Mon, 29 Mar 2021 at 02:18, Fermin <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <p> </p> <blockquote type="cite">I think that you can also look into reusing LSP if it's available, but expand on the "traditional" IDE features - refactoring (maybe starting with simple rename, method extract, etc.), more templates for code, etc. - for these things we may not need to have full-blown parsers.</blockquote> The thing is that, there is already a GNU Emacs LSP client (eglot) that is probably going to be merge into Emacs, so I'm not a big fan of overlapping functionalities, and giving that LSP doesn't expose the AST, I don't think it can be THAT usefull. <p> </p> <blockquote type="cite">Another area is support for build tools, like, Maven for Java, etc. - these tools bring more context for code completion, etc. I had a private branch of CEDET that had better support for Maven, Leiningen, and other build tools: <a href="https://github.com/alexott/cedet/tree/devel" target="_blank" moz-do-not-send="true">https://github.com/alexott/cedet/tree/devel</a> - for example, I had working completion for Java when using 3rd party libraries: <a href="https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html" target="_blank" moz-do-not-send="true">https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html</a></blockquote> That's great! I will look further if we can merge this changes, I also think that support more static/easy to parse languages can also be a nice and easy addition. <p> </p> <blockquote type="cite">P.S. Unfortunately, right now I don't have much free time, so I surrended & using Idea for Java/Scala code</blockquote> I can totally understand this, no problem, I saw that the history of Emacs and java is... interesting to say the least 😅 <div>On 28/03/2021 20:08, Alex Ott wrote:<br> </div> <blockquote type="cite"> <div dir="ltr"> <div>I think that you can also look into reusing LSP if it's available, but expand on the "traditional" IDE features - refactoring (maybe starting with simple rename, method extract, etc.), more templates for code, etc. - for these things we may not need to have full-blown parsers.</div> <div><br> </div> <div>Another area is support for build tools, like, Maven for Java, etc. - these tools bring more context for code completion, etc. I had a private branch of CEDET that had better support for Maven, Leiningen, and other build tools: <a href="https://github.com/alexott/cedet/tree/devel" target="_blank" moz-do-not-send="true">https://github.com/alexott/cedet/tree/devel</a> - for example, I had working completion for Java when using 3rd party libraries: <a href="https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html" target="_blank" moz-do-not-send="true">https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html</a></div> <div><br> </div> <div>P.S. Unfortunately, right now I don't have much free time, so I surrended & using Idea for Java/Scala code<br> </div> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Sun, Mar 28, 2021 at 8:00 PM Fermin <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <p>You are right, keeping up with new languages is quite hard, I think this is why CEDET need more people involve, we can never match<br> the level of adoption of LSP, but we can provide a decent programming experience for a variety of languages.</p> <p>Focusing on a balance between popular (to attract users) and stable (languages that don't require a lot of changes over time) can be<br> an interesting strategy, I'm not saying to focus all the energy into writing a javascript production parser or a Ada parser, something in<br> between, that can be stable enough and popular enough.</p> <p>For now, I think improving the actual parsing infrastructure is more critical that supporting new languages, giving the synchronous nature<br> of CEDET, right now is not well suited for large projects, Emacs now support (partially, and in a hackish way) <a href="https://elpa.gnu.org/packages/async.html" target="_blank" moz-do-not-send="true">asynchronous processing</a>, <br> and I hope in the near future, with <a href="https://www.emacswiki.org/emacs/GccEmacs" target="_blank" moz-do-not-send="true">native compilation</a>, the elisp performance can improve drastically ,which can really play really well if CEDET is prepared to take advantage of this changes.</p> <p><br> </p> <br> <div>On 28/03/2021 19:13, Alex Ott wrote:<br> </div> <blockquote type="cite"> <div dir="ltr">Imho, LSP is still required - it's quite hard to build grammars for multiple languages, and maintain them as languages evolve...<br> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Sun, Mar 28, 2021 at 6:15 PM Pankaj Jangid <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Vladimir Nikishkin <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> writes:<br> <br> > Things are actually moving (albeit not super fast), just not inside the SF<br> > repo. Since cedet was merged into the main emacs tree, you need to grep<br> > emacs' git log, not sf repos.<br> <br> Yup. Just saw one more commit today. I build emacs-master daily for my<br> personal use.<br> <br> By "not moving" I meant that the expectations are high. Things like LSP<br> would not be required if CEDET is seriously taken care of.<br> <br> <br> <br> <br> _______________________________________________<br> Cedet-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/cedet-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.sourceforge.net/lists/listinfo/cedet-devel</a><br> </blockquote> </div> <br clear="all"> <br> -- <br> <div dir="ltr"> <div dir="ltr"> <div>With best wishes, Alex Ott<br> <a href="http://alexott.net/" target="_blank" moz-do-not-send="true">http://alexott.net/</a><br> Twitter: alexott_en (English), alexott (Russian)<br> </div> </div> </div> <br> <fieldset></fieldset> <br> <fieldset></fieldset> <pre>_______________________________________________ Cedet-devel mailing list <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a> <a href="https://lists.sourceforge.net/lists/listinfo/cedet-devel" target="_blank" moz-do-not-send="true">https://lists.sourceforge.net/lists/listinfo/cedet-devel</a> </pre> </blockquote> </div> _______________________________________________<br> Cedet-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/cedet-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.sourceforge.net/lists/listinfo/cedet-devel</a><br> </blockquote> </div> <br clear="all"> <br> -- <br> <div dir="ltr"> <div dir="ltr"> <div>With best wishes, Alex Ott<br> <a href="http://alexott.net/" target="_blank" moz-do-not-send="true">http://alexott.net/</a><br> Twitter: alexott_en (English), alexott (Russian)<br> </div> </div> </div> </blockquote> </div> _______________________________________________<br> Cedet-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/cedet-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.sourceforge.net/lists/listinfo/cedet-devel</a><br> </blockquote> </div> <br clear="all"> <div><br> </div> -- <br> <div dir="ltr" class="gmail_signature"> <div dir="ltr"> <div>Yours sincerely, Vladimir Nikishkin</div> <div>(Sent from GMail web interface.)<br> </div> <br> </div> </div> </blockquote> </body> </html> --------------2B9D6A3FAB87E351504D015C-- --===============7263997387576777917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7263997387576777917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Cedet-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cedet-devel --===============7263997387576777917==--