Changes are not applied when using (wgrep-finish-edit) function. #36
Comments
|
This have been fixed in 83674b3. |
|
all are updated, reinstalled yet to no avail. Any further help would be much appreciated! |
|
here is the output of Edebug step-by-step debugging of |
|
doctorate75 <notifications@github.com> writes:
all are updated, reinstalled yet to no avail.
Yes, perhaps but be sure to reinstall helm first, restart emacs and then
reinstall wgrep, otherwise if you did it in the other sens wgrep is
compiled with the old helm.
I red again your report on stack exchange it is really the same bug I
fixed some time ago (due to incompatible changes in helm, sorry).
With the good install I can't reproduce.
The reason is before I was getting the file names from help-echo
property and now I get them from helm-grep-fname property so wgrep
must do the same.
Also be sure when you reinstall to compile from outside emacs and
restart emacs.
Try this and let me know if you stiil have the issue.
Thanks.
…--
Thierry
Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997
|
|
I don't know how to reinstall I rely solely on |
|
doctorate75 <notifications@github.com> writes:
I don't know how to reinstall helm from outside emacs (clone of
githubt) without breaking org-ref stuff, at restart emacs complains
that org-ref needs helm<5.5.1> version which I removed form the elpa
folder.
This confirm that you just have to cleanup your package installation to
make all working properly.
Your problem is you have compiled a recent version of a package (wgrep)
with a old version of helm and now the compiled code cannot work
properly, so you have recompile wgrep with the corresponding new helm code.
You don't have to build helm from git, just use package.el.
1) Reinstall helm.
2) Restart emacs.
3) Reinstall wgrep.
4) Restart emacs.
I rely solely on package.el management system, except for org from
github and with loaded path. Some recommend using el-get.el, others
second cask.
No I even don't know how to use these tool, use package.el or
installation from git.
…--
Thierry
Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997
|
|
It didn't work either. I did the following: From inside Emacs |
|
doctorate75 <notifications@github.com> writes:
It didn't work too. I did the following:
From inside Emacs M-x package-list-packages, I deleted all three helm, wgrep and wgrep-helm by pressing D and then x to delete them from within the packages buffer.
However, for helm package I could not delete it completely as others, it changes status from installed to dependency and I don't know which dependence is that.
Restarted Emacs,
Installed helm shown as dependency, and changed to installed by pressing I and then x to execute installation.
Restarted Emacs
Reinstalled wgrep and wgrep-helm together, again by pressing I and then x.
Restarted Emacs.
The same problem remains. What do I miss here? thanks.
Same you are still using old helm compiled files not compatible with new
wgrep.
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.*
--
Thierry
Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997
|
|
so what do I need to do in order to get rid of the old one without breaking setup code? I think here is the real issue. |
|
doctorate75 <notifications@github.com> writes:
so what do I need to do in order to get rid of the old one? I think
this is the culprit right now.
Uninstall all packages that requires helm, then uninstall helm and
reinstall it, restart emacs and reinstall all the packages you have
uninstalled one by one.
BTW Once helm is installed I suggest to use M-x helm-list-elisp-packages
to manage your packages.
…--
Thierry
Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997
|
|
The linked issue on the first message no longer works (please, people, provide proper bug reports instead of a link) but I must mention that I don't use helm and too often wgrep does not apply all the changes. I operate on buffers produced by |
|
Make sure buffer is not read-only (if so customize wgrep change read-only flag), and also file is not write-protected (file mode). |
|
I'm having the same problem operating on |
|
Ah, I think I see what's going on -- ag uses Note the |
|
Answer: use the |
|
Another cause of the edits failing to be applied is when helm presents the "file name" as the uniquified buffer name. The uniquified file name cannot be found in default directory, so wgrep cannot apply the change. Workarounds:
|
^ I just encountered a case similar to this. I have a buffer "log" and another "log.org", changes cannot be applied to "log", when I close the "log.org", it works fine. I wonder why wgrep just look at the file name without extension? |
|
In my case after pressing ZZ I'd get the message 'There are 34 unapplied changes. (0 changed)' and the files in the wgrep buffer would turn red/orange. Also many autosave (#.) files would appear in magit status as untracked. Then I tried M-x |
|
I am experiencing this as well. In my case, I collect the search results via I suspect that it is related to the file extension or the major mode (or something else that correlates with a file extension) since I recently performed a massive search and replace involving over 2000 replacements and the few failures all involved
|
|
I traced back the issue to (defun wgrep-apply-change (marker old new)
"The changes in the *grep* buffer are applied to the file.
NEW may be nil this means deleting whole line."
(let ((coding buffer-file-coding-system))
(goto-char marker)
;; check BOM
(when (and (= (point-min-marker) marker)
coding
(coding-system-get coding :bom))
(setq old (wgrep-string-replace-bom old coding))
(when new
(setq new (wgrep-string-replace-bom new coding))))
;; Check buffer line was modified after execute grep.
(unless (string= old
(buffer-substring-no-properties
(line-beginning-position) (line-end-position)))
(signal 'wgrep-error (list "Buffer was changed after grep.")))
(cond
(new
(wgrep-replace-to-new-line new))
(t
;; new nil means flush whole line.
(wgrep-flush-whole-line)
))))The check Here is a concrete, reproducible example:
The two values should be equal, but they are not. This is the source of the error. Not sure why this is happening—perhaps someone with better Elisp skills than I have can figure it out? |
benthamite
added a commit
to benthamite/dotfiles
that referenced
this issue
May 28, 2024
consult-ripgrep + wgrep is faster than elgrep, but wgrep has a bug that sometimes causes changes not to be applied: mhayashi1120/Emacs-wgrep#36 Since this has been going on for years, it seems unlikely it will be fixed any time soon. So I'm going back to elgrep for now.
benthamite
added a commit
to benthamite/dotfiles
that referenced
this issue
Jun 5, 2024
consult-ripgrep + wgrep is faster than elgrep, but wgrep has a bug that sometimes causes changes not to be applied: mhayashi1120/Emacs-wgrep#36 Since this has been going on for years, it seems unlikely it will be fixed any time soon. So I'm going back to elgrep for now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the issue is reported here in this post link below:
https://emacs.stackexchange.com/q/33375/2443
help please.
The text was updated successfully, but these errors were encountered: