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

Shell has faulty insertion behavior #8061

Closed
travisallison opened this issue Dec 27, 2016 · 5 comments
Closed

Shell has faulty insertion behavior #8061

travisallison opened this issue Dec 27, 2016 · 5 comments
Labels
- Bug tracker - Shells in Emacs stale marked as a stale issue/pr (usually by a bot)

Comments

@travisallison
Copy link

Description

When the default shell is something other than shell, the insertion behavior in the middle of a line is faulty. The insertion jumps immediately to the end of the line. See the following URL for a better visual description of the problem.
http://stackoverflow.com/questions/40447007/spacemacs-multi-term-command-cannot-insert-text-in-existing-text

Note: it happens in the following shells: term, ansi-term and multi-term.

Reproduction guide

Start emacs
Make sure that the default shell is term, ansi-term, or multi term.
Open a terminal using SPACE '
Type a word at the prompt. Escape. Go backwards a few steps using h key. Type i for insertion mode. Type a letter.

-Observed behaviour:
Letter will be inserted at end of line.
Expected behaviour:
Letter will be inserted in the middle of the word.

Note: if you maneuver backwards with the arrow key instead of escaping to command mode, you can insert into the middle of the word. Also, if you move backwards with the arrow key while in insertion mode. Then escape to command mode. Move backwards with h key. Then enter insertion mode and type a letter, the letter will be inserted where you escape to command mode. It's as if the shell isn't being updated with the current cursor position when in command mode.

System Info 💻

  • OS: gnu/linux
  • Emacs: 24.5.1
  • Spacemacs: 0.200.5
  • Spacemacs branch: master (rev. 664ba6a)
  • Graphic display: t
  • Distribution: spacemacs
  • Editing style: vim
  • Completion: helm
  • Layers:
(markdown c-c++ auto-completion ycmd evil-commentary
          (c-c++ :variables c-c++-enable-clang-support t)
          emacs-lisp git org ibuffer pdf-tools tmux
          (shell :variables shell-default-shell 'multi-term shell-default-width 30 shell-default-position 'bottom)
          version-control themes-megapack)
@xged
Copy link

xged commented Feb 18, 2017

Same (for a long time).

@chu-
Copy link

chu- commented Feb 23, 2017

Same problem

@chu-
Copy link

chu- commented Feb 23, 2017

#3125 Inconsistencies in ansi-terminal

@mattduck
Copy link

I believe this behaviour (and that in #3125) is due to the way the terminal process
is handled in Emacs, which is described here: #4063 (comment).

In the default term-char-mode, all characters in insert-state are sent to the
terminal, including control characters which can be used for movement.
When you ESC to normal-state in Evil, your movement bindings are not sent to
the terminal.

The "proper" way to use your Emacs bindings to edit text in term-mode is to
use term-line-mode and send the whole line at once, but this has its own
downsides - eg. you lose access to tab completion.

One workaround to get more familiar term bindings is to go into emacs-state,
and use set -o vi. This way you can ESC to access normal-mode within the
terminal.

Disclaimer: I'm not using spacemacs, just evil.

@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
- Bug tracker - Shells in Emacs stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

5 participants