Emacs usage in VSCode terminal is broken

[j00bar]

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) (d6ee99e, 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

[fherwig]

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: bb221a6
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

[tstackhouse]

Also seeing this behaviour following the update that pushed the new side panel.

Version: 1.64.2
Commit: f80445acd5a3dadef24aa209168452a3d97cc326
Date: 2022-02-09T22:02:29.527Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.13.0-28-generic snap

VS Code version: Code 1.64.2 (f80445a, 2022-02-09T22:02:29.527Z)
OS version: Linux x64 5.13.0-28-generic snap
Restricted Mode: No

System Info

Item	Value
CPUs	AMD Ryzen 7 4800H with Radeon Graphics (16 x 2029)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	1, 1, 2
Memory (System)	30.78GB (7.09GB free)
Process Argv	--no-sandbox --force-user-env --unity-launch --crash-reporter-id dd44f64f-61ef-4c79-9c0a-8288003c84d8
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

Extensions (55)

Extension	Author (truncated)	Version
project-manager	ale	12.5.0
ng-template	Ang	13.2.3
better-toml	bun	0.3.2
solargraph	cas	0.23.0
coddx-alpha	cod	0.3.1
gitignore	cod	0.7.0
yaml-key-viewer	cyb	0.2.2
vscode-eslint	dba	2.2.2
git-extension-pack	don	0.1.3
githistory	don	0.6.19
gitlens	eam	11.7.0
vscode-html-css	ecm	1.11.0
EditorConfig	Edi	0.16.4
graphviz-preview	EFa	1.5.0
vsc-material-theme	Equ	33.2.0
vsc-material-theme-icons	equ	1.2.2
prettier-vscode	esb	9.2.0
php-intellisense	fel	2.3.14
vscode-jest-runner	fir	0.4.47
vscode-npm	fkn	3.3.0
auto-close-tag	for	0.5.14
terminal	for	0.0.10
shell-format	fox	7.2.2
sass-lint	gle	1.0.7
todo-tree	Gru	0.0.215
terraform	has	2.19.0
rest-client	hum	0.24.6
latex-workshop	Jam	8.23.0
vscode-codeowners	jas	1.1.1
docthis	joe	0.7.1
Angular2	joh	12.0.0
json-escaper	jos	1.1.2
vscode-insertdatestring	jsy	2.3.1
auto-comment-blocks	kev	1.0.1
dotenv	mik	1.0.1
mlxprs	mlx	3.5.1
vscode-json5	mrm	1.0.0
vscode-docker	ms-	1.19.0
remote-containers	ms-	0.217.4
atom-keybindings	ms-	3.0.9
azure-account	ms-	0.9.11
powershell	ms-	2021.12.0
angular-console	nrw	17.14.1
vscode-jscpd	pau	0.3.4
material-icon-theme	PKi	4.13.0
ruby	reb	0.28.1
vscode-yaml	red	1.4.0
code-settings-sync	Sha	3.4.3
guides	spy	0.9.3
dot	Ste	0.0.1
move-ts	str	1.12.0
vscode-ruby	win	0.28.0
php-debug	xde	1.23.0
material-theme	zhu	3.13.19
vscode-open-in-github	ziy	1.3.6

(3 theme extensions excluded)

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
pythonvspyl392:30425749
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30433059
pythonvs932:30410667
wslgetstarted:30433507
vsclayoutctrc:30437038
vsrem710:30416614
vsbas813:30436447
vscscmwlcmc:30436992

[meganrogge]

cc @sbatten

[meganrogge]

In stable, running:

emacs package.json results in:

In insider's, running the same results in:

[meganrogge]

@deepak1556 we think this is a permissions related problem. it happens in 1.64 on linux/mac (before electron update) and we haven't touched node-pty recently. Do you know of any packaging changes that could've caused this?

[fherwig]

Here is code-insider running on Mac in a remote connection to a linux server, left bottom command issued, right resulting emacs editor opening in scratch.

And here the same in a local (zsh) instance, same behaviour.

For me VS code shows the same behaviour, except when I want to exit emacs the entire VS Code window will exit as if I had done Cmd-q. Before the recent update of VS code I did the content would show in emacs, but still when trying to save, the whole VS Code window closes.

VS Code insider
Version: 1.65.0-insider
Commit: 52e6549
Date: 2022-02-16T05:16:06.667Z
Electron: 16.0.9
Chromium: 96.0.4664.174
Node.js: 16.9.1
V8: 9.6.180.23-electron.0
OS: Darwin x64 20.6.0

VS Code
Version: 1.64.2
Commit: f80445a
Date: 2022-02-09T22:00:58.347Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

[deepak1556]

@meganrogge there we no package related changes for macOS/linux with 1.64. Also command of the launched sub process looks fine and --debug-init does not throw any error, so I don't think this was an issue at the process spawn level. Can you check if something changed with terminal rendering ?

$ ps -p 45826
  PID TTY           TIME CMD
45826 ttys001    0:00.49 /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14 ./package.json -nw

[tstackhouse]

I did a couple tests, doing ssh to another host within the vscode terminal emacs behaves as normal. Locally I tried running normally and without -nw (as I have a default alias to add -nw), and both times emacs continues to behave as if it was invoked without the file argument:

10051$ ps 287990
    PID TTY      STAT   TIME COMMAND
 287990 pts/0    S+     0:00 emacs -nw workspace.json

10054$ ps 289079                    
    PID TTY      STAT   TIME COMMAND
 289079 pts/0    S+     0:00 /usr/bin/emacs workspace.json

Subsequently opening a file via M-x find-file (because I can't C-x C-f, as C-f is taken over by the find command), works just fine. One interesting observation that I made was that invoking emacs by itself also behaves differently within the built-in terminal versus in my default terminal. I get the same behaviour regardless of if I invoke it with a file or not, the "scratch" buffer opens, and "Quit" displays in the status bar:

emacs workspace.json

emacs

emacs (in external terminal)

[Tyriar]

I don't think this can be a rendering only issue as it's not opening the file?

We did have a rendering change in this area that @meganrogge pointed out: xtermjs/xterm.js@a63890e#diff-2c55cc3213368a05daba3b895bbb127ef81fa0dfa90f658ace9d89f12e963577R69 - @meganrogge can you see if reverting that fixes it?

[meganrogge]

Reverting that did not fix it @Tyriar

[joelhock]

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.

[giromide]

I wonder if there's an equivalent to this in vim that explains the rendering problem that demands I clear the terminal just prior to running it.

[Zitrax]

Noticed that if I press a key while emacs is loading with a file argument it works, if no key is pressed it opens *scratch*.

[tstackhouse]

Noticed that if I press a key while emacs is loading with a file argument it works, if no key is pressed it opens *scratch*.

Confirmed! It worked for me also.

[danielsue]

adding (setq xterm-extra-capabilities nil) to ~/.emacs
This works for me too. Thanks.

[meganrogge]

Fixed with the linked PR upstream

[meganrogge]

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