Confused about Emacs project management support

There is project.el (inbuilt), EDE (inbuilt) and many others to choose from. I understand that project.el is "new" and follows the approach when there is a .git folder and other heuristics to auto-determine what a constitutes a project. EDE is "old" and has a declarative approach. Yet EDE is prominently documented and has imenu-entries, suggesting newcomers to click and try. Is EDE using project.el under the hood? And if not: Wouldn't project.el warrant menu entries?

project.el and EDE serve different purposes. As you pointed out, EDE is old, and you are unlikely to use it in modern software development. Use one of the LSP clients (e.g. eglot, lsp-mode, lsp-bridge, etc.) instead.

There's EDE and filesets in Emacs. There's also a million third-party libs out there that all compete to do more or less the same basic concept. It's a legit question, and I consider this area one of Emacs's greatest failings, though the collective effort being poured into `project.el` is doing a lot to undo some of that. Emacs desperately needs a standardised project suite that can do basic actions on a collection of like files. It's imperative that both users and package developers can rely on such a thing existing. EDE, project and filesets all serve that role. But `project.el` is now the standard, and it works well. Project should have menu bar entries and I'm surprised it does not. I do not know why they didn't promote and maintain EDE when it was merged more than a decade ago: Emacs would've had solid project management support. Filesets is equally advanced -- and been around for decades -- and can do a lot of stuff. It too was consigned to the dustbin of forgotten history.

EDE, Cedet all tried but never completely finished.

project.el is from my pov almost a carbon copy of projectile. I think the Emacs devs saw projectile's success and copied it almost but a little worse since prjectile still has better project type integration. Also project.el wants you to use vc.

Carbon copy? Maybe. Maybe not. But projectile didn't invent any of the concepts it uses. Not at all. I used jrockway's eproject for many, many years and it predates projectile. Filesets predate all of the aforementioned solutions and it, too, has many of the features found in projectile and `project.el`. Why shouldn't `project.el` use vc? Why would you build a project management solution that does not leverage a version control wrapper that supports a wide range of source control systems?! It's the most natural and obvious way to add support for a panoply of version control systems.

They're also pretty hard to use imo

Cedet is like Tree-Sitter but older. Sadly it never want anyware besides it's initial state. The only downside one the current lsp ecosystem is that there's no gcc backend so far.

>Carbon copy? Maybe. Maybe not. But projectile didn't invent any of the concepts it uses. Not at all. I used jrockway's eproject for many, many years and it predates projectile. Filesets predate all of the aforementioned solutions and it, too, has many of the features found in projectile and project.el. I wasn't aware of that thanks for pointing it out. >Why shouldn't project.el use vc? > >Why would you build a project management solution that does not leverage a version control wrapper that supports a wide range of source control systems?! It's the most natural and obvious way to add support for a panoply of version control systems. I get the point but vc feels dated compared to magit and doesn't support forges.

> I get the point but vc feels dated compared to magit and doesn't support forges. That has nothing to do with project management or `project.el`. Nothing at all. Vc is used to determine root directory and files to ignore/include. That is the benefit of a version control-agnostic tool like Emacs's vc.

> But projectile didn't invent any of the concepts it uses. Not at all. I used jrockway's eproject for many, many years and it predates projectile. Filesets predate all of the aforementioned solutions and it, too, has many of the features found in projectile and project.el. Sure, but in my opinion, only Projectile provided the intuitive (because it literally provides project-specific versions of generic Emacs commands), polished and (almost) zero-setup solution (I can't remember if I ever created `.projectile` file), perfectly suited for modern development practices. I tried some different solutions before that but they all required some manual work to be used, so neither of them lasted long (longer than a day, I'd say). Projectile just clicked! I can remember two more packages that 1. clicked 2. just worked 3. were intuitive to use - `ivy` (I used to use `ido` before, and hated it because of non-emacsy defaults) - `magit`. That's where I started using `git` from Emacs, and it improved my workflow significantly. `vc` looks more like a bunch of functions than a complete solution. > Carbon copy? Maybe. Maybe not. Aren't they literally rewriting Projectile commands?

This is literally the first time I've ever heard of filesets. Handy.

Glad you like projectile. It's a nice tool, and many like it. The notion of declaring something the root of a project is not novel; it's so intuitive that we would all coalesce to the same handful of methods of doing it. That a human instinctively knows the root of their 'project' is evidence is enough. It's either: - Explicit lists of files, declared in project file, a la old-school IDEs; - or, implicit lists of files, drawn from the presence of another file (`setup.py`, `.git.`, etc.) that serves as a root. That is why so many tools out there do exactly that. Carbon copying from a common third-party package is logical, but that does not make the code being copied novel. (See `fileset-commands` variable in `filesets.el` for an example of that.)

Not just that project.el also open vc on the project, it call it directly unless there's a a way to reconfigure that it has something to do with project.el.

> Explicit lists of files, declared in project file, a la old-school IDEs; That's what I didn't like both in old-school IDEs and pre-projectile Emacs plugins, why do the job that can be done automatically? > Carbon copying from a common third-party package is logical, but that does not make the code being copied novel. The novel thing in projectile is it feels consistent, featureful and, as I said, zero-setup (see my magit/vc comparison).

I use projectile and like it a lot. Maybe you will too.

Can somebody name the main differences of projectile and project.el? Maybe even elaborate, why one would choose one or the other.

You might like the filecache library as well.

Filecache was probably a lot more relevant in a time before super fast search apps; I use everything search as my locate with helm, and the returns are pretty near instantaneous (and I keep multiple named instances running by using a .dir-locals.el file at every project root). The fact that you have to add files to the filecache per session seems ridiculous. But also, I kinda wonder why this isn't just an autopopulated cache. (Actually, depending on what completion framework you're using, it probably is--fuzzy matching and recentf and frequency based sorting probably bubble these files to the top automatically.) But thanks for the tip if for no other reason than revealing yet another thing I never knew about emacs, even after more than 20 years of using it. Always something new to discover!

projectile does offer more features such as better integration towards project types. E.g. try projectile-configure-project or projectile-build-project.

If you know of ksh's directory aliases, thats how I use the filecache library.