A couple of issues regarding swiper-isearch-thing-at-point

[gusbrs]

I've been an user of swiper-isearch almost since it came about, and I really like it. However, I was frequently baffled by a somewhat mysterious behavior when navigating through swiper-isearch's history. But it was one of those things like "Damn! I should check lossage, but not now, later." And later never came, until a couple of days ago, and I decided to investigate.

It turns out that there are a couple of things in swiper-isearch-thing-at-point which were biting me there, and quite independent ones.

The first one is the binding which was chosen for it in swiper-isearch-map, M-n. In ivy-minibuffer-map, M-n is bound to ivy-next-history-element which pairs with M-p for ivy-previous-history-element. So that, when in swiper-isearch not only is the pairing symmetry lost, but there is no binding for ivy-next-history-element. Hence, if you go some steps trough the history in swiper-isearch there is actually no way to navigate back.

This problem is made even more baffling when coupled with the second one. swiper-isearch-thing-at-point gets the "thing-at-point", inserts it into the mini-buffer, alongside with any input which was already there and, finally, adds the symbol wrappers around the whole thing. In other words, the problem is that care is not taken to replace the previous input with "thing-at-point". So that if you hit M-n a number of times (which you would do, if you were thinking in navigating back through history) you get a nice Frankenstein of an input there. Only remedy, C-g and start all over.

To reproduce, start emacs -Q (I'm running the latest Emacs 27.2 here), then:

(add-to-list 'load-path "~/.emacs.d/elpa/ivy-20210404.1241")
(add-to-list 'load-path "~/.emacs.d/elpa/swiper-20210404.1302")
(load "swiper.el" nil t t)
(ivy-mode)

M-x find-library RET ivy RET. Now call swiper-isearch. To illustrate the second issue by itself, type "xyz" as input, and then hit M-n for swiper-isearch-thing-at-point. The result will be somewhat random, as point will have moved while typing. But I get here \_<xyzlexical-binding:\_>, which shows the problem.

To illustrate the interaction between the two problems C-g, call swiper-isearch again, hit M-p a number of times, and then try to navigate back history with M-n. The result will not be the same, as it will depend on the current state of swiper-isearch history, but I got here: \_<\_<\_<\_<\_<test:test\_>:test\_>:test\_>:test\_>:test\_>.

I've rebound M-n to ivy-next-history-element in swiper-isearch-map, and it was such a relieve. "thing-at-point" will still sort of work by means of the "future-history" of next-history-element. Though, true, without the symbol wrappers.

So, please consider restoring the M-n-M-p symmetry in swiper-isearch-map. And, I do get the interest in swiper-isearch-thing-at-point, but care should be taken it does not construct the symbol by joining previous mini-buffer content with "thing-at-point".

[jjnilton]

I'm having a similar issue too. When I want to search a word at point, I tried to use C-s M-n and got the word like \_<this\_>. This does seem to happen when I'm using lsp-mode, though, and the word is recognized by the language server as something it can jump to.

I think I'll just key bind swiper-isearch-thing-at-point for now.

Did you find a workaround?

[P233]

I have the same issue. It seems next-history-element works in all counsel functions, but not swiper.

[gtms]

There is an unfortunate choice of default bindings in swiper-isearch-map.

This should fix it:

(define-key swiper-isearch-map (kbd "M-n") 'next-history-element)
(define-key swiper-isearch-map (kbd ".") 'swiper-thing-at-point)