Skip to content
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

swiper-isearch starts at wrong hit when multiple hits on line #2025

Closed
Lenbok opened this issue Apr 14, 2019 · 3 comments
Closed

swiper-isearch starts at wrong hit when multiple hits on line #2025

Lenbok opened this issue Apr 14, 2019 · 3 comments

Comments

@Lenbok
Copy link

@Lenbok Lenbok commented Apr 14, 2019

I just started to use swiper-isearch and it's very nice. One minor problem I noticed is that when I invoke swiper-isearch starting on a line containing two occurrences of the search term, swiper initially matches the first occurrence of the match on the line, even if the initial invocation position was to the right of that first occurrence.

In my case, I had actually initiated the search from the second occurrence via swiper-isearch followed by ivy-yank-word, which made it even more jarring as I went to do ivy-yank-word a second time to further refine the search, but it pulled in the word following the first occurrence on the line, not the one I started from!

(In fact it has nothing to do with whether there are multiple occurrences on the line, swiper-isearch should just start from the next match if the initial invocation position is to the right of the first match on the line)

@Lenbok Lenbok changed the title swiper-isearch start at wrong hit when multiple hits on line swiper-isearch starts at wrong hit when multiple hits on line Apr 14, 2019
flatwhatson added a commit to flatwhatson/swiper that referenced this issue Apr 16, 2019
@flatwhatson
Copy link
Contributor

@flatwhatson flatwhatson commented Apr 16, 2019

I have included a fix in #2029

@abo-abo
Copy link
Owner

@abo-abo abo-abo commented May 7, 2019

OK, took me some minutes to figure out the reason why it works the way it does right now:

The original logic:

(setq swiper--isearch-point-history
        (list
         (cons "" (point))))

The current logic:

(setq swiper--isearch-point-history
        (list
         (cons "" (if executing-kbd-macro
                      (point)
                    (line-beginning-position)))))

Suppose we revert to the original logic. Move the point here:

(def|un swiper-isearch-action (x)

...

(defun swiper-isearch ...)

Press C-s M-n to search for symbol-at-point. The point will not stay at the current defun as expected, but will move to the next one. This is correct, but not convenient.

Maybe a better solution would be to modify only the M-n logic, and keep the original swiper--isearch-point-history logic.

@abo-abo abo-abo closed this in f628eb3 May 7, 2019
@abo-abo
Copy link
Owner

@abo-abo abo-abo commented May 7, 2019

Thanks, please test.

astoff added a commit to astoff/swiper that referenced this issue Jan 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants