Re: CEDET, future and Emacs
Fermin <[email protected]> Sun, 28 Mar 2021 20:17:36 +0200
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============5658252993772675551== Content-Type: multipart/alternative; boundary="------------8FA72F1EE9C6CE96D62B3AB5" Content-Language: en-US This is a multi-part message in MIME format. --------------8FA72F1EE9C6CE96D62B3AB5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > 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) --------------8FA72F1EE9C6CE96D62B3AB5 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 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">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">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 😅</p> <div class="moz-cite-prefix">On 28/03/2021 20:08, Alex Ott wrote:<br> </div> <blockquote type="cite" cite="mid:CALV1_=KzkEw8UXKAGMDv5QvvnrMnYqJ1NwhpGfeUdS=ezokhUg@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <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" 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" 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]" 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" class="gmail_signature"> <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> </body> </html> --------------8FA72F1EE9C6CE96D62B3AB5-- --===============5658252993772675551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5658252993772675551== 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 --===============5658252993772675551==--