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-ag + wgrep not working (No changes to be performed) #1841
Comments
Could this be related to #1813? Are you sure you have the latest version of |
Yup, the version numbers in my So, in the broken setup I've found in (defun ivy--occur-insert-lines (cands)
"Insert CANDS into `ivy-occur' buffer."
(font-lock-mode -1)
(dolist (str cands)
(setq str (ivy--highlight-fuzzy (copy-sequence str)))
(add-text-properties
0 (length str)
'(mouse-face
highlight
help-echo "mouse-1: call ivy-action")
str)
(insert (if (string-match-p "\\`.[/\\]" str) "" " ") ;; THIS LINE!
str ?\n))
<snip> Which checks to see if the file path begins with When I have some time I can dig in more to try and identify the root cause. It's really bizarre how two setups that supposedly have the same versions have different behaviour :/ |
That they are the same does not mean they are the latest.
Thanks, please do.
What is their full M-x |
Did some more investigation and I think I found the root of the problem. First some preamble:
Both the same,
Nope, both:
Same output:
The Problem So, I discovered that the working setup was using an older version of the code. Specifically, this is the implementation of (defun ivy--occur-insert-lines (cands)
"Insert CANDS into `ivy-occur' buffer."
(dolist (str cands)
(add-text-properties
0 (length str)
`(mouse-face
highlight
help-echo "mouse-1: call ivy-action")
str)
(insert str "\n"))
(goto-char (point-min))
(forward-line 4)) Notice how it always insert the string starting from column 0. Now, the broken setup uses the HEAD version:
Which has the check:
In other words, if the candidate (aka. matching file+content) starts with a So, either Edit: The specific command that
This above output is what appears to be passed to the function |
The cause is that in that case, ./ should be prepended. I'll take a look later today. |
Yup, that looks like the culprit, thanks! |
Thanks, please test. |
1 similar comment
Thanks, please test. |
Don't you want to modify the candidates list to prepend ./ if not present? |
@mookid I think it's up to |
@abo-abo I'm not familiar with the |
Verified that |
Not directly related to this, but may be too heavyweight for a new issue, I noticed that when using Edit: In other words, I always want |
MELPA automatically gets updated from |
@basil-conto Hmm, I just checked https://melpa.org/#/?q=swiper and it still says that |
@m-renaud Like I said, if it's not updated yet, it will be relatively soon - MELPA only updates a couple of times per day or so. If you look at the notice on its homepage https://melpa.org, you will see the next build isn't for another 3 hours from the time of writing. |
@basil-conto ah I see, I was confused because there are commits from yesterday which haven't been rebuilt, so maybe its not "every few hours" but "every few days" :) Edit: It appears the last build "took 16 hours and ended 9 hours ago", and with 1 hour until the next build it seems like the schedule is every ~26 hours. Sorry for all the noise, I wasn't familiar with the Melpa release schedule, thanks for enlightening me :) |
Is anyone else having this issue again? My files won't update when using counsel-ag and wgrep but it used to work fine. It says also the wgrep buffer was modified at the end. I also tried using the helm-wgrep package so maybe it is an issue with wgrep, not something in the counsel or swiper. |
@JSpenced I just checked with |
@abo-abo Just updated all packages and tried again with git-grep and counsel-ag. Wgrep seemed to be working fine with both. Not sure the issue before but thanks |
Thanks for checking. |
Overview
I have two machines, both running Debian and emacs v26.1, with the same
counsel
,swiper
,wgep
, andwgrep-ag
packages installed. On one of them the workflow:counsel-ag
,ivy-occur
,ivy-wgrep-change-to-wgrep-mode
works perfectly fine. I can edit the occur buffer then pressC-x C-s
to save and everything is updated properly. On the other, the occur buffer looks slightly different and when I try to save it says (No changes to be performed).Strangely, for the working setup,
ivy
is not installed according the package manager, on the broken one it is (as a dependency of swiper), I'm not sure how this happened.Occur buffer
Working:
Broken:
Ivy version:
ivy-20181129.2105
The format in the broken one is different that the first which is (I assume) the problem. I'm confused because I've verified that the versions of the installed packages are the same (other than the missing ivy dependency on the working setup).
What I've tried
Uninstall and re-install
remove .elc files
Removed all relevant .elc files in case there was some compile incompatibility
Edit: Summary of thread for future readers
The root cause of the issue is
ivy--occur-insert-lines
is adding leading spaces before the candidate matches when creating theivy-occur
buffer when the candidate string does not start with a.
(which it does not forag v2.1.0
.wgrep
requires that all candidates start at column 0 of the line.The text was updated successfully, but these errors were encountered: