[improvement request] async version of `swiper` (i.e. `swiper-all` for a single buffer with start at point)

[kurt-hesselbart]

Using swiper on lines with multiple occurrences of the candidates isn't as expedient as one could wish. (For me, it seems to be pretty unpredictably, at which occurrence the point will be moved to.)

Using swiper-all instead helps alot finding (and navigate to) the correct candidate. If I understand correctly this happens (only) because of swiper-all's async properties.

But using swiper-all as replacement for swiper isn't fully satisfying, since swiper-all doesn't start searching at point (it starts at point-min) and searches needlessly beyond the current buffer.

So I'm not sure, if it would be easier to modify swiper-all to provide the missing features or to produce a distinct async version of swiper.

[LuhengStat]

I think may be you are looking for counsel-projectile-rg (or ag) function with the aid of projectile package and counsel-projectile, which can search results in a project.

[kurt-hesselbart]

@LuhengStat

I think may be you are looking for counsel-projectile-rg (or ag) function with the aid of projectile package and counsel-projectile, which can search results in a project.

I fear I failed totally explaining my thoughts or I misunderstood your reply.

I thought I was talking about the possibility to have some advantages of swiper-all for the standard swiper command. And I want it only for the current buffer. I can't see how rg or ag could help here, since I want to work with buffers but not with files (rg and ag and grep as well, they all search in the files, but not in the buffers, so one has to make sure to save first). That's another reason why swiper-all isn't the best replacement, since it doesn't search in fileless buffers, like scratch.

Perhaps an example helps me to tell my major point. We have the following line:

»Foo bar their baz while foo bar at our baz of the foo with some bars at my baz.«

Now using swiper with »baz« gives only one candidate and I think it doesn't always jump predictable to the first occurrence (after »their baz«). But swiper-all here gives us all there occurrences as candidates and choosing the last one results in jumping to the correct position (right after »my baz«).

But the disadvantages are a) start searching at (point-min) not at (point), searching only in buffers related to a file and searches unnecessary in more than only the current buffer.

Btw, does anyone know how to remove a »thumbs up« vote. I tried to get information about the person who voted for my comment, but accidentally voted also with a thumb up. Can I revert it?

[basil-conto]

@kurt-hesselbart

Btw, does anyone know how to remove a »thumbs up« vote. I tried to get information about the person who voted for my comment, but accidentally voted also with a thumb up. Can I revert it?

You can remove your own reactions by just clicking on them.

[kurt-hesselbart]

@basil-conto

You can remove your own reactions by just clicking on them.

Thank you very much, I lacked the courage to click again.

[abo-abo]

Foo bar their baz while foo bar at our baz of the foo with some bars at my baz.

I'm thinking if there's a place for improvement here, wrt what gets shown in the minibuffer. Right now, swiper-all with input foo will correctly cycle through the 3 matches on the line. But what gets shown in the minibuffer is messy because everything is highlighted. Moreover, since the search is no longer line based, does it still make sense to show the full line of context? Maybe just a few chars around the match would suffice?

[kurt-hesselbart]

@abo-abo

I'm thinking if there's a place for improvement here, wrt what gets shown in the minibuffer.

I'm very sorry, but I can't understand why only the minibuffer representation is seen as the problem.

I updated my packages today, so I'm not sure if it results from an already done enhancement, but here, highlighting works very well.

Anyway, perhaps an example can help here?

As one can see, swiper does it (totally) wrong, It only shows three (instead of six) occurences and at a line of three occurrences it jumps to the second one. Did we expect so?

On the other hand swiper of course starts only after inserting the third char but then gave us a pretty result: all six occurrences and all six can be reached reliable.

But in fact, the minibuffer representation differs. I'm quite sure, that there are good reasons for both: showing only some characters around the searched item or showing the full line as swiper does. (I would prefer an option).

Anyway, I wouldn't agree, the perfect minibuffer representation is urgently needed.

I see, it wasn't a good idea to phrase such a vague request. Since I can't use swiper as a isearch replacement because of it's lack of reliable reaching to search item, I'll keep misusing swiper-all while surveying the disadvantages by doing so for only buffer wide searches.

Perhaps it's better to think about an stepwise transformation of swiper-all to swiper-async.

So the first step could be an ability to start searching at point (instead of point-min).