Blink: Emacs

[ftoralesacosta]

Emacs no longer opens files from the command line over ssh. One has to do c-x c-f in emacs to open a file. What’s interesting is inside a tmux session, emacs works fine from the command line. I’ve tested with other terminals and computers and emacs can open files from the command line just fine (I.e. “emacs file.txt”).

[Osushi]

I have same issue. ( and also tmux is same)

When I open file from emacs, the file not open and emacs is opened by scratch mode.

[skoji]

Same here on macOS Catalina and Ubuntu 18.04 LTS. emacs -q is same.

It works fine on the following :

• inside screen session
• inside tmux session.
• connecting over mosh

[ytzeng1]

Same here. Emacs is not loading files. The remote server is Ubuntu 16.04 LTS

[carloscabanero]

I wasn’t able to reproduce this myself. Is there something in your .emacs? The file is a parameter and shouldn’t have anything to do with Blink at all 🤔

[ytzeng1]

I’ve tried removed .emacs file, and also tested on raspberry pi with freshly installed emacs. Still wouldn’t load files using emacs foo.txt. I am on version 13.5.1. Thank you!

I wasn’t able to reproduce this myself. Is there something in your .emacs? The file is a parameter and shouldn’t have anything to do with Blink at all 🤔

[gonsie]

This is happening to me too, but not when using other iPad ssh apps (such as Prompt and Terminus).

It does not matter what emacs version (26.3, 24.3) or operating system is on the other side (I tried Mac OS X 10.14.6 and RHEL 7.6). Even ssh-ing through the Mac to a Linux system has this error.

This has nothing to do with my .emacs files (running emacs with -Q does not fix the issue). Indeed, emacs itself shows that it was passed the correct command line arguments and that it has processed them all.

[carloscabanero]

I tried it yesterday with Ubuntu too and didn’t have any issues. Could anyone here set up an account in a non-critical machine so I can test this myself?

Maybe it is an issue with Blink configuration.

@gonsie when you say emacs shows that it was passed the correct cli arguments and has processed them all, you mean the file is also passed, right?

[carloscabanero]

Fedora too, no issues. 🤔

[ytzeng1]

I noticed that when I call emacs using blink shell, I always get a Quit signal instead of the usual (for information about GNU emacs ......) welcome message. Attached is the backtrace info.

-UUU:----F1 scratch All L1 [(Lisp Interaction Fly ElDoc)] ------------------------------------------------------
1Debugger entered--Lisp error: (quit)
2 xterm--version-handler()
3 xterm--query("\033[>0c" (("\033[?" . xterm--version-handler) ("\033[>" . xterm--version-handler)))
4 terminal-init-xterm()
5 tty-run-terminal-initialization(# nil t)
6 command-line()
7 normal-top-level()

[gyre]

I also get this error. Didn't notice it previously. It's hard to debug. Happens exactly where the previous poster said... it's after the user's init file has been run and in the xterm--version-handler.

[philregier]

Seems like I'm getting into xterm--query before trapping the quit signal but there is a lot going on in there. Does seem to be in the (let ((evt (read-event ... block if I'm reading correctly...

EDIT: For what it's worth, I got my trace by temporarily adding the line (set 'debug-on-quit t) to xterm.el immediately following the defunition of xterm--version-handler.

[philregier]

So a possible workaround, set TERM to something other than xterm or xterm-256color. Emacs seems to work fine for me when I call TERM=linux emacs -nw or TERM=ansi emacs -nw.

(Personally, I utterly detest xterm coloring anyway, so TERM=linux is already my preference.)

[carloscabanero]

Thanks for debugging this! I have xterm-256color set in my .bashrc, and have no problem opening a file.

This being said, I'd bet is something related to a compatibility issue while executing all the .emacs.d structure. Whenever there is an error during loading, everything just stops for emacs.

Does anyone have any special configurations uploaded to GitHub we can try?

[philregier]

Just to clarify, I think the record shows that people who encounter this issue experience it with .emacs and .emacs.d removed and/or with --no-init-file. Furthermore, this issue does not prevent a file from being opened in emacs (e.g., with C-x C-f or with the find-file command) but rather from being opened on the command line (specifically, because in xterm--query or thereabouts one of emacs's asynchronous terminal query routines produces a quit signal, interrupting initialization before the implicit find-file can be executed).

@carloscabanero If this is exactly the use case you tested -- emacs --no-init-file -nw filename.txt -- and the file opened at startup without having to open it manually, then you've successfully evaded the issue. I tested with RHEL7 and a fairly recent emacs build from source. Is your version of Blink newer than 17 days by any chance? If so, I'll try again.

[nrnrnr]

This is entirely an issue with the TERM environment variable. Somehow when it is set to xterm-256color, Emacs does not open the file.

It would be nice to know what $TERM Blink thinks it is emulating. I have not found that information in the documentation.

[kjmph]

Here is the precise line that is causing the "Quit" and then aborts opening a file:

https://github.com/emacs-mirror/emacs/blob/master/lisp/term/xterm.el#L737-L738

I believe it is because Blink is reporting as an xterm with 256 as the version number, yet doesn't support the background color query?

For now, adding this to your ~/.emacs fixes the problem:

(setq xterm-extra-capabilities '())

[carloscabanero]

Thanks, will close this for Blink 14.

[andschwa]

You may prefer to set it to:

(setq xterm-extra-capabilities '(modifyOtherKeys getSelection setSelection))

This avoids the bug with reportBackground but keeps copy/paste with Emacs bindings out of the Blink app working (and theoretically keeps other keys bound, though I don’t know how to test that).

The fix should be that Blink starts supporting checking the background color since it advertises that it does so.

[carloscabanero]

Thanks everyone for your help with this. Blink is an xterm-256color by default, but additionally applications may request the device attributes by calling something like echo -ne '\e[>0c'; cat, and we return ^[[>0;256;0. This value does not change, no matter what TERM you have setup. The two first semicolons are important, the first one sets a VT100 (like xterm does), and the second one is a version which may be used to gather capabilities (kinda like firmware, xterm does > 200, iterm and terminal.app do 95, and tmux does 86) - leaving here two references for more info, any other insights are greatly appreciated https://github.com/microsoft/terminal/pull/6850, https://invisible-island.net/xterm/ctlseqs/ctlseqs.html.

Now, what happens is that emacs and vim usually rely on that firmware number to figure out features to maintain compatibilities with terminals they are talking to. For Emacs you can read it here (https://github.com/emacs-mirror/emacs/blob/ac102bb966f7944babbd8594684550905eecca0a/lisp/term/xterm.el#L739). As you see, if the version is higher than 242, it tries to then request the background color. We do support the call with OSC 11 (we actually added it ourselves, to close #222). Funny thing is that the value we return (echo -ne '\e]11;?\a'; cat returns ie ^[]11;rgb;0000/0000/0000^G), for some reason it is not taken by emacs as @kjmph correctly pointed out. And the extreme terminal fun comes from realizing that although iTerm and all those support also the OSC11, because their number is 95, emacs never even tries 🤣.

We have a workaround that will release soon, but will appreciate a bit of extra help so we are able to do this properly:
1 - If anyone has access to a Xterm or maybe Gnome terminal may work as well, please send us what the echo -ne '\e[11;?\a'; cat returns for you. Maybe we are missing something there and that is why we are not compatible?
2 - Maybe it is emacs not parsing it properly or expecting a different rgb? @kjmph, could I ask you for some extra help to try to debug this with me?

Thanks!!

edit: bracket typo for future ref

[nrnrnr]

I must be misunderstanding something. cat hangs waiting for standard input. Maybe that's not meant to be a shell command but something else?

[kjmph]

I believe the square bracket is just reversed, correct? It should be echo -ne '\e]11;?\a'; cat

On xterm I see:
^[]11;rgb:ffff/ffff/ffff^G

On Terminal.app I see:
^[]11;rgb:0000/0000/0000^G

On Alacritty I see:
^[]11;rgb:0000/0000/0000^G

Is this helpful? I can't run gnome-terminal without taking my Linux box out of headless mode.

[carloscabanero]

Thanks! I am mostly interested on xterm. This looks exactly like what we are sending back. I don't know how to debug emacs enough to see if we may be missing something else after the call. Do you think you could dig deeper on what is exactly the part that emacs is missing there? Thanks!

We will release a version with the workaround while we figure this out.