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

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

Open
jojojames opened this issue Oct 3, 2018 · 15 comments
Open

Comments

@jojojames
Copy link
Contributor

jojojames commented Oct 3, 2018

;; 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
Copy link
Collaborator

basil-conto commented Oct 3, 2018

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
Copy link
Contributor Author

jojojames commented Oct 3, 2018

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
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Collaborator

What is your M-xemacs-versionRET?

@jojojames
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Contributor Author

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

@jojojames
Copy link
Contributor Author

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
Copy link
Contributor

edkolev commented Oct 16, 2018

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
Copy link
Owner

abo-abo commented Dec 12, 2018

Please test if the issue is still there.

@mookid
Copy link
Contributor

mookid commented Dec 13, 2018

I confirm it is still there.

@jojojames
Copy link
Contributor Author

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

@mookid
Copy link
Contributor

mookid commented Dec 18, 2018

I suggest closing this for now.

@abo-abo
Copy link
Owner

abo-abo commented Dec 18, 2018

@mookid OK, closing.

Thanks, all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants