cedet-devel — Developers of CEDET

Re: [CEDET-devel] CEDET, future and Emacs

[Eric L. <eri...@gm...>]

First, thank you Fermin for stepping forward to maintain CEDET!  It will 
be great to have someone moving it forward again.

On 3/28/21 2:17 PM, Fermin 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.

One of the powerful things CEDET does is it provides an abstract way to 
think about the contents of a buffer, which is the tags that it produces 
through the parsers, saves between sessions, and uses to decorate the 
buffer, provide navigation ,completion, etc.  A whole host of tools 
relies on those tags, and the simplicity & speed of getting them, and 
navigating with them.

I think Alex's suggestion is less about "should someone write a bunch of 
code to integrate LSP into CEDET", and more about "Can we get LSP 
generated tags behind the CEDET tag model", thus magically enabling a 
host of new languages to work with the tag system.

Another way to think of it is, if eglot is how lsp will be pulled into 
Emacs, then can eglot produce semantic tags?  Or can eglot provide the 
underpinnings of other parts of CEDET that are over loadable, such as 
database backends, etc.  I think this is important because the current 
system does not scale.  It does not take too big a project to make 
Emacs' memory footprint just too big with all the saved meta-data form 
CEDET.  Optionally delegating database functionality elsewhere would be 
a boon.

My opinion is that the more sources of data are available, such as lisp 
based parsers and optional 3rd party tools, the more likely it is that 
someone's language will be supported, and that a tag based tool can be 
used.  If more languages supported CEDET tags via eglot or other 
cheap-to-develop 3rd party tools, then more tool writers may choose to 
use the CEDET tag system instead of something that is bound to a 
specific tool like eglot.

I also think it is important to provide more semantic based parsers for 
more languages, obscure or otherwise.  They provide a distinct editing 
advantage over external parsers, and are often needed to fully resolve 
context for advanced tools like srecode that 3rd party tools can't provide.

Hope this helps explain some of the philosophy of where I was trying to 
get to before I ran out of time to work on CEDET.  It's a big project, 
and it will take many hands.

Eric

Re: [CEDET-devel] bug#16008: semantic/grammar-wy.el cannot be bootstrapped

[Stefan M. <mo...@ir...>]

David Engster [2013-11-30 11:00:47] wrote:
> Glenn Morris writes:
>> semantic/grammar-wy.el is a generated file and therefore ideally should
>> not be kept in the Emacs VCS.
> That's true for all parsers. However, grammar-wy.el is special, as
> you've noticed.
>> It is generated by semantic/grammar.el.
>> semantic/grammar.el requires semantic/grammar-wy.el, therefore
>> it is not possible to bootstrap without semantic/grammar-wy.el already
>> present.
> Yes, it has a circular dependency, because the parser grammar-wy.el
> parses grammar files, including itself.  In upstream, we have
> a fallback parser for this, which is used when grammar-wy.el is not
> present yet.

Of course, another option would be to add a sexp-based syntax for wisent
grammars, so that grammar.wy can be rewritten with that sexp-based syntax
and won't need a wisent parser to parse it any more.

In the mean time I suggest the patch below which I recently sent to
emacs-devel.

Eli Zaretskii [2021-04-03 10:58:12] wrote:
> Assuming you tested that during bootstrap (which you say you never
> do), and assuming there's no better way of breaking the circular
> dependency, I'm okay with the change.  But please also change
> admin/make-tarball.txt to say that grm-wy-boot.el should be updated
> the same way as ldefs-boot.el is.  We should also make sure
> grm-wy-boot.el is updated in Git whenever grammar.wy changes.

Glenn, could you arrange to "auto""-update `grm-wy-boot.el` like you do
for `ldefs-boot.el`?


        Stefan


diff --git a/.gitignore b/.gitignore
index b653ef215b..9fe8ecb594 100644
--- a/.gitignore
+++ b/.gitignore
@@ -88,6 +88,7 @@ lisp/cedet/semantic/wisent/javat-wy.el
 lisp/cedet/semantic/wisent/js-wy.el
 lisp/cedet/semantic/wisent/python-wy.el
 lisp/cedet/srecode/srt-wy.el
+lisp/cedet/semantic/grammar-wy.el
 lisp/eshell/esh-groups.el
 lisp/finder-inf.el
 lisp/leim/ja-dic/
diff --git a/admin/grammars/Makefile.in b/admin/grammars/Makefile.in
index aa09d9edf9..800e31762d 100644
--- a/admin/grammars/Makefile.in
+++ b/admin/grammars/Makefile.in
@@ -48,14 +48,11 @@ BOVINE =
 	${bovinedir}/make-by.el \
 	${bovinedir}/scm-by.el
 
-## FIXME Should include this one too:
-##	${cedetdir}/semantic/grammar-wy.el
-## but semantic/grammar.el (which is what we use to generate grammar-wy.el)
-## requires it!
-WISENT = \
-	${wisentdir}/javat-wy.el \
-	${wisentdir}/js-wy.el \
-	${wisentdir}/python-wy.el \
+WISENT = 				   \
+	${cedetdir}/semantic/grammar-wy.el \
+	${wisentdir}/javat-wy.el 	   \
+	${wisentdir}/js-wy.el 		   \
+	${wisentdir}/python-wy.el 	   \
 	${cedetdir}/srecode/srt-wy.el
 
 ALL = ${BOVINE} ${WISENT}
diff --git a/lisp/cedet/semantic/grammar.el b/lisp/cedet/semantic/grammar.el
index dba289fdd7..782327e617 100644
--- a/lisp/cedet/semantic/grammar.el
+++ b/lisp/cedet/semantic/grammar.el
@@ -31,7 +31,12 @@
 (require 'semantic/format)
 ;; FIXME this is a generated file, but we need to load this file to
 ;; generate it!
-(require 'semantic/grammar-wy)
+;; We need `semantic/grammar-wy.el' but we're also needed to generate
+;; that file from `grammar.wy', so to break the dependency, we keep
+;; a bootstrap copy of `grammar-wy.el' in `grm-wy-boot.el'.  See bug#16008.
+(eval-and-compile
+  (unless (require 'semantic/grammar-wy nil t)
+    (load "semantic/grm-wy-boot")))
 (require 'semantic/idle)
 (require 'help-fns)
 (require 'semantic/analyze)
diff --git a/lisp/cedet/semantic/grammar-wy.el b/lisp/cedet/semantic/grm-wy-boot.el
similarity index 100%
rename from lisp/cedet/semantic/grammar-wy.el
rename to lisp/cedet/semantic/grm-wy-boot.el

Re: [CEDET-devel] CME package

[Consciencia <con...@pr...>]

License added.

Of course you can :) It would be awesome to have fixes from CME in CEDET.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 1, 2021 10:24 PM, Fermin <fm...@po...> wrote:

> Totally understandable, I also notice that your repository doesn't have any license, if you provide a GPLv3 compatible license (and you allow me) I can adapt the code
> to fit into the master branch of Emacs and the CEDET infrastructure.
>
> Regards,
>
> Fermin
>
> On 01/04/2021 22:12, Consciencia via Cedet-devel wrote:
>
>> Certainly. Issue is that fixes and enhancements tend to intertwine together in monkey patched CEDET functions. I myself got little lost in it because I wrote it over the course of several years so I forgotten a lot of things. Overall, code is dirty and hacky, cleanliness was of no importance to me because I wanted to create desired functionality as fast as possible which means integrating parts of CME into CEDET would be time consuming. Sadly, I am not in a good terms with time.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Thursday, April 1, 2021 8:52 PM, Fermin [<fm...@po...>](mailto:fm...@po...) wrote:
>>
>>> Oh wow seems awesome!
>>>
>>> It is any possibility to include these changes into CEDET? It could be a great addition to fix these behavior in core Emacs
>>>
>>> On 01/04/2021 20:07, Consciencia via Cedet-devel wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> Let me introduce CME. Package build around CEDET which is providing:
>>>> 1) Simple user interface.
>>>> 2) Automatic CEDET configuration.
>>>> 3) Fixes for incorrect CEDET behavior.
>>>> 4) And some new features.
>>>>
>>>> CEDET adoption is mainly blocked by two factors, hard configuration and huge confusing API. CME is trying to solve both issues. Another issue is the need to install 3rd party software (GNU Global) otherwise CEDET is not able to find function implementations, only prototypes. This is solved by CME too.
>>>>
>>>> Take a look and tell me what you think.
>>>>
>>>> https://github.com/consciencia/CME
>>>>
>>>> C.
>>>>
>>>> _______________________________________________
>>>> Cedet-devel mailing list
>>>> Ced...@li...
>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>
>> _______________________________________________
>> Cedet-devel mailing list
>> Ced...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] CME package

[Fermin <fm...@po...>]

Totally understandable, I also notice that your repository doesn't have 
any license, if you provide a GPLv3 compatible license (and you allow 
me) I can adapt the code
to fit into the master branch of Emacs and the CEDET infrastructure.

Regards,

Fermin

On 01/04/2021 22:12, Consciencia via Cedet-devel wrote:
> Certainly. Issue is that fixes and enhancements tend to intertwine 
> together in monkey patched CEDET functions. I myself got little lost 
> in it because I wrote it over the course of several years so I 
> forgotten a lot of things. Overall, code is dirty and hacky, 
> cleanliness was of no importance to me because I wanted to create 
> desired functionality as fast as possible which means integrating 
> parts of CME into CEDET would be time consuming. Sadly, I am not in a 
> good terms with time.
>
>
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, April 1, 2021 8:52 PM, Fermin <fm...@po...> wrote:
>
>> Oh wow seems awesome!
>>
>> It is any possibility to include these changes into CEDET? It could 
>> be a great addition to fix these behavior in core Emacs
>>
>> On 01/04/2021 20:07, Consciencia via Cedet-devel wrote:
>>> Hello everyone,
>>>
>>> Let me introduce CME. Package build around CEDET which is providing:
>>> 1) Simple user interface.
>>> 2) Automatic CEDET configuration.
>>> 3) Fixes for incorrect CEDET behavior.
>>> 4) And some new features.
>>>
>>>
>>>
>>> CEDET adoption is mainly blocked by two factors, hard configuration 
>>> and huge confusing API. CME is trying to solve both issues. Another 
>>> issue is the need to install 3rd party software (GNU Global) 
>>> otherwise CEDET is not able to find function implementations, only 
>>> prototypes. This is solved by CME too.
>>>
>>> Take a look and tell me what you think.
>>>
>>> https://github.com/consciencia/CME <https://github.com/consciencia/CME>
>>>
>>> C.
>>>
>>>
>>> _______________________________________________
>>> Cedet-devel mailing list
>>> Ced...@li...  <mailto:Ced...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel  <https://lists.sourceforge.net/lists/listinfo/cedet-devel>
>>>
>
>
>
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] CME package

[Consciencia <con...@pr...>]

Certainly. Issue is that fixes and enhancements tend to intertwine together in monkey patched CEDET functions. I myself got little lost in it because I wrote it over the course of several years so I forgotten a lot of things. Overall, code is dirty and hacky, cleanliness was of no importance to me because I wanted to create desired functionality as fast as possible which means integrating parts of CME into CEDET would be time consuming. Sadly, I am not in a good terms with time.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 1, 2021 8:52 PM, Fermin <fm...@po...> wrote:

> Oh wow seems awesome!
>
> It is any possibility to include these changes into CEDET? It could be a great addition to fix these behavior in core Emacs
>
> On 01/04/2021 20:07, Consciencia via Cedet-devel wrote:
>
>> Hello everyone,
>>
>> Let me introduce CME. Package build around CEDET which is providing:
>> 1) Simple user interface.
>> 2) Automatic CEDET configuration.
>> 3) Fixes for incorrect CEDET behavior.
>> 4) And some new features.
>>
>> CEDET adoption is mainly blocked by two factors, hard configuration and huge confusing API. CME is trying to solve both issues. Another issue is the need to install 3rd party software (GNU Global) otherwise CEDET is not able to find function implementations, only prototypes. This is solved by CME too.
>>
>> Take a look and tell me what you think.
>>
>> https://github.com/consciencia/CME
>>
>> C.
>>
>> _______________________________________________
>> Cedet-devel mailing list
>> Ced...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] CME package

[Fermin <fm...@po...>]

Oh wow seems awesome!

It is any possibility to include these changes into CEDET? It could be a 
great addition to fix these behavior in core Emacs

On 01/04/2021 20:07, Consciencia via Cedet-devel wrote:
> Hello everyone,
>
> Let me introduce CME. Package build around CEDET which is providing:
> 1) Simple user interface.
> 2) Automatic CEDET configuration.
> 3) Fixes for incorrect CEDET behavior.
> 4) And some new features.
>
>
>
> CEDET adoption is mainly blocked by two factors, hard configuration 
> and huge confusing API. CME is trying to solve both issues. Another 
> issue is the need to install 3rd party software (GNU Global) otherwise 
> CEDET is not able to find function implementations, only prototypes. 
> This is solved by CME too.
>
> Take a look and tell me what you think.
>
> https://github.com/consciencia/CME <https://github.com/consciencia/CME>
>
> C.
>
>
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel

[CEDET-devel] CME package

[Consciencia <con...@pr...>]

Hello everyone,

Let me introduce CME. Package build around CEDET which is providing:
1) Simple user interface.
2) Automatic CEDET configuration.
3) Fixes for incorrect CEDET behavior.
4) And some new features.

CEDET adoption is mainly blocked by two factors, hard configuration and huge confusing API. CME is trying to solve both issues. Another issue is the need to install 3rd party software (GNU Global) otherwise CEDET is not able to find function implementations, only prototypes. This is solved by CME too.

Take a look and tell me what you think.

https://github.com/consciencia/CME

C.

Re: [CEDET-devel] CEDET, future and Emacs

[Pankaj J. <pa...@co...>]

Fermin <fm...@po...> writes:

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

I have seen eglot. It is really good stuff. Neat and lean code and exist
as a thin layer between Emacs infrastructure and language server. It
tries to reuse as much as possible, the existing Emacs
infrastructure. Like, eldoc, completion, flymake.

Other thing I want is improvement of ‘project-*’ infrastructure. This is
currently happening. Currently only git and EDE backends are supported
but this may be enhanced to include things like Maven, Gradle, Cargo
etc.

CEDET can then use the ‘project’ infrastructure to limit the scope. Even
now it should rely on ‘project’ only. Or this could be an option.

--
Pankaj Jangid

Re: [CEDET-devel] CEDET, future and Emacs

[Fermin <fm...@po...>]

> 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 <fm...@po... 
> <mailto:fm...@po...>> 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 <fm...@po...
>>     <mailto:fm...@po...>> 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
>>>         <pa...@co... <mailto:pa...@co...>> wrote:
>>>
>>>             Vladimir Nikishkin <loc...@gm...
>>>             <mailto:loc...@gm...>> 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
>>>             Ced...@li...
>>>             <mailto:Ced...@li...>
>>>             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
>>>         Ced...@li...  <mailto:Ced...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/cedet-devel  <https://lists.sourceforge.net/lists/listinfo/cedet-devel>
>>         _______________________________________________
>>         Cedet-devel mailing list
>>         Ced...@li...
>>         <mailto:Ced...@li...>
>>         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
>     Ced...@li...
>     <mailto:Ced...@li...>
>     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.)
>

Re: [CEDET-devel] CEDET, future and Emacs

[Vladimir N. <loc...@gm...>]

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 <fm...@po...> 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 - 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
>
> 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 - 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
>
> 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 <fm...@po...> 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 <pa...@co...>
>> wrote:
>>
>>> Vladimir Nikishkin <loc...@gm...> 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
>>> Ced...@li...
>>> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>
>> _______________________________________________
>> Cedet-devel mailing list
>> Ced...@li...
>> 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
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>


-- 
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)

Re: [CEDET-devel] CEDET, future and Emacs

[Fermin <fm...@po...>]

> 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 <fm...@po... 
> <mailto:fm...@po...>> 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
>>     <pa...@co... <mailto:pa...@co...>> wrote:
>>
>>         Vladimir Nikishkin <loc...@gm...
>>         <mailto:loc...@gm...>> 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
>>         Ced...@li...
>>         <mailto:Ced...@li...>
>>         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
>>     Ced...@li...  <mailto:Ced...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/cedet-devel  <https://lists.sourceforge.net/lists/listinfo/cedet-devel>
>     _______________________________________________
>     Cedet-devel mailing list
>     Ced...@li...
>     <mailto:Ced...@li...>
>     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)

Re: [CEDET-devel] CEDET, future and Emacs

[Alex O. <al...@gm...>]

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

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 <fm...@po...> 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 <pa...@co...>
> wrote:
>
>> Vladimir Nikishkin <loc...@gm...> 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
>> Ced...@li...
>> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>


-- 
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Re: [CEDET-devel] CEDET, future and Emacs

[Fermin <fm...@po...>]

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 <pa...@co... 
> <mailto:pa...@co...>> wrote:
>
>     Vladimir Nikishkin <loc...@gm...
>     <mailto:loc...@gm...>> 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
>     Ced...@li...
>     <mailto:Ced...@li...>
>     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
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] CEDET, future and Emacs

[Alex O. <al...@gm...>]

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 <pa...@co...>
wrote:

> Vladimir Nikishkin <loc...@gm...> 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
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>


-- 
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Re: [CEDET-devel] CEDET, future and Emacs

[Pankaj J. <pa...@co...>]

Vladimir Nikishkin <loc...@gm...> 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.

Re: [CEDET-devel] CEDET, future and Emacs

[Vladimir N. <loc...@gm...>]

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.

--
Yours sincerely, Vladimir Nikishkin
(Sent with Google mail mobile.)

Pankaj Jangid <pa...@co...> 于 2021年3月28日周日 21:45写道：

> Fermin <fm...@po...> writes:
>
> > My name is Fermin, I'm an Emacs hacker (among other things) and I've
> > been messing around with CEDET these past year or so, and I really
> > like it overall,
> > I can understand his faults and how/why the Emacs community is not
> > taking it into account too much these days, but I also think that this
> > can change.
>
> Thanks for your willingness and enthusiasm to take this project
> forward. I had always wondered what happened to this project. Nothing is
> moving.
>
> --
> Regards,
> Pankaj Jangid
>
>
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

Re: [CEDET-devel] CEDET, future and Emacs

[Pankaj J. <pa...@co...>]

Fermin <fm...@po...> writes:

> My name is Fermin, I'm an Emacs hacker (among other things) and I've
> been messing around with CEDET these past year or so, and I really
> like it overall,
> I can understand his faults and how/why the Emacs community is not
> taking it into account too much these days, but I also think that this
> can change.

Thanks for your willingness and enthusiasm to take this project
forward. I had always wondered what happened to this project. Nothing is
moving.

-- 
Regards,
Pankaj Jangid

[CEDET-devel] Fwd: CEDET, future and Emacs

[Fermin <fm...@po...>]

No problem, forwarded to the mailing list.

Giving that CEDET is now part of GNU Emacs, I think that is more 
appropriate to ask for a mailing list (like others projects have), 
rather than using an external one, there is no rush to this, of course.

Regards,

Fermin

-------- Forwarded Message --------
Subject: 	Re: [CEDET-devel] CEDET, future and Emacs
Date: 	Sun, 28 Mar 2021 16:33:16 +0800
From: 	Vladimir Nikishkin <loc...@gm...>
To: 	Fermin <fm...@po...>



Yes, sure. I misclicked "reply to the author" instead of "reply to all". 
My bad.

--
Yours sincerely, Vladimir Nikishkin
(Sent with Google mail mobile.)

Fermin <fm...@po... <mailto:fm...@po...>> 于 2021年3月28日周日 
16:24写道：

    Hello Vladimir,

>     It's always great when software gets the attention it deserves. In
>     fact, cedet is a quite good tool, which unfortunately feels
>     unfinished. I'm feeling happy that someone is ready to dedicate
>     effort to it.
    Thank you!

>     1. Cedet feels a bit orthogonal to the Emacs standard way of doing
>     things. (Same has been said about helm!) For example, rebinding
>     right-click (mouse-3), seems a bit too much.
    You are right, even tho I'm a fan (and user) of helm, the monolithic
    design make it way more harder to
    change, and giving that CEDET is written with EIEIO (which is no
    largely used AFAIK) and it's a rather complex
    software, I can understand why there are not too much people willing
    to invest time into it.

>     2. The parser is not very good at tolerating non-conforming
>     source. I had especially a lot of this with the scheme-mode.
>     Scheme exists in 9 "standards" (of which 6 are in use, of which 3
>     are in wide use), and numerous extensions to those standards
>     (essentially, a set of extensions per compiler), so it's almost
>     guaranteed that "something not in the grammar" is going to be
>     found in the source. It would be nice to either be able to recover
>     after failures (to a certain extent), or to provide "hooks" for
>     extensions, or something like that.
    Yes, I was these past weeks changing the Emacs Lisp parser and
    adapting it to Common Lisp, the way that semantic has
    to deal with errors seems like is just ignoring it, which it's not
    the great thing for debuggable reasons. Having a nice error
    recovery system can really benefit CEDET, also point out, that using
    the Emacs reader is not always the best thing,
    because there are certain symbols that either doesn't understand
    (and break) or ignore, which can lead to confusing
    data structures.

    The speed is also a concern, giving that some software today has
    large codebases with hundreds of files and dependencies,
    if CEDET need to parse all of that synchronous  in a computer not
    that powerful, it can be a real pain for the user, some of
    the complains a read online were in that matter.

>     Better documentation would also be totally amazing!
    Yes, I think that this project needs more visibility, and a nice
    informative webpage can really help in that regard,
    having a page with outdated information is not a good sign for a
    project.

>     Thanks for your effort!
    Thank you for your suggestions!

    (Should we copy this conversation to the mailing list?)

    Regards,

    Fermin


    On 28/03/2021 04:20, Vladimir Nikishkin wrote:
>     It's always great when software gets the attention it deserves. In
>     fact, cedet is a quite good tool, which unfortunately feels
>     unfinished. I'm feeling happy that someone is ready to dedicate
>     effort to it.
>
>     If I may express a few suggestions:
>
>     1. Cedet feels a bit orthogonal to the Emacs standard way of doing
>     things. (Same has been said about helm!) For example, rebinding
>     right-click (mouse-3), seems a bit too much.
>
>     2. The parser is not very good at tolerating non-conforming
>     source. I had especially a lot of this with the scheme-mode.
>     Scheme exists in 9 "standards" (of which 6 are in use, of which 3
>     are in wide use), and numerous extensions to those standards
>     (essentially, a set of extensions per compiler), so it's almost
>     guaranteed that "something not in the grammar" is going to be
>     found in the source. It would be nice to either be able to recover
>     after failures (to a certain extent), or to provide "hooks" for
>     extensions, or something like that.
>
>     Better documentation would also be totally amazing!
>     Thanks for your effort!
>
>     --
>     Yours sincerely, Vladimir Nikishkin
>     (Sent with Google mail mobile.)
>
>     Fermin <fm...@po... <mailto:fm...@po...>> 于 2021年3月28日周日
>     04:35写道：
>
>         Hello everyone!
>
>         My name is Fermin, I'm an Emacs hacker (among other things)
>         and I've
>         been messing around with CEDET these past year or so, and I
>         really like
>         it overall,
>         I can understand his faults and how/why the Emacs community is
>         not
>         taking it into account too much these days, but I also think
>         that this
>         can change.
>
>         I will propose myself as a maintainer of CEDET in the Emacs
>         mailing
>         list, I have experience working with "legacy" software or
>         software that
>         is not
>         in active development anymore and I can bring modern ideas to
>         the table.
>
>         The most important thing for me right now is to make CEDET
>         more visible,
>         provide good documentation and encourage the community to
>         contribute.
>
>         Even tho I have the luck to have a good amount of time to
>         dedicate to
>         CEDET, I can understand that a project like this cannot
>         compete with
>         other tools in
>         the industry if I'm the only one improving it, so a community
>         effort
>         will be necessary if the project want to succeed in the future.
>
>         I started with changing the CEDET webpage to the HTML5
>         standard, but
>         with the same (awesome) aesthetic, thanks to Eric, I have the
>         source code so
>         I can replicate it easily, this is the repository
>         https://gitlab.com/sasanidas/cedet-webpage
>         <https://gitlab.com/sasanidas/cedet-webpage>, and this is the
>         webpage
>         online https://sasanidas.gitlab.io/cedet-webpage/
>         <https://sasanidas.gitlab.io/cedet-webpage/> .
>
>         If the GNU Emacs maintainers approve my position, my intention
>         is to
>         make a branch with a lot of new changes, even tho I think the
>         send patch
>         workflow is valid,
>         for a package like CEDET that needs a lot of changes, this can
>         really
>         slow down the process, so I will also try that.
>
>         Let me know what do you guys think.
>
>         Regards,
>
>         Fermin
>
>
>
>
>         _______________________________________________
>         Cedet-devel mailing list
>         Ced...@li...
>         <mailto:Ced...@li...>
>         https://lists.sourceforge.net/lists/listinfo/cedet-devel
>         <https://lists.sourceforge.net/lists/listinfo/cedet-devel>
>

[CEDET-devel] CEDET, future and Emacs

[Fermin <fm...@po...>]

Hello everyone!

My name is Fermin, I'm an Emacs hacker (among other things) and I've 
been messing around with CEDET these past year or so, and I really like 
it overall,
I can understand his faults and how/why the Emacs community is not 
taking it into account too much these days, but I also think that this 
can change.

I will propose myself as a maintainer of CEDET in the Emacs mailing 
list, I have experience working with "legacy" software or software that 
is not
in active development anymore and I can bring modern ideas to the table.

The most important thing for me right now is to make CEDET more visible, 
provide good documentation and encourage the community to contribute.

Even tho I have the luck to have a good amount of time to dedicate to 
CEDET, I can understand that a project like this cannot compete with 
other tools in
the industry if I'm the only one improving it, so a community effort 
will be necessary if the project want to succeed in the future.

I started with changing the CEDET webpage to the HTML5 standard, but 
with the same (awesome) aesthetic, thanks to Eric, I have the source code so
I can replicate it easily, this is the repository 
https://gitlab.com/sasanidas/cedet-webpage, and this is the webpage 
online https://sasanidas.gitlab.io/cedet-webpage/ .

If the GNU Emacs maintainers approve my position, my intention is to 
make a branch with a lot of new changes, even tho I think the send patch 
workflow is valid,
for a package like CEDET that needs a lot of changes, this can really 
slow down the process, so I will also try that.

Let me know what do you guys think.

Regards,

Fermin

Re: [CEDET-devel] Semantic enters debug in scheme files

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

Sorry I missed your question earlier.  It didn't show up in my new email 
list the way I would usually expect.

The parser (.by file) is used only during build time.  If you are using 
the scheme parser that is part of Emacs, then you would edit it and 
rebuild emacs.  You may need to just run the Makefile in admin/grammars. 
  I'm not sure, I'm not a core Emacs developer.

What I do remember is that the grammar is pretty simple, and got me 
through some simple scheme development several years ago.  As I look at 
the grammar, it may be relatively easy to add . as punctuation, and then 
tweak 'name-arg-expand' to have a couple other match options to get the 
match you need.

Good Luck
Eric

On 3/11/20 9:45 PM, Vladimir Nikishkin wrote:
> I am not sure if this a parser problem or a grammar problem.
> 
> I found the scheme.by grammar file in the source tree, but not in the
> working Emacs distribution. Is it only used at build time? Can I
> regenerate the parser/lexer in a working Emacs without a full rebuild?
> 
> ср, 11 мар. 2020 г. в 22:40, Vladimir Nikishkin <loc...@gm...>:
>>
>> Hello
>>
>> I have a very simple example file:
>>
>> example.scm:
>> (define (list . args)
>>    args)
>>
>> Note that this function accepts any number of arguments, therefore its
>> prototype is a dotted list. (list DOT args)
>> Semantic throws an exception when encountering such a pattern:
>>
>> Debugger entered: ((2 31))
>>    semantic--tag-expand((2 31))
>>    semantic-repeat-parse-whole-stream(((semantic-list 2 . 31)) nil nil)
>>    semantic-parse-region-default(1 33 nil nil nil)
>>    semantic-parse-region(1 33)
>>    semantic-fetch-tags()
>>    semantic-idle-scheduler-refresh-tags()
>>    semantic-idle-work-for-one-buffer(#<buffer semantic-scheme-test.scm>)
>>    semantic-idle-work-core-handler()
>>    semantic-idle-scheduler-work-function()
>>    apply(semantic-idle-scheduler-work-function nil)
>>    timer-event-handler([t 0 60 0 t
>> semantic-idle-scheduler-work-function nil idle 0])
>>
>> I'm not qualified enough to debug this. Any suggestions?
>>
>> --
>> Yours sincerely, Vladimir Nikishkin
> 
> 
> 

Re: [CEDET-devel] Semantic enters debug in scheme files

[Vladimir N. <loc...@gm...>]

I am not sure if this a parser problem or a grammar problem.

I found the scheme.by grammar file in the source tree, but not in the
working Emacs distribution. Is it only used at build time? Can I
regenerate the parser/lexer in a working Emacs without a full rebuild?

ср, 11 мар. 2020 г. в 22:40, Vladimir Nikishkin <loc...@gm...>:
>
> Hello
>
> I have a very simple example file:
>
> example.scm:
> (define (list . args)
>   args)
>
> Note that this function accepts any number of arguments, therefore its
> prototype is a dotted list. (list DOT args)
> Semantic throws an exception when encountering such a pattern:
>
> Debugger entered: ((2 31))
>   semantic--tag-expand((2 31))
>   semantic-repeat-parse-whole-stream(((semantic-list 2 . 31)) nil nil)
>   semantic-parse-region-default(1 33 nil nil nil)
>   semantic-parse-region(1 33)
>   semantic-fetch-tags()
>   semantic-idle-scheduler-refresh-tags()
>   semantic-idle-work-for-one-buffer(#<buffer semantic-scheme-test.scm>)
>   semantic-idle-work-core-handler()
>   semantic-idle-scheduler-work-function()
>   apply(semantic-idle-scheduler-work-function nil)
>   timer-event-handler([t 0 60 0 t
> semantic-idle-scheduler-work-function nil idle 0])
>
> I'm not qualified enough to debug this. Any suggestions?
>
> --
> Yours sincerely, Vladimir Nikishkin



-- 
Yours sincerely, Vladimir Nikishkin

Re: [CEDET-devel] Semantic enters debug in scheme files

[Vladimir N. <loc...@gm...>]

It seems to really cough on dotted lists. Is semantic directly using
something like (read), which reads the dotted list into a pair rather
than a list?

ср, 11 мар. 2020 г. в 22:40, Vladimir Nikishkin <loc...@gm...>:
>
> Hello
>
> I have a very simple example file:
>
> example.scm:
> (define (list . args)
>   args)
>
> Note that this function accepts any number of arguments, therefore its
> prototype is a dotted list. (list DOT args)
> Semantic throws an exception when encountering such a pattern:
>
> Debugger entered: ((2 31))
>   semantic--tag-expand((2 31))
>   semantic-repeat-parse-whole-stream(((semantic-list 2 . 31)) nil nil)
>   semantic-parse-region-default(1 33 nil nil nil)
>   semantic-parse-region(1 33)
>   semantic-fetch-tags()
>   semantic-idle-scheduler-refresh-tags()
>   semantic-idle-work-for-one-buffer(#<buffer semantic-scheme-test.scm>)
>   semantic-idle-work-core-handler()
>   semantic-idle-scheduler-work-function()
>   apply(semantic-idle-scheduler-work-function nil)
>   timer-event-handler([t 0 60 0 t
> semantic-idle-scheduler-work-function nil idle 0])
>
> I'm not qualified enough to debug this. Any suggestions?
>
> --
> Yours sincerely, Vladimir Nikishkin



-- 
Yours sincerely, Vladimir Nikishkin

[CEDET-devel] Semantic enters debug in scheme files

[Vladimir N. <loc...@gm...>]

Hello

I have a very simple example file:

example.scm:
(define (list . args)
  args)

Note that this function accepts any number of arguments, therefore its
prototype is a dotted list. (list DOT args)
Semantic throws an exception when encountering such a pattern:

Debugger entered: ((2 31))
  semantic--tag-expand((2 31))
  semantic-repeat-parse-whole-stream(((semantic-list 2 . 31)) nil nil)
  semantic-parse-region-default(1 33 nil nil nil)
  semantic-parse-region(1 33)
  semantic-fetch-tags()
  semantic-idle-scheduler-refresh-tags()
  semantic-idle-work-for-one-buffer(#<buffer semantic-scheme-test.scm>)
  semantic-idle-work-core-handler()
  semantic-idle-scheduler-work-function()
  apply(semantic-idle-scheduler-work-function nil)
  timer-event-handler([t 0 60 0 t
semantic-idle-scheduler-work-function nil idle 0])

I'm not qualified enough to debug this. Any suggestions?

-- 
Yours sincerely, Vladimir Nikishkin

Re: [CEDET-devel] How large is the difference between the SF cedet and Emacs cedet (melpa)?

[Vladimir N. <loc...@gm...>]

By the way, ede's default keybinding prefix C-c .
conflicts with org-mode's org-time-stamp command binding.

It's it really the best keybinding prefix?

Vladimir Nikishkin <loc...@gm...> 於 2020年1月16日 週四 11:15 寫道：

> Well, I'm sort of trying to use the sf version now, and it's actually
> working with scheme files better than the built-in one (due to the last
> scheme-related commit?). (In the sense that it doesn't throw exceptions.)
> It can't do a lot more though.
>
> Which tools are still not there?
> The grammars-fw manual and cogre at least...
>
>
> Eric Ludlam <er...@si...> 於 2020年1月16日 週四 10:47 寫道：
>
>> Hi Vladimir,
>>
>> Mainline Emacs version of CEDET has moved past CEDET on sourceforge due
>> to major changes to eieio.  At this point it is not possible to use SF
>> version with newer Emacsen.
>>
>> I have been posting minor patches to Emacs for missing features from SF
>> version, but it is slow going as I have limited time, and I don't have a
>> continous release from my company.  Eventually I'd like to move some of
>> the tools not in Emacs into melpa after updating them to work with newer
>> Emacs, but it will be a while without help.
>>
>> Eric
>>
>> On 1/12/20 1:11 AM, Vladimir Nikishkin wrote:
>> > I am reading the built-in Emacs CEDET manuals, and they are apparently
>> > refencing some CEDET features that are not within a standard Emacs
>> > installation. (For example, cogre is not there. Also the manual
>> > references the grammar-fw info node, which is also not present.)
>> > How large is the difference? Is it worth installing a git version of
>> > cedet for everyday usage (not for development)?
>> >
>> > You know, org-mode is also generally divergent from the main Emacs
>> > tree, but they maintain a separate MELPA repository, which allows to
>> > have a "semi-fresh" org installation without interfering with Emacs
>> > proper.  Maybe it is worth making a melpa repository with the latest
>> > CEDET?
>> >
>>
>

Re: [CEDET-devel] How large is the difference between the SF cedet and Emacs cedet (melpa)?

[Vladimir N. <loc...@gm...>]

Well, I'm sort of trying to use the sf version now, and it's actually
working with scheme files better than the built-in one (due to the last
scheme-related commit?). (In the sense that it doesn't throw exceptions.)
It can't do a lot more though.

Which tools are still not there?
The grammars-fw manual and cogre at least...


Eric Ludlam <er...@si...> 於 2020年1月16日 週四 10:47 寫道：

> Hi Vladimir,
>
> Mainline Emacs version of CEDET has moved past CEDET on sourceforge due
> to major changes to eieio.  At this point it is not possible to use SF
> version with newer Emacsen.
>
> I have been posting minor patches to Emacs for missing features from SF
> version, but it is slow going as I have limited time, and I don't have a
> continous release from my company.  Eventually I'd like to move some of
> the tools not in Emacs into melpa after updating them to work with newer
> Emacs, but it will be a while without help.
>
> Eric
>
> On 1/12/20 1:11 AM, Vladimir Nikishkin wrote:
> > I am reading the built-in Emacs CEDET manuals, and they are apparently
> > refencing some CEDET features that are not within a standard Emacs
> > installation. (For example, cogre is not there. Also the manual
> > references the grammar-fw info node, which is also not present.)
> > How large is the difference? Is it worth installing a git version of
> > cedet for everyday usage (not for development)?
> >
> > You know, org-mode is also generally divergent from the main Emacs
> > tree, but they maintain a separate MELPA repository, which allows to
> > have a "semi-fresh" org installation without interfering with Emacs
> > proper.  Maybe it is worth making a melpa repository with the latest
> > CEDET?
> >
>