| Age | Commit message (Collapse) | Author |
|
- projectile.el:
Initialize cache when a user opens a file can take a long time if a
project is large. Projectile should not interfere with normal Emacs
operations. Cache should only be initialized when a user uses Projectile
commands that requires the cache.
A file should not be added to cache unless the cache is initialized, to
avoid corrupting the cache with only a few files inside. A message is
displayed when Projectile starts caching process to notify the user that
Emacs is not hanged or crashed. This message is displayed on all
commands that invoke caching, not just for adding file.
- test/projectile-test.el:
Adapt test case projectile-test-cache-current-file with the new change.
|
|
|
|
Because adding a file will make the cache non-empty with that only file.
The next time a command like `projectile-find-file` is invoked, only
that single file is displayed. When the cache is empty, do not add file
but retrieves all project files first.
Also add a test case for testing projectile-cache-current-file function.
The test case contains two tests:
- One for testing when cache is initially empty. When
projectile-cache-current-file is called, cache is expected to contain
every project file. The message "Empty cache. Projectile is
initializing cache" will be printed out.
- One for testing when cache exists. In this case, it should return full
cache.
|
|
When candidates are more than 1, look up to the dirnames and try to find best matched file.
In this way, we can take advantage of dirname based namespace rules.
If the best matched file is not clear, it behaves like it did.
|
|
|
|
Fixes #448
|
|
Add a test case to demonstrate the usage of projectile-find-other-files
commands and is used for regression testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Default files for projectile-grep with prefix arg
|
|
|
|
|
|
|
|
|
|
Fixes #305
|
|
|
|
Invalidate project cache if .projectile is modified
|
|
Go through the list of known projects and remove those which
directory doesn't exist anymore.
|
|
|
|
|
|
|
|
|
|
This could be problematic in certain edge cases (like visiting files in
the project in which projectile-mode is not enabled), but is saner and cleaner.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bbatsov/projectile#129 issue.
|
|
|
|
The name of the function was confusing since it was not actually
computing the project files for a while now, so it got renamed to
`projectile-dir-files`. A couple of helper functions were also extracted
from it.
|
|
This broke the multiple subdirectory functionality, since the subdir
paths would always be incorrect.
|
|
|
|
|
|
|
|
Hashifying had serious performance implications and added next
to no value. Now Projectile relies on relative project file names and
performs much better.
|
|
|
|
For large codebases, path exclusion is unworkable (too many paths to
exclude). It's better to only include the directories you want to
include.
This change accomplishes that, by changing the .projectile file so
that entries prefixed with + are subdirectory includes, - are
subdirectory and file pattern excludes, and no prefix are also
subdirectory and file pattern excludes, to preserve backwards
compatibility.
|
|
Known projects makes it easy to return to projects that you have
previously done work on. Projects are saved whenever the system
already does caching. The main user-facing component is the
`projectile-switch-project` command, bound to 's' on the projectile
mode map, which makes it easy to switch to the new project.
|
|
adding a (customizable) option to use relative paths with projectile-find-file
|
|
|