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

Completion in minibuffer: Making inhibit-read-only local to *helm-mode-completion-at-point* while let-bound! #4224

Closed
synic opened this issue Dec 18, 2015 · 13 comments
Labels
Helm Question stale marked as a stale issue/pr (usually by a bot)

Comments

@synic
Copy link
Contributor

synic commented Dec 18, 2015

I often open up spacemacs and type :e ~/Pro[tab] to open a file. Tab completion is hard to see because that message pops up, obscuring the completion.

How can I make that stop?

System Info

  • OS: darwin
  • Emacs: 24.5.7
  • Spacemacs: 0.105.0
  • Spacemacs branch: develop (rev. 03c83e1)
  • Distribution: spacemacs
  • Layers:
(unscroll auto-completion xkcd emacs-lisp git dash yaml github javascript html markdown extra-langs python ruby org osx python django syntax-checking spell-checking version-control lua colors spacemacs-layouts vimscript
          (c-c++ :variables c-c++-enable-clang-support t)
          (shell :variables shell-default-height 30 shell-default-position 'bottom))
@StreakyCobra
Copy link
Contributor

It would help us to help you if you can provide some more details :-) Have a look here.

@justbur
Copy link
Contributor

justbur commented Dec 18, 2015

I believe this happens when you try to do tab completion while helm is loading which happens on about a 1 second delay

@synic
Copy link
Contributor Author

synic commented Dec 18, 2015

It's not while it's loading, I can wait on the home screen forever and it will still happen, however, it appears to only happen the first time.

Is there a way do non-helm-completion in the minibuffer? if I type e: ~/Pro[tab], it would guess first ~/Projects, but if I hit tab again, it just brings up the next possible match without helm? ~/Products?

@justbur
Copy link
Contributor

justbur commented Dec 18, 2015

To clarify, I believe the problem occurs if you execute a command that
enters the minibuffer before helm is loaded. I think if you wait until helm
loads before entering :e you will not see the behavior. Is that correct?

On Fri, Dec 18, 2015 at 4:35 PM Adam Olsen notifications@github.com wrote:

It's not while it's loading, I can wait on the home screen forever and it
will still happen, however, it appears to only happen the first time.

Is there a way do non-helm-completion in the minibuffer? if I type e:
/Pro[tab], it would guess first/Projects, but if I hit tab again, it
just brings up the next possible match without helm?~/Products`?


Reply to this email directly or view it on GitHub
#4224 (comment)
.

@synic
Copy link
Contributor Author

synic commented Dec 20, 2015

I can wait as long as I want. It will still happen. But only the first time.

@justbur
Copy link
Contributor

justbur commented Dec 20, 2015

Here's a more direct test. Comment out this line, restart and see if you can reproduce it

@StreakyCobra
Copy link
Contributor

@justbur I think your link is (already) outdated. You should link to a specific commit version (pressing y on the github page helps, IIRC)

@justbur
Copy link
Contributor

justbur commented Dec 21, 2015

Actually I can reproduce this even if helm is not deferred, so I was wrong about that

@puyo
Copy link

puyo commented Jun 18, 2016

I was seeing this issue this morning, then Spacemacs seemed to update to v.0.105.21 and now the issue seems to have gone away.

@hansent
Copy link

hansent commented Aug 8, 2016

@synic did you figure out a workaround for this?

@whogotpwned
Copy link

@synic @hansent Yeah I am interested too. That's really annoying and I lose about 2 seconds each time this pops up 😦

@xguerin
Copy link

xguerin commented Sep 22, 2016

@synic @hansent I am interested as well.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Helm Question stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

7 participants