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

Inconsistencies in ansi-terminal #3125

Closed
rahulmutt opened this issue Sep 24, 2015 · 3 comments
Closed

Inconsistencies in ansi-terminal #3125

rahulmutt opened this issue Sep 24, 2015 · 3 comments
Labels
Bug :-( stale marked as a stale issue/pr (usually by a bot) Terminals To be reproduced

Comments

@rahulmutt
Copy link

When working with the shell, I've noticed that there is a difference between the text you see and the text that gets sent in certain cases.
imageedit_2_5196751952
Suppose I use something like 'lein repl' for Clojure inside of ansi-terminal. When I press Backspace, it doesn't show that the text is deleted, but in fact it is deleted (as shown by the result from the repl). Similarly if you press 'x' on something, it shows that the character is deleted under the cursor, but the string sent to the shell is the original string. So the solution is straightforward:

(1) In shell mode, if the 'Backspace' key is pressed, additionally perform the function of the 'x' key.
(2) In shell mode, if the 'x' key is pressed, additionally perform the function of the 'Backspace' key.

This bug has forced me to use a normal terminal emulator for basic repl work. This bug also happens when you paste text into the terminal from the external clipboard. It also occurs with 'sbt'.

@mclearc
Copy link
Contributor

mclearc commented Oct 29, 2015

I'm seeing a similar bug in both ansi- and multi-term. I find this particularly bothersome because, on OS X, I use text expander snippets system wide. These show as being pasted into the terminal but do not execute. I have also found that text cannot be pasted into terminal using the standard OS X command-v (note that I use the osx layer), but must rather be put into the terminal from normal mode using put. Interestingly, eshell does not exhibit this problem. It would be great if the emacs ansi- and multi-terms could be made to behave more consistently with other terminals in this regard.

System Info

  • OS: darwin
  • Emacs: 24.5.1
  • Spacemacs: 0.105.0
  • Spacemacs branch: develop (rev. 150e38e)
  • Distribution: spacemacs
  • Layers:
(auto-completion deft emacs-lisp eyebrowse git helm-bibtex latex markdown org osx pandoc pdf-tools
                 (ranger :variables ranger-show-preview t)
                 (shell :variables shell-default-term-shell "/usr/local/bin/zsh" shell-default-shell 'ansi-term shell-default-height 30 shell-default-position 'bottom)
                 shell-scripts spell-checking sr-speedbar syntax-checking themes-megapack version-control yaml)

@elvis-sik
Copy link

OP said this:

This bug also happens when you paste text into the terminal from the  external clipboard. It also occurs with 'sbt'.

Pretty much all editions I make in evil-normal-state to what is written in the terminal show up in the command line, but then when I press enter, the result is as though they were ignored. This applies to deleting chars with dw or x, and pasting, in particular.

Also, I cannot change the position of the cursor in normal state. Say, I start escaping from insert-state to normal-state, pressing h twice to go left, and then pressing i again. Then if I type, my editions will show up at the place the cursor used to be.

I am reporting this here because it seems related, but am not sure. Maybe it is even expected or known behavior?

Also, this seems not to have anything to do with the shell. I mean, bash, zsh and the like. However, eshell works as expected. I would settle on it if I wasn't so addicted to zsh.

@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 :-( stale marked as a stale issue/pr (usually by a bot) Terminals To be reproduced
Projects
None yet
Development

No branches or pull requests

4 participants