Closed kevinkwl closed 5 years ago
same problem here. it started yesterday.
i have the same help-swoop version as kevinkwl on linux with emacs 27.0.50.
Same here:
Emacs 26.0.90 helm 20180119.1053 helm-core 20180121.1022 helm-swoop 20170923.2127
Given the lack of change in swoop over the weekend I guess this is something that has changed in helm that has broken helm-swoop.
I can confirm that it is Helm. Helm from melpa stable with the latest snapshot of helm-swoop runs just fine!
Same here. It began yesterday.
Emacs 25.3.1 helm-20180119.1053 helm-core-20180122.706 helm-swoop-20170923.2127
Ditto.
Emacs 25.2.1 helm-20180119.1053 helm-core-20180122.706 helm-swoop-20170923.2127
fwiw, this is what the debugger comes up with... looks like a change to a function definition but my knowledge is then exhausted:
`Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 2)
helm-display-buffer("Helm Swoop" nil) helm-internal(((name . "scratch") (candidates [i have deleted lots of output. jack]:candidate-number-limit 19999) helm-swoop() funcall-interactively(helm-swoop) call-interactively(helm-swoop nil nil) command-execute(helm-swoop) `
Same here:
Same here, broken since the new helm update.
@it3ration @twlz0ne @jack99999 can you try @jguenther's patch in PR #124
the patch is working for me. (1 min testing). thanks
@stsquad The patch works for me as well. Thanks.
@ShingoFukuyama apply the patch please.
Patch works fine for me as well
Does @ShingoFukuyama still maintain this package? Curious how we can get this patch into melpa, I rely on use-package
mostly.
His last commit on GitHub was in early October. Tough to tell. Someone might have to fork it 🤔
Patch confirmed working here as well.
The patch does work. However, it's highly doubted that if the author is still maintaining this, after a long while. it would be nice if someone can fork it and publish it to melpa.
I agree with @HuStmpHrrr, it doesn't seem to be actively maintained, I hate to manually require helm-swoop
from a git repo ..
@it3ration it's quite easy using quelpa (package on melpa), for example:
(quelpa '(pkg-name :fetcher github :repo "user/repo"))
(require 'pkg-name)
I do not think it's the problem of obtaining this particular fix or not. It's a matter of whether the tool is maintained.
This particular incident is in fact caused by a helm update, not a problem from helm-swoop side. Since helm is for sure actively maintained, it's almost certain that in the future, interface changes like this will happen, or even deprecations. at that time, there needs to be someone who knows the code well enough to do corresponding changes and makes it published to melpa. This is very unfortunate, but unmaintained tool is very hard to live with, and even more unfortunately, this is a good tool.
@HuStmpHrrr I just couldn't agree more. I don't know if I can live without helm-swoop. Swiper seems so much slower, contrary to what people say.
@ShingoFukuyama the patch works well. helm-swoop is important tool for me. please apply melpa.
Seems like someone's going to have to fork this project and maintain it which is unfortunate. I'd volunteer but I'm starting a new gig and don't have the time.
Pity, helm-swoop is an essential package for me too. Maybe a contributor from helm/helm-core can adopt it?
It is actually a good idea to merge swoop into helm core
I second this.
Does anyone know the helm
maintainer? Perhaps we could implement a version of this natively into helm
..
I asked. and obviously Thierry does not like the idea.
How are you guys using this when you clone it locally? Can you still use use-package
?
@it3ration you can reuse the one from melpa. you can do the following:
M-x byte-recompile-file
and recompile that particular file.@HuStmpHrrr thanks for this, hopefully it gets pulled into main at some point. or someone creates a version of it that's >= in terms of functionality ..
What is the recommended way to apply patch #124?
@dylan-conlin you can do it in many ways.
you can either
just remember to run recompile to make sure emacs loads the right code.
Any follow up ? Issue was reported 21 days ago... Patch is not yet in Melpa right, otherwise it would work for me?
After reading the comment of thierryvolpiatto, I realized that helm-occur, with minimal tweaking, does indeed do the same thing. So exploring this might be an alternative. I thought that I would do this as a temporary fix, but am now so happy that I have settled on it. Searching of special characters is much more consistant than helm-swoop and with the following options, it looks just as good.
I realized that helm-occur, with minimal tweaking, does indeed do the same thing
AFAICS, helm-occur
doesn't provide the nice helm-swoop
's feature that the original buffer's cursor is jumping line to line according to moving up and down the line list. Did I miss something?
@prosoitos do you mind sharing some tweaks you were referring to?
@dbitouze AFAIK, you can press C-c C-f
in a helm-occur window to achieve that behavior. more operations can be seen by doing C-h m
.
@HuStmpHrrr Indeed, C-c C-f does the trick but AFAICS, it is much slower than helm-swoop
to jump from line to line in the original buffer.
With (setq helm-follow-mode-persistent t) helm-occur almost does the same thing, thanks for mentioning it!
Btw. without setting the helm-follow-mode-persistent to non-nil one can still jump around the results by holding ctrl while going through results just like in helm-mini etc.
However, helm-occur seems to ignore mark and fetch only the word which is below the cursor. I find it kind of annoying but still much better than ivy-swiper IMHO.
Maybe helm maintainers can cherry pick good design decisions from helm-swoop and "improve" helm-occur? I also like the helm-swoop formatting more.
You can set it in more subtle ways, so that helm only follows in occur. See for instance the 2nd answer of https://emacs.stackexchange.com/questions/2563/helm-search-within-buffer-feature:
(require 'helm-config)
(defvar my-helm-follow-sources ()
"List of sources for which helm-follow-mode should be enabled")
;; Use helm-follow-mode for the following sources:
(add-to-list 'my-helm-follow-sources 'helm-source-occur)
(defun my-helm-set-follow ()
"Enable helm-follow-mode for the sources specified in the list
variable `my-helm-follow-sources'. This function is meant to
be run during `helm-initialize' and should be added to the hook
`helm-before-initialize-hook'."
(mapc (lambda (source)
(when (memq source my-helm-follow-sources)
(helm-attrset 'follow 1 (symbol-value source))))
helm-sources))
;; Add hook to enable helm-follow mode for specified helm
(add-hook 'helm-before-initialize-hook 'my-helm-set-follow)
Making the formatting looks like helm-swoop is also easy by playing with a few of the helm faces.
And, honestly, as much as I loved helm-swoop until this happened, I have now realized that thierryvolpiatto is right and helm-occur is MUCH faster. On large files, it is really obvious. So in the end, I am actually really happy with the swap and let go of helm-swoop.
I spent a few days following this thread, eager to see the patch applied. But after I set helm-occur to behave as I wanted (and working even better than helm-swoop), I felt really happy. So I thought that I would mention it here, so that others who are still hoping for helm-swoop to be rescued can try this and see if it works for them.
@prosoitos Thank you for rescuing me! This works perfectly for me.
@prosoitos I applied this patch for helm-swoop
and what you suggest for helm-occur
. The former is still much smoother and faster than the latter, e.g. on a 300K .tex
file (with 11270 lines).
Is there some way to control how helm-occur
splits the window? I always had helm-swoop
pop up to the right of my current window, not on the bottom. Also curious if anyone has found a way to wrap around once you reach the top / bottom.
With respect, I can't help but think that the solution(s) posted by @prosoitos are not exactly straightforward .. am I crazy?
(setq helm-split-window-default-side (quote right))
(Explore all the helm customisations (lots of them...) to make it look however you want. Mine looks exactly the way helm-swoop did).
Helm-occur is faster in my setup and for my usage. And it searches for special characters predictably. So it works great for me. Now, if that doesn't work for you, sorry about that. I was just trying to help.
Hey @prosoitos, thanks for the response, I wasn't trying to criticize, it's my fault for not understanding helm
's internals. :)
Any idea how to control the helm buffer location for just helm-occur
? helm-swoop
opens the filtered results buffer to the left or right of the current buffer for me, whichever is the opposite of the current buffer.
On an unrelated note, do you know much about helm-attrset
? I'm curious what else you can customize.
(setq helm-move-to-line-cycle-in-source t)
for the "wrap around".
No offence. I was just trying to suggest exploring helm's capacities and options further since I was inspired by this post emacs-helm/helm#1966 to do so myself, which allowed me to realize that helm-occur can do everything I wanted and more.
I don't think that there is a pre-written option to change the window configuration just for helm-occur. But you could easily do that with popwin.. Or write a function for helm-split-window-preferred-function
.
Anyway, I am stepping out of this thread as we are really moving off topic.
@it3ration If you do M-x customize-group Ret helm Ret
you will be able to explore and play with the regular options. And of course, you can always write functions to tweak things beyond that. Good luck!
Here is a screencast which shows helm-swoop
is still much smoother and faster than the helm-occur
, e.g. on a 300K .tex file (with 11270 lines).
One can also see that helm-swoop
displays the comments as in the original buffer.
macOS 10.13.1, emacs 25.3
helm-swoop does not work. Here's my config:
helm version: