Skip to content

Identification of caller for ivy-read #1957

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ThibautVerron
Copy link

@ThibautVerron ThibautVerron commented Jul 26, 2025

Hi,

With ivy, projectile uses ivy-read for completion. This function takes a named parameter :caller that allows ivy to change its behavior (e.g. ivy-rich annotations, or display-buffer behavior). As it stands, projectile always sets this parameter to projectile-completing-read.

This PR changes it to set a different caller according to what is being read: projectile-read-project for a project name, projectile-read-buffer for a buffer name, projectile-read-file for a file name, projectile-read-directory for a directory.

Based on the changelog, the purpose appears to be similar to #1892.

It is also similar to what counsel-projectile does, but that package is much larger in scope, and more opinionated. This PR won't change user-facing behavior without additional configuration on their side.

One possible friction point is if a user has already configured eg ivy-rich to match on 'projectile-completing-read. Then they will need to adjust their configuration to the new identifiers. If that is a big problem, we can add a configuration variable to make the new behavior opt-in or opt-out.


Examples of what can be done (requires additional code)

Show the current branch of the projects (very useful when juggling between multiple worktrees):
image

Have the same information with projectile-switch-buffer as with switch-buffer:
image


Before submitting a PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

  • The commits are consistent with our contribution guidelines
  • You've added tests (if possible) to cover your change(s)
  • All tests are passing (eldev test)
  • The new code is not generating bytecode or M-x checkdoc warnings
  • You've updated the changelog (if adding/changing user-visible functionality)
  • You've updated the docs (when adding new project types, configuration options, commands, etc)

Thanks!

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.

1 participant