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

Entering normal-state should exit compaly tooltip #1097

Closed
luxbock opened this issue Apr 9, 2015 · 12 comments
Closed

Entering normal-state should exit compaly tooltip #1097

luxbock opened this issue Apr 9, 2015 · 12 comments
Labels
- Forum - Auto-completion Ready for work stale marked as a stale issue/pr (usually by a bot)

Comments

@luxbock
Copy link

luxbock commented Apr 9, 2015

I tried using:

(add-hook 'evil-normal-state-entry-hook 'company-pseudo-tooltip-hide)

to achieve this, but it doesn't appear to work. It's a rather minor annoyance of mine.

@syl20bnr
Copy link
Owner

Seems that not everybody gets this behavior. I get it but if I remove my layers it disappears.
@luxbock can you confirm that you don't have this behavior with a stock spacemacs config ?

@luxbock
Copy link
Author

luxbock commented Apr 27, 2015

Using master, if I remove all of my own configurations and leave only the auto-completion layer, then ESC does what I wish, i.e. goes to normal-state and disables the company popup, so yes I can confirm your finding.

I'm trying to investigate which setting it is that causes it, and have narrowed it down to my (eval-after-load 'evil ...) block in my dotspacemacs/config.

@luxbock
Copy link
Author

luxbock commented Apr 27, 2015

I have identified the culprit: (setq evil-move-cursor-back nil). Perhaps it's the same for you as well?

@CestDiego
Copy link
Contributor

@syl20bnr @luxbock I do exit company popup when I press (for example) nj which is my evil-escape key. BUT I'm back to insert mode. shouldn't it go to normal state? because If I wanted to modify sth in insert mode I shouldn't have to exit company tooltip, I'd just write more because for entering company popup you HAVE to be inserting text.

@TheBB
Copy link
Contributor

TheBB commented Oct 22, 2015

Status on this? Seems to work as expected for me.

@mmcnl
Copy link

mmcnl commented Oct 24, 2015

I can confirm that setting evil-move-cursor-back prevents exiting normal mode (either by the evil-escape sequence or C-[) from also closing the company tooltip.

(Thanks @luxbock for tracking the issue down to that setting -- I spent far too long trying unsuccessfully to add hook behavior to close the tooltip manually).

It'd be great to be able to have both the evil-move-cursor-back setting and the expected tooltip closing behavior but it's definitely not killing any kittens.

@mmcnl
Copy link

mmcnl commented Oct 24, 2015

Oh, looks like using this hook instead is giving the desired behavior, even when (setq evil-move-cursor-back nil) is set:

(add-hook 'evil-normal-state-entry-hook 'company-abort)

@fintelkai
Copy link
Contributor

@mmcnl Thanks for the tip (#1097 (comment)). This had been driving me bonkers.

@aldanor
Copy link

aldanor commented Feb 28, 2016

Would this be a sensible default?

Confirmed, the above hook solves it when exiting to normal mode via fd or ESC, even when evil-move-cursor-back is disabled.

@StreakyCobra
Copy link
Contributor

@aldanor You can create a PR with this if you feel motivated, this would be discussed there :-)

@aldanor
Copy link

aldanor commented Feb 28, 2016

Well, I'm not sure it is a sensible default for everyone -- if it is I could try and open a PR. For me it surely is, it is natural to expect that fd or ESC actually kill the company popup; if you want to ignore the popup and stay in insert mode -- you just continue typing and it will go away on its own.

@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
- Forum - Auto-completion Ready for work stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

9 participants