Re: CEDET, future and Emacs
Vladimir Nikishkin <[email protected]> Mon, 29 Mar 2021 10:53:44 +0800
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <CA+A2iZbXkScRMNbpr+BtovS3ritFzkjJ34TWA60ytKA5bQkr6A@mail.gmail.com> |
--===============7229021557933077055== Content-Type: multipart/alternative; boundary="00000000000024e17b05bea3fe4f" --00000000000024e17b05bea3fe4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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]> 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 wi= th > 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 i= s > probably going to be merge into Emacs, so I'm not a big fan of overlappin= g > functionalities, and giving that LSP doesn't expose the AST, I don't thin= k > 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 - for example, I > had working completion for Java when using 3rd party libraries: > https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacsce= det.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 Emac= s > and java is... interesting to say the least =F0=9F=98=85 > > 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 wi= th > 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 - for example, I > had working completion for Java when using 3rd party libraries: > https://alexott.blogspot.com/2012/10/new-version-of-article-about-emacsce= det.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]> 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 prepa= red >> 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]> >> wrote: >> >>> Vladimir Nikishkin <[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 gr= ep >>> > 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] >>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>> >> >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Twitter: alexott_en (English), alexott (Russian) >> >> >> _______________________________________________ >> Cedet-devel mailing [email protected]://lists.s= ourceforge.net/lists/listinfo/cedet-devel >> >> _______________________________________________ >> Cedet-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/cedet-devel >> > > > -- > With best wishes, Alex Ott > http://alexott.net/ > Twitter: alexott_en (English), alexott (Russian) > > _______________________________________________ > Cedet-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/cedet-devel > --=20 Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.) --00000000000024e17b05bea3fe4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"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 unlikel= y to ever get LSP support.</div><div>That's why I was speaking about Sc= heme, since the Scheme ecosystem consists of hundreds of almost unmaintaine= d components.</div><div>And what's more, there _are_ Scheme standards t= hat are expected to be the "lingua franca" but do not have any &q= uot;actual software" implementing them which would expose it's par= ser 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, i= t'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 hav= e one, it's not being universally obeyed. Many of them do have their ow= n "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=3D"gmail_qu= ote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 29 Mar 2021 at 02:18, Fe= rmin <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<= br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> =20 =20 =20 <div> <p> </p><blockquote type=3D"cite">I think that you can also look into reusing LSP if it's available, but expand on the "traditio= nal" 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> <p> </p><blockquote type=3D"cite">Another area is support for build tools= , like, Maven for Java, etc. - these tools bring more context for code completion, etc.=C2=A0 I had a private branch of CEDET that ha= d better support for Maven, Leiningen, and other build tools: <a href= =3D"https://github.com/alexott/cedet/tree/devel" target=3D"_blank">https://= github.com/alexott/cedet/tree/devel</a> - for example, I had working completion for Java when using 3rd party libraries: <a href=3D"https://alexott.blogspot.com/2012/10/ne= w-version-of-article-about-emacscedet.html" target=3D"_blank">https://alexo= tt.blogspot.com/2012/10/new-version-of-article-about-emacscedet.html</a></b= lockquote> 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> <p> </p><blockquote type=3D"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 =F0=9F=98=85<p><= /p> <div>On 28/03/2021 20:08, Alex Ott wrote:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"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.=C2=A0 I had a private branch of CEDET that had better support for Maven, Leiningen, and other build tools: <a hr= ef=3D"https://github.com/alexott/cedet/tree/devel" target=3D"_blank">https:= //github.com/alexott/cedet/tree/devel</a> - for example, I had working completion for Java when using 3rd party libraries: <a href=3D"https://alexott.blogspot.com/2012= /10/new-version-of-article-about-emacscedet.html" target=3D"_blank">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=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 28, 2021 at 8:00 PM Fermin <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"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> =C2=A0between, 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= =3D"https://elpa.gnu.org/packages/async.html" target=3D"_blank">asynchronou= s processing</a>, <br> and I hope in the near future, with <a href=3D"https://www.em= acswiki.org/emacs/GccEmacs" target=3D"_blank">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=3D"cite"> <div dir=3D"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=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 28, 2021 at 6:15 PM Pankaj Jangid <<a href=3D"mailto:pankaj@cod= eisgreat.org" target=3D"_blank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Vladimir = Nikishkin <<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[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 a= re 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=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/c= edet-devel" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.= net/lists/listinfo/cedet-devel</a><br> </blockquote> </div> <br clear=3D"all"> <br> -- <br> <div dir=3D"ltr"> <div dir=3D"ltr"> <div>With best wishes, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alex Ott<br> <a href=3D"http://alexott.net/" target=3D"_blank">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=3D"mailto:[email protected]" target=3D"_blank">Cede= [email protected]</a> <a href=3D"https://lists.sourceforge.net/lists/listinfo/cedet-devel" target= =3D"_blank">https://lists.sourceforge.net/lists/listinfo/cedet-devel</a> </pre> </blockquote> </div> _______________________________________________<br> Cedet-devel mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/cedet-dev= el" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/list= s/listinfo/cedet-devel</a><br> </blockquote> </div> <br clear=3D"all"> <br> -- <br> <div dir=3D"ltr"> <div dir=3D"ltr"> <div>With best wishes, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Alex Ott<br> <a href=3D"http://alexott.net/" target=3D"_blank">http://alexot= t.net/</a><br> Twitter: alexott_en (English), alexott (Russian)<br> </div> </div> </div> </blockquote> </div> _______________________________________________<br> Cedet-devel mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Cede= [email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/cedet-devel" rel=3D= "noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo= /cedet-devel</a><br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div>Yours sincerely, Vladimir = Nikishkin</div><div>(Sent from GMail web interface.)<br></div><br></div></d= iv> --00000000000024e17b05bea3fe4f-- --===============7229021557933077055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7229021557933077055== 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 --===============7229021557933077055==--