ctrl+enter prints ;5;13~

[bep]

I use nano as my Git editor, which is why I stumbled over this right out of the gate. But I get the same error if I

1. nano foo.txt
2. Add some text.
3. Try to save the file.

~ ❯❯❯ uname -a
Darwin bep-mac14.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000 arm64

Ghostty verison: 1.0.0.

This works fine in Kitty and Iterm 2.

[mitchellh]

Nano works completely fine for me. Are you running into this? https://ghostty.org/docs/help/terminfo

[bep]

~ ❯❯❯ env | grep TERM=
TERM=xterm-ghostty
COLORTERM=truecolor

Which sounds ... correct? But how do I know. Are you saying that there's a special setting that sets the byte order or something?

[mitchellh]

Terminfo dictates input format yes (not my invention). Run infocmp to see if it can load it correctly. If it can, I'm still not sure what's wrong since as I said nano works totally fine for me. :)

[bep]

infocmp loads fine:

~ ❯❯❯ infocmp
#       Reconstructed via infocmp from file: /Applications/Ghostty.app/Contents/Resources/terminfo/78/xterm-ghostty
xterm-ghostty|ghostty|Ghostty,
        am, bce, ccc, hs, km, mc5i, mir, msgr, npc, xenl,
        colors#256, cols#80, it#8, lines#24, pairs#32767,
        acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
        cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
        dl=\E[%p1%dM, dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX,
        ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l,
        fsl=^G, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH,
        ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J,
        indn=\E[%p1%dS,
        initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
        invis=\E[8m, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
        kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,
        kRIT=\E[1;2C, kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB,
        kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM,
        kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~,
        kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S,
        kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ,
        kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~,
        kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q,
        kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR,
        kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~,
        kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~,
        kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R,
        kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~,
        kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
        kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~,
        kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R,
        kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
        kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
        kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
        kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
        kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
        kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
        kri=\E[1;2A, oc=\E]104\007, op=\E[39;49m, rc=\E8,
        rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
        rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
        rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m,
        rmul=\E[24m, rs1=\E]\E\\\Ec, sc=\E7,
        setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
        setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
        sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
        sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
        smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
        smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
        u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd,

Also, the "it works for me" argument gets old pretty quick.

[mitchellh]

Also, the "it works for me" argument gets old pretty quick.

It's not an argument. I'm trying to learn more to resolve your issue, but I can't really do it if I can't reproduce it. That's all!

[mitchellh]

Your infocmp looks good. I'm not sure. We'll need more details from you or others before we can open an issue for this (as noted in CONTRIBUTING.md).

[Neutrollized]

nano isn't my usual editor, but it does work fine for me.

Darwin mac.lan 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec  6 19:02:41 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6030 arm64

COLORTERM=truecolor
TERM=xterm-ghostty
TERMINFO=/Applications/Ghostty.app/Contents/Resources/terminfo
TERM_PROGRAM=ghostty
TERM_PROGRAM_VERSION=1.0.0

[bep]

Not sure if this adds anything useful, but it seems to add ?;5;13~ to every filename for some reason:

Darwin mac.lan 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:02:41 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6030 arm64

I'm on 23.6.0 Darwin Kernel Version 23.6.0 (I need to wait a little with the upgrade for some compability reasons).

[bep]

OK; so I guess it's the function keys that I use when saving in nano that somehow leaks into the ... filename:

ghostty/src/input/function_keys.zig

Line 206 in a8e5eef

.{ .mods = .{ .ctrl = true }, .sequence = "\x1b[27;5;13~" },

Hmm...

[bep]

OK, now I see what's happening.

What I do when saving a file in nano:

1. Hold down ctrl and click o
2. The correct "filename to write" is displayed.
3. Still holding down ctrl I click enter.
4. ?;5;13~ gets appended to the filename.
5. I then click enter (without ctrl) and get the illegal byte sequence.

This is muscle memory for me, but if I remember to let go of the ctrl button before hitting enter, everything works fine. But I think I need to find a way to turn off whatever shortcut is attached to ctrl+enter.

[JakeWharton]

Hmm I don't see this behavior.

❯ nano --version
 GNU nano, version 8.3
 (C) 2024 the Free Software Foundation and various contributors
 Compiled options: --disable-libmagic --enable-utf8

❯ fish --version
fish, version 3.7.1

❯ ghostty --version
Ghostty 1.0.0

Version
  - version: 1.0.0
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

nano.mov

[bep]

OK, now I see what's happening. I have updated the issue/topic title.

The best config workaround I have found is:

keybind = ctrl+enter=ignore

But this smells like a bug.

[Neutrollized]

I get the "error" you get when I hit ctrl+enter, but I don't think it's a bug. Maybe it's supposed to bind to something and this is terminal specific, but I tried it on iTerm (where I'm coming from) and the Terminal app and if I hit ctrl+enter there, I get a right-click menu options pop up. I'm not a nano user, but I looks like over on iTerm hitting ctrl+enter wouldn't do any saving anyway. At least here you have the option to ignore the keybind here 🤷

[bep]

I get the "error" you get when I hit ctrl+enter, but I don't think it's a bug.

The bug is that these ansi keyboard codes gets printed to the console. That has, to my knowledge, no practical use, is confusing and potentially harmful (as in the example above using nano as the Git commit message editor).

I tested this in 4 terminals:

• Both Apple's Terminal and iTerm 2 shows a menu on ctrl+enter
• With Kitty ctrl+enter is the same as enter (which is where my recent muscle memory comes from, I guess, as this has been my Terminal for the last year or so).
• Ghostty prints ;5;13~ to the console.

[JakeWharton]

Ghostty is not printing these to the console. It is sending 1b5b32373b353b31337e on ctrl+enter which is encoded using the Kitty keyboard protocol.

Something in your chain of applications is parsing it improperly.

This is a CSI sequence which should be consumed until a byte in the range 0x40..0xff is found, which is not present until the trailing 0x7e. Whoever is doing the improper parsing is stopping after the bytes which represent "27" (0x3237) which causes the rest of the sequence to be interpreted as normal keyboard input.

[gpanders]

@bep You can make Ctrl+Enter behave the same as enter with

keybind = ctrl+enter=text:\r

Unlike other terminals, Ghostty encodes modified key presses using the CSI u (fixterms) protocol by default. Many applications don't know how to interpret these sequences and so will print them to the console instead (they should probably just be ignoring them, but alas).

In this case, Ctrl+Enter is being encoded using Xterm's "modify other keys" encoding, i.e. CSI 27;5;13~. I am not sure why this isn't using CSIu, but the conclusion is the same in any case.

[mitchellh]

I'll add a note to add a docs page about this. I think specifically having a config you can copy and paste to undo some of the fixterms stuff would be good.

[onetom]

Also ctrl-m uses CSI 109;5u by default (as mentioned here), while ctrl-j seems to work as an Enter alternative. Seems related.

Based on the example, this indeed seems to work as it did in Apple Terminal, for example:

keybind = ctrl+m=text:\n

though now I'm not sure why doesn't ctrl-m sends \r, which is \0x0d, 13, since m is the 13th letter in the ABC...

[bep]

Many applications don't know how to interpret these sequences and so will print them to the console instead (they should probably just be ignoring them, but alas).

Many applications would then include all the shells I have tested with this; bash, ksh (prints ^[[27;5;13~), zsh. The default behaviour here for ctrl+enter and shift+enter (at least) is at best very confusing.