Re: project-mode vs projectile

[Dmitry Gutov]

On 05.09.2021 14:35, Steinar Bang wrote:
> > > > > > Dmitry Gutov <dgutov@yandex.ru>:
>
> > 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
> handy).
>
> 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
> used.

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: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#146

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

Cheers,
Dmitry.