Use projectile root if available

[katafrakt]

If projectile is available, use its root directory to set as current directory when creating a comint buffer. This way aider --subtree-only will start correctly in the project root, not in the semi-random location related to current file.

I tested it and it seems to work well. Would be great if someone without projectile could confirm it does not break anything (although it really should not).

Addresses #23

[tninja]

Thanks for using this library and put effort on it!

For #23, I believe this PR can resolve the problem. However, I still wish I can get more information on why git cannot get the right project root? (eg. a example git repo case can reproduce the problem). And I even wish that the problem can be resolved by some git command.

I am asking the question, because that I am trying to minimize the dependency of this project. (Even I am a projectile lover and has been using it for >10 years). Less dependency will make the project easier to maintain and evolve. So, If the problem can be resolved by git, which is the nature dependency of aider project, I'll prefer to keep using git.

[katafrakt]

I understand what you are saying about dependencies and I agree. However, there seems to be a misunderstanding. I don't wand Aider to start in a git root. If I did, I wouldn't have used --subtree-only. I want to scope it only to the part of the monorepo - ideally to current projectile project, but might be also some other way to predictable set where it should be scoped.

I cannot share the repo where I have this problem, but I will try to find some public one and reproduce there.

[tninja]

Sounds good. A example to reproduce the issue would be definitely help to this. Also, I thought aider was designed to work with git. In its github page, it said: "Aider lets you pair program with LLMs, to edit code in your local git repository.". So even in the command line version of aider, it need to work with git. Let me know if I was wrong on that.

[katafrakt]

Yes, it's still inside a github repo, just not in its root.

Let's say you work on Ruby on Rails monorepo, but only on actioncable subproject.

git clone https://github.com/rails/rails.git
cd rails
touch actioncable/.projectile

Now open a rails/actioncable in Emacs.

Aider wants to always operate on the whole repo, which makes it slow. In case of my work monorepo, unbearably slow. Which is why I use --subtree-only option for Aider, as suggested here. But now Aider opens relative to the file in the buffer I open it from. If I am at rails/actioncable/Gemfile, if sets current dir at rails/actioncable. However if my open buffer has rails/actioncable/lib/action_cable/helpers/action_cable_helper.rb, the current dir is set to rails/actioncable/lib/action_cable/helpers. As a result I have to be very careful from where I start Aider from.

This seems to be less random than I initially thought, but still would be better if I could have it always start at projectile root. However, I'm fine with keeping these changes local to my installation at this point. Should I close this PR?

[tninja]

Got it. Thanks for explaining. Seems that it is a useful strategy for large repo with submodule. And the work want to focus on a particular submodule.

Given the description, I feel that it is useful for some case but not necessarily to everyone at this moment. I am wondering that if we can put the projectile version of function (aider-run-aider) to a new file, aider-projectile.el? It can be optionally loaded, just like aider-helm.el? Would be also put a section in README, Optional part, to describe how to load and use it.

And your words are very helpful to explain when to use it. Wonder if it is possible to put them into the comment of the updated version of aider-run-aider (in aider-projectile.el).

In the future, if there is any other projectile related function, maybe it is good to keep them in that file.

[katafrakt]

This makes a lot of sense. I will make this change.