vscode: Emacs usage in VSCode terminal is broken

Issue Type: Bug

Since the latest update, when I try to run emacs in the VSCode terminal, Weird Stuff™ happens.

First, the editor doesn’t show up right away. I get a blank terminal and have to hit a keystroke to have it redraw.

More importantly, when opening emacs with a file as the argument (or, for example, when using emacs as the git commit message editor) the editor opens to *scratch*.

This did not happen in previous versions. Emacs works fine in the system terminal, just not VSCode’s.

I’ve had a colleague successfully reproduce this behavior on their copy of 1.64.1 as well.

VS Code version: Code 1.64.1 (Universal) (d6ee99e4c045a6716e5c653d7da8e9ae6f5a8b03, 2022-02-07T17:26:08.977Z) OS version: Darwin arm64 20.6.0 Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 (8 x 24)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 2, 2
Memory (System)	16.00GB (0.16GB free)
Process Argv	–crash-reporter-id 8e391140-90fd-402a-914a-809486f4e509
Screen Reader	no
VM	0%

Extensions (14)

Extension	Author (truncated)	Version
gitlens	eam	11.7.0
vscode-pull-request-github	Git	0.36.1
vscode-emacs	hir	0.1.1
plantuml	jeb	2.17.2
vscode-position	jtr	1.1.2
vscode-docker	ms-	1.19.0
python	ms-	2022.0.1814523869
vscode-pylance	ms-	2022.2.1
jupyter	ms-	2022.1.1001821375
jupyter-keymap	ms-	1.0.0
jupyter-renderers	ms-	1.0.6
remote-containers	ms-	0.217.2
vscode-thunder-client	ran	1.11.1
rewrap	stk	1.16.1

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392cf:30425750
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dsc:30433058
pythonvs932:30410667
wslgetstartedc:30433508
vscop453:30404998
vsrem710:30416614

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 22
Comments: 17 (8 by maintainers)

Most upvoted comments

Ok, i have a clue. If you notice in the screenshots posted to this issue, they have Quit displayed in the status bar. Adding (setq debug-on-quit t) to ~/.emacs results in the following backtrace immediately on emacs startup in the vscode integrated terminal:

Debugger entered--Lisp error: (quit)
  xterm--version-handler()
  xterm--query("\033[>0c" (("\033[?" . xterm--version-handler) ("\033[>" . xterm--version-handler)))
  terminal-init-xterm()
  tty-run-terminal-initialization(#<frame F1 0xc927b0> nil t)
  command-line()
  normal-top-level()

adding (setq xterm-extra-capabilities nil) to ~/.emacs solves the issue. I believe the commands emacs issues are detailed in https://github.com/emacs-mirror/emacs/blob/master/lisp/term/xterm.el, but I haven’t investigated further.

joelhock on Mar 2, 2022

I have a similar issue. No delay in starting up emacs, but emacs will open into scratch instead of the file argument. This happens both on a local Mac OS instance as well as on a remote Linux based instance. emacs will open file correctly when manually loaded from inside emacs once started.

Version: 1.65.0-insider Commit: bb221a61d29deabd99ee9431736d04f2175cb596 Date: 2022-02-11T05:16:57.139Z Electron: 16.0.8 Chromium: 96.0.4664.110 Node.js: 16.9.1 V8: 9.6.180.21-electron.0 OS: Darwin x64 20.6.0

fherwig on Feb 13, 2022

to verify, run emacs __file-name___ . it should open the file and display its contents, not showing scratch at the bottom

meganrogge on Mar 28, 2022