Should EDE use project.el

Should EDE use project.el

[Ergus]

Hi:

Recently working in the gtags-mode package I thought to add a backend
for ede/cedet... but I have found that most of the ede features overlap
or coincide with ones in project.el.

So my question is: Isn't it easier to add a backend in locate.el to make
ede use project as one ede-locate-setup-options?

I am not sure about how useful is ede or cedet these days as they seem
to be a bit unmaintained, but IMHO, if we don't want to remove them (for
some reason) but still keep project.el as the preferred way to go, then
maybe cedet should use the project.el functions by default.

The basic implementation seems to need only:

initialize-instance
ede-locate-ok-in-project
ede-locate-file-in-project-impl
ede-locate-create/update-root-database

Implementing all these may be extremely simple but not sure if it worth
the effort.

What do you suggest?

Best,
Ergus

Re: Should EDE use project.el [PATCH]

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

Hi:

I just attached an extremely simple (intested) attempt to make cedet use
Project.el.. Maybe Dmitry or someone with more experience may complete
this and extend it when possible?

Best,
Ergus

On Mon, May 16, 2022 at 01:46:43PM +0200, Ergus wrote:
>Hi:
>
>Recently working in the gtags-mode package I thought to add a backend
>for ede/cedet... but I have found that most of the ede features overlap
>or coincide with ones in project.el.
>
>So my question is: Isn't it easier to add a backend in locate.el to make
>ede use project as one ede-locate-setup-options?
>
>I am not sure about how useful is ede or cedet these days as they seem
>to be a bit unmaintained, but IMHO, if we don't want to remove them (for
>some reason) but still keep project.el as the preferred way to go, then
>maybe cedet should use the project.el functions by default.
>
>The basic implementation seems to need only:
>
>initialize-instance
>ede-locate-ok-in-project
>ede-locate-file-in-project-impl
>ede-locate-create/update-root-database
>
>Implementing all these may be extremely simple but not sure if it worth
>the effort.
>
>What do you suggest?
>
>Best,
>Ergus
>

[-- Attachment #2: cedet.patch --]
[-- Type: text/plain, Size: 1947 bytes --]

diff --git a/lisp/cedet/ede/locate.el b/lisp/cedet/ede/locate.el
index b9b1194ccc..67bd698b5f 100644
--- a/lisp/cedet/ede/locate.el
+++ b/lisp/cedet/ede/locate.el
@@ -64,8 +64,8 @@ ede-locate-setup-options
 		  (const :tag "locate" ede-locate-locate)
 		  (const :tag "GNU Global" ede-locate-global)
 		  (const :tag "ID Utils" ede-locate-idutils)
-		  (const :tag "CScope" ede-locate-cscope)))
-  )
+		  (const :tag "CScope" ede-locate-cscope)
+                  (const :tag "Project" ede-locate-project))))
 
 ;;;###autoload
 (defun ede-enable-locate-on-project (&optional project)
@@ -204,6 +204,45 @@ ede-locate-file-in-project-impl
     )
   )
 
+;;; PROJECT
+;;
+
+(declare-function project-current "project")
+(declare-function project-files "project")
+
+(defclass ede-locate-project (ede-locate-base)
+  ()
+  "EDE Locator using Project.el")
+
+(cl-defmethod initialize-instance ((_loc ede-locate-project) &rest _slots)
+  "Make sure that we can use Project API."
+  (cl-call-next-method)
+  (if-let* ((project (project-current))
+	    (root (project-root project)))
+      nil
+    (error "No Project.el project found for %s" default-directory)))
+
+(cl-defmethod ede-locate-ok-in-project ((_loc (subclass ede-locate-project))
+                                        root)
+  "Is it ok to use this project type under ROOT."
+  (when-let ((default-directory root))
+    (project-current)))
+
+(cl-defmethod ede-locate-file-in-project-impl
+  ((_loc ede-locate-project) filesubstring)
+  "Locate occurrences of FILESUBSTRING in LOC, using Project.el."
+  (mapcan (lambda (filename)
+            (when (string-match filesubstring filename)
+              filename))
+          (project-files (project-current))))
+
+
+(cl-defmethod ede-locate-create/update-root-database
+  ((_loc ede-locate-project) _root)
+  "Create or update Project for the current project.
+This is not applicable in generalized project.el."
+  )
+
 ;;; GLOBAL
 ;;
 

Re: Should EDE use project.el [PATCH]

[Dmitry Gutov]

On 16.05.2022 18:00, Ergus wrote:
> Hi:
> 
> I just attached an extremely simple (intested) attempt to make cedet use
> Project.el.. Maybe Dmitry or someone with more experience may complete
> this and extend it when possible?

Looks okay to me.

To give more detailed feedback, one might need more knowledge of CEDET, 
I think

Do you use it? CEDET, I mean. If yes, this can be a beneficial direction 
to go in. My observations say it's only falling out of favor, though.

> 
> Best,
> Ergus
> 
> On Mon, May 16, 2022 at 01:46:43PM +0200, Ergus wrote:
>> Hi:
>>
>> Recently working in the gtags-mode package I thought to add a backend
>> for ede/cedet... but I have found that most of the ede features overlap
>> or coincide with ones in project.el.
>>
>> So my question is: Isn't it easier to add a backend in locate.el to make
>> ede use project as one ede-locate-setup-options?
>>
>> I am not sure about how useful is ede or cedet these days as they seem
>> to be a bit unmaintained, but IMHO, if we don't want to remove them (for
>> some reason) but still keep project.el as the preferred way to go, then
>> maybe cedet should use the project.el functions by default.
>>
>> The basic implementation seems to need only:
>>
>> initialize-instance
>> ede-locate-ok-in-project
>> ede-locate-file-in-project-impl
>> ede-locate-create/update-root-database
>>
>> Implementing all these may be extremely simple but not sure if it worth
>> the effort.
>>
>> What do you suggest?
>>
>> Best,
>> Ergus
>>

Re: Should EDE use project.el [PATCH]

[Ergus]

On Mon, May 16, 2022 at 06:50:59PM +0300, Dmitry Gutov wrote:
>On 16.05.2022 18:00, Ergus wrote:
>>Hi:
>>
>>I just attached an extremely simple (intested) attempt to make cedet use
>>Project.el.. Maybe Dmitry or someone with more experience may complete
>>this and extend it when possible?
>
>Looks okay to me.
>
>To give more detailed feedback, one might need more knowledge of 
>CEDET, I think
>

>Do you use it? CEDET, I mean. If yes, this can be a beneficial 
>direction to go in. My observations say it's only falling out of 
>favor, though.
>
Actually I don't know how to use it properly yet. I just tried this
because I tried something with gtags and I found that it has its own
backend for global/gtags BUT un-optimized and tramp and similes fail (as
expected).

The last commit in their git repo was in 2019 and it seems to be almost
totally unmaintained (in a quick test I found some issues
immediately)... which means I am not even sure if there is anyone still
using it.

So my first recommendation would be to remove/deprecate it in favor of
project.el; but as I know that such a suggestion is impossible, I just
recommend to make it a wrapper for project.el by default when possible.

The only feature missing in project.el to totally overlap EDE is the
concept of update; which cedet seems to use but project does not
understand (probably because in the new backends may not be needed..)

Best,
Ergus

>>
>>Best,
>>Ergus
>>
>>On Mon, May 16, 2022 at 01:46:43PM +0200, Ergus wrote:
>>>Hi:
>>>
>>>Recently working in the gtags-mode package I thought to add a backend
>>>for ede/cedet... but I have found that most of the ede features overlap
>>>or coincide with ones in project.el.
>>>
>>>So my question is: Isn't it easier to add a backend in locate.el to make
>>>ede use project as one ede-locate-setup-options?
>>>
>>>I am not sure about how useful is ede or cedet these days as they seem
>>>to be a bit unmaintained, but IMHO, if we don't want to remove them (for
>>>some reason) but still keep project.el as the preferred way to go, then
>>>maybe cedet should use the project.el functions by default.
>>>
>>>The basic implementation seems to need only:
>>>
>>>initialize-instance
>>>ede-locate-ok-in-project
>>>ede-locate-file-in-project-impl
>>>ede-locate-create/update-root-database
>>>
>>>Implementing all these may be extremely simple but not sure if it worth
>>>the effort.
>>>
>>>What do you suggest?
>>>
>>>Best,
>>>Ergus
>>>
>

Re: Should EDE use project.el [PATCH]

[Ergus]

On Mon, May 16, 2022 at 06:50:59PM +0300, Dmitry Gutov wrote:
>On 16.05.2022 18:00, Ergus wrote:
>>Hi:
>>
>>I just attached an extremely simple (intested) attempt to make cedet use
>>Project.el.. Maybe Dmitry or someone with more experience may complete
>>this and extend it when possible?
>
>Looks okay to me.
>
>To give more detailed feedback, one might need more knowledge of 
>CEDET, I think
>
>Do you use it? CEDET, I mean. If yes, this can be a beneficial 
>direction to go in. My observations say it's only falling out of 
>favor, though.
>

I only get messages like this all the time:

Debug on Error enabled globally
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration>-  which-key: There are no keys to show [2 times]
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration> <menu-bar> is undefined
<cedet-menu> is undefined
<ede-new> is undefined
Remote file error: Forbidden reentrant call of Tramp [3 times]
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration>-  which-key: There are no keys to show [2 times]
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration> <menu-bar> is undefined
<cedet-menu> is undefined
<ede-new> is undefined
Remote file error: Forbidden reentrant call of Tramp [3 times]
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration>-  which-key: There are no keys to show [2 times]
<menu-bar> <cedet-menu> <ede-project-options> <Default configuration> <menu-bar> is undefined
<cedet-menu> is undefined
<ede-project-options> is undefined
<Default configuration> is undefined

So I am 90% sure nobody is trying cedet with tramp.

>>
>>Best,
>>Ergus
>>
>>On Mon, May 16, 2022 at 01:46:43PM +0200, Ergus wrote:
>>>Hi:
>>>
>>>Recently working in the gtags-mode package I thought to add a backend
>>>for ede/cedet... but I have found that most of the ede features overlap
>>>or coincide with ones in project.el.
>>>
>>>So my question is: Isn't it easier to add a backend in locate.el to make
>>>ede use project as one ede-locate-setup-options?
>>>
>>>I am not sure about how useful is ede or cedet these days as they seem
>>>to be a bit unmaintained, but IMHO, if we don't want to remove them (for
>>>some reason) but still keep project.el as the preferred way to go, then
>>>maybe cedet should use the project.el functions by default.
>>>
>>>The basic implementation seems to need only:
>>>
>>>initialize-instance
>>>ede-locate-ok-in-project
>>>ede-locate-file-in-project-impl
>>>ede-locate-create/update-root-database
>>>
>>>Implementing all these may be extremely simple but not sure if it worth
>>>the effort.
>>>
>>>What do you suggest?
>>>
>>>Best,
>>>Ergus
>>>
>
>

Re: Should EDE use project.el [PATCH]

[Eli Zaretskii]

> Date: Mon, 16 May 2022 18:09:38 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >Do you use it? CEDET, I mean. If yes, this can be a beneficial 
> >direction to go in. My observations say it's only falling out of 
> >favor, though.
> >
> Actually I don't know how to use it properly yet. I just tried this
> because I tried something with gtags and I found that it has its own
> backend for global/gtags BUT un-optimized and tramp and similes fail (as
> expected).
> 
> The last commit in their git repo was in 2019 and it seems to be almost
> totally unmaintained (in a quick test I found some issues
> immediately)... which means I am not even sure if there is anyone still
> using it.
> 
> So my first recommendation would be to remove/deprecate it in favor of
> project.el

CEDET includes many features that project.el doesn't have (and AFAIU
is not intended to have any time soon, if at all).  Moreover, some of
those features are actively used, for example by Xref commands.  I
don't understand how we can deprecate those parts, let alone remove
them.

Maybe you only meant the parts in CEDET that handle project structure,
i.e. that overlap what project.el does.  Those parts we could perhaps
consider deprecating, especially if we can make CEDET use project.el
instead.  But AFAIR that's a very small part of what we have below
cedet/, functionality-wise.

Re: Should EDE use project.el [PATCH]

[andres.ramirez]

Hi. Guys.

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


[...]

    Eli> CEDET includes many features that project.el doesn't have (and AFAIU is not intended to
    Eli> have any time soon, if at all).  Moreover, some of those features are actively used, for
    Eli> example by Xref commands.  I don't understand how we can deprecate those parts, let alone
    Eli> remove them.

    Eli> Maybe you only meant the parts in CEDET that handle project structure, i.e. that overlap
    Eli> what project.el does.  Those parts we could perhaps consider deprecating, especially if we
    Eli> can make CEDET use project.el instead.  But AFAIR that's a very small part of what we have
    Eli> below cedet/, functionality-wise.


I use srecode and cogre. And I have read over years on this list that
some people use also wisent.

Best Regards