How does it compare to helm-swoop ?

[abo-abo]

How does it compare to helm-swoop ?

[abo-abo]

• it's more pretty, using my definition of pretty
• it's more usable, using my definition of usable
• it's more simple, using my definition of simple

Both packages set out to accomplish the same task, so they can't be too different.
You can use either one as a matter of taste.

The plan is to provide a back end similar to ido eventually. Helm is used initially to get a
reference implementation.

[syl20bnr]

That's fine with me but I hoped for something more constructive. I don't see much difference in "prettyness" between the 2 packages, faces are customizable.

Do you plan to add editing feature and multi buffer search ?

There is also another implementation of helm-swoop without helm [1] which might be interesting for you.

[1] https://github.com/ShingoFukuyama/emacs-swoop

[abo-abo]

That's fine with me but I hoped for something more constructive. I don't see much difference in
"prettyness" between the 2 packages, faces are customizable.

Just try completing words separated by spaces with both packages, you'll see the difference: it's
totally unrelated to faces color. The matching is different as well.

Do you plan to add editing feature and multi buffer search ?

I'm not currently interested in that, I just want a re-search-forward replacement.

There is also another implementation of helm-swoop without helm [1] which might be interesting for you.

[1] https://github.com/ShingoFukuyama/emacs-swoop

Thanks, I saw this link earlier today. It looks to me like helm-swoop is a straight upgrade over
emacs-swoop. I'm looking at ido to get something less obtrusive than helm.

[syl20bnr]

@abo-abo helm-swoop is not an upgrade, emacs-swoop is a rewrite of helm-swoop without helm, but as you see the helm variant is the more popular one, although emacs-swoop has cool unique features.

Reference: emacsorphanage/swoop#3

Since you already have multiple backend I would suggest to put helm in front and then in a second README section you can introduce ivy (which must be fully optional). This is a better strategy for adoption but as all my advices are **** for you... ;-)

[abo-abo]

Since you already have multiple backend I would suggest to put helm in front and then in a second
README section you can introduce ivy (which must be fully optional).

I want to downplay the helm back end eventually. The only reason why it's the default currently is
that the ivy part of swiper isn't completed yet.

swiper's key point will be unobtrusiveness, and that can only be done with ivy (maybe also ido
with ido-vertical, but it's hard to make ido work with swiper).

Unobtrusiveness is that both helm-swoop and swoop don't have.

This is a better strategy for adoption but as all my advices are **** for you... ;-)

Well, there hasn't been any good ones yet. But keep trying, if you like.

[syl20bnr]

That's ok with me, I truly think that there is benefit at some point in all advices, be good or bad.

Don't be mistaken, Helm can be unobtrusive, it is just a matter of configuration and in your case for swiper it is just a matter of documentation. There is a great benefit to have a whole configuration consistently relying on Helm instead of several different interfaces, users like consistency a lot. Helm is one of the most powerful package on MELPA, don't downplay it.

[abo-abo]

Helm is one of the most powerful package on MELPA, don't downplay it.

Helm is only a package for completion, just like ido or ivy. It
may be easy to use, once someone has gone through the trouble of
setting it up, but it's hard to get it to do exactly what you want.
Some people are fine with black boxes, as long as they give them nice
things, I'm not.