Counsel wipes input (counsel-rg / counsel-fzf/ async counsel commands?)

[jojojames]

;; OSX

(setq package-enable-at-startup nil
      package-archives
      '(("melpa" . "http://melpa.milkbox.net/packages/")
        ("gnu" . "http://elpa.gnu.org/packages/")))

(require 'package)
(package-initialize)
(package-refresh-contents)
(package-install 'swiper)
(package-install 'ivy)
(package-install 'counsel)

M-x counsel-rg

Click window (e.g. *scratch* buffer) -> counsel-rg adds output to that window

This is a manual repro of output being added to another window other than the main ivy window. I've seen this happen even when I don't manually select a window sometimes (not all the times) with counsel-rg or counsel-fzf.

[basil-conto]

I'm sorry, but I don't think the description is clear enough.

counsel-rg adds output to that window

What output? Have you typed in a search string which resulted in search results, or are you referring to e.g. counsel-rg's 3 chars more prompt?

I've seen this happen even when I don't manually select a window sometimes (not all the times) with counsel-rg or `counsel-fzf.

Again, the precise set of steps and outcome are not clear. Can you please provide more details and/or screenshots/screencast?

For instance, here's what I did to try to reproduce this:

1. make plain.
2. M-xcounsel-fzfRET
   • List of 26 files under repo is displayed for completion, as expected
3. Click in *scratch* buffer
   • Minibuffer completion is unchanged, no text appears in *scratch*
4. C-xoivy
   • Completion is narrowed to files which include ivy in their name
5. Click in *scratch* buffer
   • Minibuffer completion is unchanged, no text appears in *scratch*

Here's a more programmatic example:

1. make plain

2. (progn (setq unread-command-events
               (listify-key-sequence "\C-xo"))
         (call-interactively #'counsel-fzf))

3. C-xC-e
   • Minibuffer completion starts, but no candidates are displayed yet (this could be considered a separate bug)
   • *scratch* is selected, but no additional text has been printed to it
4. C-xo
   • Minibuffer is selected and candidates are finally displayed

Replacing (listify-key-sequence "\C-xo") with something more elaborate like (listify-key-sequence "ivy\C-xo\C-xo") still works as expected.

Similarly, counsel-rg seems to behave as expected:

1. make plain
2. C-ck
   • Minibuffer completion starts and 3 chars more is displayed
3. Click in *scratch*
   • Minibuffer completion is unchanged, no text appears in *scratch*
4. C-xoivy
   • Completion is narrowed occurences of ivy
5. Click in *scratch* buffer
   • Minibuffer completion is unchanged, no text appears in *scratch*

And the same can be seen with e.g.

(progn (setq unread-command-events
             (listify-key-sequence "ivy\C-xo\C-xo"))
       (call-interactively #'counsel-rg))

So I don't exactly understand what the issue is, or how to reproduce it.

[jojojames]

What output? Have you typed in a search string which resulted in search results, or are you referring to e.g. counsel-rg's 3 chars more prompt?

Yes 'asdf' will do. Of course, the search string will be dependent on whatever your filesystem may look like.

Again, the precise set of steps and outcome are not clear.

It happens 'every so often' so I'm not going to be able to provide a list of steps for that case but I'd expect both cases to be symptomatic of the same issue.

Can you please provide more details and/or screenshots/screencast?

Yeah.

https://www.dropbox.com/s/zdojsha800quiw2/counsel_bug.mov?dl=0

[jojojames]

Again, the precise set of steps and outcome are not clear. Can you please provide more details and/or screenshots/screencast?

To clarify, for the second case, the outcome (the search result output of counsel-* being streamed to the selected-window/buffer) is the same as the first case, although I have no idea how to repro the second case.

[basil-conto]

Can you please provide more details and/or screenshots/screencast?

Yeah.

https://www.dropbox.com/s/zdojsha800quiw2/counsel_bug.mov?dl=0

Wow, I didn't expect such bad behaviour. :) This has never happened to me, and I'm worried it might be hard to debug. It may even be OS-specific. Any programmatic reproduction recipe you can come up with will prove very helpful.

Does the issue occur in the absence of other packages except Ivy/Swiper/Counsel? I.e. can you reproduce the issue from emacs -Q followed by manually loading only Ivy/Swiper/Counsel? If not, there may be some other package you have installed that is interfering.

[basil-conto]

What is your M-xemacs-versionRET?

[jojojames]

Happens on both:

GNU Emacs 26.1 (build 1, x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 10.10.5 (Build 14F2511)) of 2018-05-30

(Version of emacs -Q) GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29)) of 2018-08-09

I.e. can you reproduce the issue from emacs -Q followed by manually loading only Ivy/Swiper/Counsel?

The video/recipe is starting from emacs -Q.

[basil-conto]

The video/recipe is starting from emacs -Q.

But you call package-initialize, no? This will evaluate the autoloads of all installed third-party packages, potentially (even if only by a small chance) interfering with the recipe.

[jojojames]

That's a good point. I removed all my packages from my elpa directory and the problem persists.

[jojojames]

Extra datapoint: I tried going back in commit history to when counsel-rg was introduced and it still repros there so I don't think this is a regression. I believe it also repros on emacs 25 On MacOS Sierra.

I'm surprised no one else is seeing this on OSX!

[edkolev]

Another data point which could be related (I'm on OS X):

• counsel-rg and counsel-git-grep always show "0" results, no matter what you search for
• however, ivy-occur opens a buffer with the correct results (i.e. even though counsel-rg shows "0" results when searching for "ABC", pressing C-c C-o opens a buffer with all the lines in the project which have "ABC")

This issue isn't always reproducible, but once I get this issue, I can't get counsel-rg/counsel-git-grep to work again without restarting emacs.

[abo-abo]

Please test if the issue is still there.

[mookid]

I confirm it is still there.

[jojojames]

The repro steps here don't repro anymore for me but I trust @mookid 's judgement in #1857.

[mookid]

I suggest closing this for now.

[abo-abo]

@mookid OK, closing.

Thanks, all.