[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project-mode vs projectile

From: Dmitry Gutov
Subject: Re: project-mode vs projectile
Date: Thu, 7 Oct 2021 05:39:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 05.09.2021 14:35, Steinar Bang wrote:
Dmitry Gutov <>:

First of all, it's not a mode. A recent enough version of project.el
just installs a global keymap and lets you use its bindings.

Hm... ok. I've seen some bindings mentioned in a google hit, but when I
tried using them on emacs 27 (I don't have a reference to the google hit

Is this for emacsen newer than 27.1?

Like I said, it's grown a little in Emacs 28. You can install that version from GNU ELPA in Emacs 27 as well.

One advantage is it doesn't run any code (e.g. root-finding code)
until you actually use one of the related commands.

An advantage in performance?

I don't know what projectile does here, but I suspect that, with the
correct configuration (which is *not*, as I found, "scan everything on
startup"...), projectile doesn't do much either, until the commands are

It doesn't do "much", but it does stuff, for example,

  (add-hook 'find-file-hook 'projectile-find-file-hook-function)

which isn't too bad by itself but contributes to the "death by a 1000 cuts" in configurations where many packages are installed. Or when you just need to visit many files quickly.

I've used it for years, it's a handy package. project.el started out
as a kind of backdoor to be able to use projectile indirectly in core
Emacs commands. That still hasn't panned out exactly, but I'm hopeful
on that front too.

Hm... are you saying project.el and projectile are releated somehow?

They will be more "related" when Bozhidar gets around to merging the "bridging" code which allows Projectile to act as a project.el backend.

Any year now.

If you want some dedicated support, we'll need to clarify the
requirements. For instance, would you be happy if mvn modules were
treated as separate projects?

Ideally I would like the project level commands to remain as they are.

But I would like to have a similar set of commands that operate on the
specified module only (search, replace, build, at least).

And maybe a simple way to navigate to a specified module.

All right, thanks.

I've outlined my brief thoughts on the subject of module-specific functionality in the second part of the email here:

I think that leaves only the "module compile command", and that seems
somewhat maven-specific. You could create a new command which would
look up what kind of project the current file is in, and invoke some
corresponding action.

What I currently do, is have a text file in each project, not commited
to git, and containing canned commands for building each project.

And then I just go to that file, copy them, and then feed them to "M-x
compile" to build a specific project.

But this is cumbersome, and error prone (I have may times built the
wrong module and not understood why my changes weren't showing up) and
cd followed by a command, doesn't work on windows emacs.

Here's an example of such a text file:
  cd ~/workspaces/sampleapp/sampleapp.web.frontend/; mvn -B install -DskipTests 
-Dmaven.javadoc.skip=true -Dmaven.source.skip=true
  cd ~/workspaces/sampleapp/sampleapp.db.liquibase.test/; mvn -B install 
-DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
  cd ~/workspaces/sampleapp/sampleapp.backend/; mvn -B install -DskipTests 
-Dmaven.javadoc.skip=true -Dmaven.source.skip=true
  cd ~/workspaces/sampleapp/sampleapp.web.api/; mvn -B install -DskipTests 
-Dmaven.javadoc.skip=true -Dmaven.source.skip=true

Sounds like it can be automated, with or without project.el integration. Though perhaps you'd have to transition to a more structured file format like yml/json/lisp. Which might be more of a pain to write.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]