Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projectile-project-type could return the wrong project type when called with argument #1806

Merged
merged 10 commits into from
Oct 31, 2022

Conversation

fanshi1028
Copy link
Contributor

Expected behavior

(projectile-project-type DIR) should return the right project type.

Actual behavior

(projectile-project-type DIR) sometimes return the wrong project type

Why

The problem is, some logic branches inside projectile-project-type involve calling
(projectile-detect-project-type) which use the default-directory instead of the DIR we supply.

Potential Fix

  1. Amend projectile-detect-project-type to take optional argument DIR(just like projectile-project-type).

  2. Pass along the input from the projectile-project-type to projectile-detect-project-type

Steps to reproduce the problem

Let DIR1 and DIR2 be 2 directories from projects of different types

Call (projectile-project-type DIR2) from a DIR1, you will get DIR1's project type instead of DIR2's(given that DIR2's project type is not cached)

Environment & Version information

Projectile version information

Projectile 2.6.0-snapshot

Emacs version

GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.6 (Build 19G2021))

Operating system

macOS

@fanshi1028 fanshi1028 changed the title Projectile-project-type could return the wrong project type when called when argument Projectile-project-type could return the wrong project type when called with argument Oct 17, 2022
fanshi1028 added a commit to fanshi1028/projectile that referenced this pull request Oct 17, 2022
fanshi1028 added a commit to fanshi1028/projectile that referenced this pull request Oct 17, 2022
fanshi1028 added a commit to fanshi1028/projectile that referenced this pull request Oct 17, 2022
@fanshi1028
Copy link
Contributor Author

I could have just bind the default-directory locally in the middle of the stack to fix the issue. But currently I chose to go deeper down the function stack to make those functions taking the same optional dir as argument, kind of give them a more unified interface. Which way do you prefer?

fanshi1028 added a commit to fanshi1028/.doom.d that referenced this pull request Oct 21, 2022
@bbatsov
Copy link
Owner

bbatsov commented Oct 25, 2022

Your suggestions seem reasonable, but I'm not quite sure what exactly is the problem that you've encountered (and I don't see any new tests that's illustrate it). I got that somewhere the project detection is failing, because it's not acting on the right folder, but you didn't say where exactly.

fanshi1028 added a commit to fanshi1028/projectile that referenced this pull request Oct 30, 2022
@fanshi1028
Copy link
Contributor Author

Your suggestions seem reasonable, but I'm not quite sure what exactly is the problem that you've encountered (and I don't see any new tests that's illustrate it). I got that somewhere the project detection is failing, because it's not acting on the right folder, but you didn't say where exactly.

Here is a branch with just the commit for the tests for the issues.
master + tests

Briefly, what I did was calling (projectile-project-type DIR1) while I was at default-directory of DIR2. In this case I thought I would get the projectile-project-type of DIR1 instead of DIR2, but it failed my expectation.

@bbatsov bbatsov merged commit d6ef51d into bbatsov:master Oct 31, 2022
@bbatsov
Copy link
Owner

bbatsov commented Oct 31, 2022

Got it. Thanks for working on this! 🙇‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants