What killer feature(s) make you prefer projectile over project.el?

I moved to project.el a while back. but want to make sure i'm not missing out anything that projectile users find invaluable. Unsurprisingly perhaps, this thought was spurred on by the latest projectile release. I most likely won't move back to projectile with this information, but may implement any very compelling features atop project.el.

As I use Doom, I theoretically use projectile ... But in reality,I don't use it. I'm happy that magit and eglot/clangd know the boundaries of my project, I don't really need more. Or do I? What killer features do you use in project?

> Unsurprisingly perhaps, this thought was spurred on by the latest projectile release. For those not on the bleeding edge, what do you mean?

I think they may be referring to https://www.reddit.com/r/emacs/comments/yd1hkp/projectile_26_released/.

> What killer feature(s) make you prefer projectile over project.el? - it's been there for 10 years or something and worked well all this time (edit: to clarify, I use Emacs and Projectile for my everyday work, not for tinkering, if it ain't broke, don't fix it) - project.el was _inspired by_ projectile, not vice versa - while Bozhidar and co are maintaining projectile - it will be ahead of project.el (for lots of reasons).

For me it’s the project type, being able to specify generically how to build, run and test a project is amazing

For me there is no killer feature that keeps me with projectile. It's a habit mostly. I only use `projectile-find-file` and `projectile-ripgrep` most of the time. Which makes me think to ditch projectile in favor of project.el just to reduce the amount of duplicated functionality in my emacs. On the other hand it's much easier to contribute to projectile (github, no FSF signature required). Which makes me think not to ditch projectile...

I moved to projectile from project.el a while ago. I forgot the exact reason, but generally projectile is more feature-complete and packed with well-designed feature set and I can just use them instead of rolling out my own version. Customizing project.el usually involves writing your own commands, advice, and such. I’m tired of that.

No reasons about it specifically, just it reminded me of my ongoing interest in deciding which I prefer.

Yes, i just saw this and thought others reasons might help me decide.

I use both, project for integration with emacs packages and projectile for the fast file-selection mechanism in a big project. Project alone would work but it blocks my “open a project file” dialog in this repo for 10 seconds, and that was really annoying. Projectile’s “alien” listing methods win here.

I like project because I can do c-x p c and it will run compile from the project root folder, which is very convenient for what I do. Also, doesn't eglot use project to find the boundaries?

The "lots of reasons" would be the interesting part, the rest is less meaningful for those not already using it.

i use projectile-project-p and projectile-project-root in many my custom functions

I particularly love the handy projectile function projectile-find-file-in-known-project.

Thanks for the vote of confidence! :-) I've always seen the community as Projectile's biggest advantage - obviously it's a lot easier to contribute to a project that's not restrained by Emacs's contribution paperwork, guidelines and so on. I've said this several times in the past - there was a moment in time where Projectile could have become part of Emacs, but I never considered this seriously as I wanted to keep the development as open and as welcoming as possible. That being said, I'm happy that Projectile inspired project.el and people get some good project management tool out-of-the-box. Btw, these days it's easier to install Projectile than ever, given it's now part of the official NonGNU ELPA repo (enabled in Emacs 28+ by default).

I'm obviously biased, as Projectile's author, so take my comments with a grain of salt. :-) I think that one nice advantage of Projectile is that it knows about a lot of build tools (e.g. Maven, Leiningen, Make, etc) and can interact with the them easily. Projectile's also quite flexible in terms of project indexing methods (pure Elisp, a combination of Elisp and external commands, only external commands), supports project caching and so on. I guess not everyone would need this flexibility, but it's handy to have it. I also love the Projectile Commander, the countless ways to search within a project, and the infinite configuration options. Generally if project.el gets the job done for you, you should probably stick with it. If you feel you need something more you can explore what Projectile has to offer. Projectile has a lot of docs and even a small section on how it compares with project.el (see [https://docs.projectile.mx/projectile/faq.html#how-does-projectile-compare-to-the-built-in-project-el](https://docs.projectile.mx/projectile/faq.html#how-does-projectile-compare-to-the-built-in-project-el)). As noted in another response - I think the killer feature of Projectile is that's it's very easy to contribute to it, which is not always the case with core Emacs projects. I think that's one feature you'll find it hard to implement in project.el. :-) P.S. Many people seem to believe that if something's in core Emacs it's the one true way, it should have all the "best" features and the competition should just wither and die. Focus is good, right? While I don't object to project.el borrowing features from Projectile, I think that some competition and alternatives are good for an ecosystem and you probably don't want to be left with a single option at the end of the day. Just my 2 cents on a very complex topic.

Ah I see. Thanks.

Thanks for your work! > I've always seen the community as Projectile's biggest advantage - obviously it's a lot easier to contribute to a project that's not restrained by Emacs's contribution paperwork, guidelines and so on. yep, that's one of the "reasons" I was thinking of :)

Projectile may indeed have inspired some features in project.el, but all have taken inspiration from EDE, filesets and in particular the likes of JRockway's eproject. The latter especially drove a lot of foundational concepts that we now take for granted in project.el --- and projectile. I used eproject until project.el became mature/stable enough to use. Filesets for instance introduced `M-x filesets-run-cmd` which is surely one of the earliest instances of a project-aware tool set in Emacs. EDE and eproject could also delineate based on the presence of files or directories like a git directory. Filesets/EDE worked more on the older, IDE-style "add files to project" mentality. The value of `project.el` is that it finally -- **finally** -- adds a standardised system for collating and interacting with collections of files in a sane and consistent manner. That and the emacs development team have decided to extend functionality in other parts of Emacs to support it. That is its value.

[deleted]

While I can't speak about the sources of inspiration for \`project.el\` I can tell you that I drew zero inspiration from EDE and eproject, as I've never used them. :-) All my inspiration came from \`ffip\` (for the original \`projectile-find-file\` command) and from the IDEs I was using alongside Emacs. Basically I wanted to make the interaction with projects as nice as it was in IntelliJ IDEA. It's a long story that I'll have document at some point. :-) I'm not arguing about the value of \`project.el\`, although I really think that most projects only need a notion of a project root (project discovery) and basic concepts like project files, dirs, etc and the interactions/operations with them could be left to other libraries.

No idea who downvoted you, you tried to give an answer after all. For compiling I wrote my own elisp, see https://github.com/holgerschurig/emacs-doom-config/blob/master/my-compile.el Badically it's combining completing-read with history, so that I can enter compile commands and can re-select them. E.g. Shift-F9 prompts, F9 just compiles. It predates project/projectile, so it uses locate-dominating-file to find the .git moniker. Also it can parse special formatted comments to populate the list of valid compile commands that way, too. Not just from hand-entering them. I used that back in my help days.Then with Ivy (see the file starting with ivy in the same directory). And now with plain completing-read, which is beefed up by consult now. Also, if you have embark,you can delete entries while in the completion, to get rid of compile history entries with typos.

I actually switched from Projectile to project.el a little while ago, but I want to say that I still appreciate Projectile as a, um, project; and especially the firm dedication to being open to all contributors.

Interesting code! It goes to show how people have different needs and the best part of emacs is that we can customize it to better fit our preferences

Just wanted to say thanks for projectile and thank you for weighing in on this thread. I was a projectile user for many years and it has had a very positive impact on my productivity.

I've only recently started using project.el because eglot uses that and I wanted to switch to that from lsp-mode. There are some things I really like with projectile, like the ability to change how the root is found easier. I really like the projectile-vterm command. I use both right now, but mainly projectile.

projectile-kill-project is one of the most used functions. Also compiling, testing, configuring projects make me very happy Emacs user. Basically I have all IDE features in Emacs, thanks to projectile + lsp-mode.