-
Notifications
You must be signed in to change notification settings - Fork 26
Route ESC to terminal in alt-screen apps under evil-ghostel (#215) #216
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd imagine there's a scenario where you're in normal state in emacs but want ESC to be sent to the insert state in the nested emacs/vim or maybe vice versa. Not sure because we're dealing with 2 modal states that could be not synchronized.
Or maybe in a non normal/insert state (like visual/motion/etc?) state but wanting ESC to pass through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I'm not an evil user I'm not 100% I understand what you mean, can you rephrase or make a suggestion for a fix?
btw (maybe it helps), you can always
C-c C-q <esc>to send the next key to the terminal whatever it is ( in this case).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. if you're in emacs (outer) and vim (inner) [start emacs -> start ghostel -> start vim inside ghostel
maybe using 'insert state is ok e.g. for the user to interact with ghostel, they need to be in insert state, which then triggers your function above
the cycling might be strange though
e.g. emacs+evil [normal state] -> go to insert state -> press i in vim to go to insert state -> press ESC. this cycles the ESC to the next thing.
But you want this instead:
emacs+evil [normal state] -> go to insert state in emacs -> press i in vim to go to insert state -> press ESC -> (normal state in vim) -> press i again to go to insert state in vim -> press ESC to go to normal state in vim -> press i again to go to insert state in vim -> and so on.
^ I think this case is more likely to happen.
If you do that though, you still need a way to get back to the outer emacs (e.g. to get back to normal state in emacs) but once the inner vim is taking ESC inputs, it really won't know which ESC you want to send to so you can't do it automagically.
No suggestion, the way we do it in vterm is kind of a "this is too complicated, just let the user decide when they want what". If there's a more clever way to handle this, I'm all for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But doesn't the auto-mode kinda address that in that is sends the ESC so long to vim as long as vim is open. You close it to type something in the shell, ESC gets routed to evil?!
And if you want your first case or not have ESC forwardet to the terminal when an alt-screen app is running, you have to manually change the routing (like in your vterm solution right now)?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to leave the window/leave vim running but still be able to get back to Normal state in emacs. I think this is a relatively common use case so won't describe specific examples. :)
Yeah, I think it's a more manual/intentional step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok.
But anyway, should we merge this PR as it provides at least a workaround (and with the auto-mode hopefully even a slightly better hack than vterm)?
(and this might be me not using it, but if you just want to get into normal state emacs, you
can of course just bind
evil-force-normal-stateso something likeC-c escor whatever.)And if you or some other evil user has a better idea how that "workflow" could be implemented I'm open for issues or PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks.
And happy to discuss any ideas/PRs, especially evil related as I don't test this integration very much.