If the first file in the projectile-current-project-files is also a
buffer, it will appear twice in the counsel-projectile list. This is
fixed by reassigning the result of the delete expression to the files
list.
Current code will show significant lag for projects with large numbers
of files. Tests with 400K files shows 15-20s lag for
counsel-projectile-find-file. Profiling showed that this was
due to the preprocessing of projectile-current-project-files to add
'ivy-virtual face to files not already in a buffer. To fix this,
a display transformer was added for this command so that the face
modification was applied only to at most ivy-height files.
The preprocessed file list was also used by counsel-projectile
code paths, so some additional modifications were made to ensure
that that code path does not change behavior. Any similar issues in
counsel-projectile performance was not addressed in this commit.
Details:
* move 'ivy-virtual face change to a display transformer function
* use projectile-current-project-files instead of counsel-projectile--file-list
for ivy-read.
* reduce the scope of counsel-projectile--file-list, making it return
only unvisited files, and renaming it accordingly. This is now only
used indirectly by the counsel-projectile function.
* change ivy-switch-buffer-transformer to propertize files at display time.
* counsel-projectile.el:
(counsel-projectile-ag-initial-input): new variable
(counsel-projectile-ag): use the above var
(counsel-projectile-rg-initial-input): new variable
(counsel-projectile-rg): use the above var
[Closes#43]
- Fix#46
- according to rg's manual, files for `--ignore-file FILE ...` should
be matched relative to the current working directory
- while `--glob` can accept files that does not exist in current
project (Thanks to @chaoyi)
`m-x counsel-projectile-switch-project` `m-o r` removes the *current* project
from `projectile-known-projects` instead of the selected one.
The expected behaviour is for the action to operate on the *selection*, which is
the case for the rest of the actions.
I was not able to determine why this was happening. The use of dynamic binding
and my inexperience with the elisp debugger were a limitation; It looks like it
might be an inconsistency in projectile, but not necessarily a bug.
For some reason, when one of these two functions was used as an action
in cp-switch-project, its actions were losing track of the project root
against which to expand filenames (they were using the root of the root
of the project from which cp-switch-project was called instead of the
root of the selected project to switch to). To fix this issue, the correct root is now recorded in the candidate
files / buffers.
