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

counsel-git-grep' followed by ivy-next-history-element' #409

Closed
jdahm opened this issue Feb 29, 2016 · 13 comments
Closed

counsel-git-grep' followed by ivy-next-history-element' #409

jdahm opened this issue Feb 29, 2016 · 13 comments

Comments

@jdahm
Copy link

jdahm commented Feb 29, 2016

Excellent work with ivy, I recently switched back from ido again.

As for this issue: the message "3 chars left" disappears, but the combination doesn't start the git grep process. Typing more chars doesn't help.

@abo-abo
Copy link
Owner

abo-abo commented Feb 29, 2016

It works on my end. Try to reproduce with emacs -Q.

@jdahm
Copy link
Author

jdahm commented Feb 29, 2016

Still not working. It's only after I remove the ''<" and the ">" that it finds a match.

@abo-abo
Copy link
Owner

abo-abo commented Feb 29, 2016

git --version?

@jdahm
Copy link
Author

jdahm commented Feb 29, 2016

$ git --version
git version 2.5.0

@abo-abo
Copy link
Owner

abo-abo commented Feb 29, 2016

Can you try with 2.7.2?

@jdahm
Copy link
Author

jdahm commented Feb 29, 2016

I'm having a hard time setting counsel-git-grep-cmd' andcounsel-git-grep-history' to a locally-installed git version to test this. I tried using both setq' andsetq-default' and initially in the buffer when I use C-h v' it shows the correct (modified) path to git, but after executingcounsel-git-grep' I check again and it says the variable is the default. I've even gone into the package itself and changed the variable, but somehow it is getting reset.

I'm using this:

(use-package swiper
  :ensure t
  :init (ivy-mode 1)
  :diminish ivy-mode
  :bind (("C-S-s" . swiper)
         ("C-c C-r" . ivy-resume)
         ("<f6>" . ivy-resume)
         ("M-x" . counsel-M-x)
         ("C-x C-f" . counsel-find-file)
         ("<f1> f" . counsel-describe-function)
         ("<f1> v" . counsel-describe-variable)
         ("<f1> l" . counsel-load-library)
         ("<f2> i" . counsel-info-lookup-symbol)
         ("<f2> u" . counsel-unicode-char)
         ("C-c g" . counsel-git)
         ("C-c j" . counsel-git-grep)
         ("C-x l" . counsel-locate))
  :config
  (csetq ivy-use-virtual-buffers t)
  (use-package counsel
    :ensure t
    :config
    (setq-default counsel-git-grep-cmd "/home/jdahm/src/git/git --no-pager grep --full-name -n --no-color -i -e %S")
    (setq-default counsel-git-grep-cmd-history "/home/jdahm/src/git/git --no-pager grep --full-name -n --no-color -i -e %S")))

@abo-abo
Copy link
Owner

abo-abo commented Feb 29, 2016

(csetq ivy-use-virtual-buffers t)

Looks like the csetq macro from my config. It's not standard, check if you actually have that defined.

(setq-default counsel-git-grep-cmd "/home/jdahm/src/git/git --no-pager grep --full-name -n --no-color -i -e %S")

A plain setq should suffice here. But I see now that this variable is reset to "git --no-pager grep --full-name -n --no-color -i -e %S" in the interactive spec. Try to modify it in the source and use eval-defun to reload.

(setq-default counsel-git-grep-cmd-history "/home/jdahm/src/git/git --no-pager grep --full-name -n --no-color -i -e %S"))

No need to set this manually. This is simply the initial history for C-u counsel-git-grep.

@jdahm
Copy link
Author

jdahm commented Feb 29, 2016

Thanks for the quick reply. Even after a few years with Emacs I'm not an expert, and always looking to learn tips.

Looks like the csetq macro from my config. It's not standard, check if you actually have that defined.

I got the idea from your config, but for now I'm using

(defmacro csetq (var val)
  "Call `customize-set-variable' to set VAR to VAL."
  `(funcall 'customize-set-variable ',var ,val))

The idea was something like customize-setq to use the customize interface instead of directly `set-variable'. On a related note, I'm still not sure the best way to deal with the defcustom vs defvar issues, but we should discuss that another time.

Here's what I ended up using to debug:

(defun my-counsel-git-grep ()
  (interactive)
  (counsel-git-grep "/home/jdahm/src/git/git --no-pager grep --full-name -n --no-color -i -e %S"))

Executing M-x my-counsel-git-grep' followed byM-n' still doesn't show any matches.

@jdahm
Copy link
Author

jdahm commented Mar 1, 2016

Seems to not even work on the command line:

$ ~/src/git/git --no-pager grep --full-name -n --no-color -i -e \_<String\_>
-bash: syntax error near unexpected token `newline'

I tried wrapping \_<String\_> with quotes, but nothing matches.

@abo-abo
Copy link
Owner

abo-abo commented Mar 1, 2016

Try wrapping it with single quotes. You see, \_<String\_> serves an important cause: it matches symbol bounds, so e.g. it would not match StringBuilder, although \bString\b would. So it makes sense for git grep to support it.

@jdahm
Copy link
Author

jdahm commented Mar 1, 2016

I tried that, and then it matches nothing in the code, even when there is a clear 'String' in the code with spaces on either side.

I can just remove them by default, or hit `M-n' again. However, I'd like to understand how this is supposed to work, and how I'm either misunderstanding it or using it incorrectly. Can you give me an example where it will definitely give a match? Is there a page somewhere that explains the regexp? Thanks again for the help.

@abo-abo abo-abo closed this as completed in 8f527d7 Mar 1, 2016
@abo-abo
Copy link
Owner

abo-abo commented Mar 1, 2016

I've made a mistake checking counsel-git-grep in the swiper repository, which is small. counsel-git-grep has matching done entirely in Emacs for small repositories, that's why \_< was working for me. But for large repositories, the actual git grep is used, which does not at all recognize \_< - \b is basically the same to it, since it does not recognize programming languages.

The bug should be fixed now, thanks for reporting.

@jdahm
Copy link
Author

jdahm commented Mar 1, 2016

Excellent work!

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

No branches or pull requests

2 participants