Alt+left/alt+right mess up the input buffer when .inputrc is modified

[jyn514]

$ bit  # alt-left a bunch of times
>> > b> bit ?[1;3D?[1;3D?[1;3D?[1;3D
$ bit # alt-right a bunch of times
bit
>> > b> bi> bit ?[1;3C?[1;3C?[1;3C?[1;3C?[1;3C

[jyn514]

I am still seeing this error on master (bit version v0.6.1).

[chriswalz]

@jyn514 boo, I've tested it on Mac and Ubuntu and seemed to work fine 🤔

[jyn514]

I have this in my .inputrc in case it makes a difference:

## enable Alt-arrows
"\e[1;3D": backward-word ### Alt left
"\e[1;3C": forward-word ### Alt right

[chriswalz]

That's likely the issue. This is how it's implemented.

prompt.OptionAddASCIICodeBind(prompt.ASCIICodeBind{
            ASCIICode: []byte{0x1b, 0x62},
            Fn:        prompt.GoLeftWord,
        }),
prompt.OptionAddASCIICodeBind(prompt.ASCIICodeBind{
            ASCIICode: []byte{0x1b, 0x66},
            Fn:        prompt.GoRightWord,
        }),

Unclear what would be an elegant way to integrate .inputrc but it will be considered for future work

[elder-n00b]

I noticed this can also easily result in a crash:

fish❯ bit
>> bit ?[1;3Cruntime error: index out of range [0] with length 0
goroutine 1 [running]:
runtime/debug.Stack()
    runtime/debug/stack.go:24 +0x65
github.com/chriswalz/bit/cmd.HandleExit()
    github.com/chriswalz/bit/cmd/util.go:324 +0x93
panic({0x561e7a420ac0, 0xc000035ea8})
    runtime/panic.go:884 +0x212
github.com/c-bata/go-prompt.(*CompletionManager).GetSelectedSuggestion(0xc0002b9450?)
    github.com/c-bata/go-prompt@v0.2.5/completion.go:51 +0xb5
github.com/c-bata/go-prompt.(*Render).Render(0xc0002b9450, 0xc0000768c0, 0xc00007a410)
    github.com/c-bata/go-prompt@v0.2.5/render.go:207 +0x3ac
github.com/c-bata/go-prompt.(*Prompt).Input(0xc0002d6090)
    github.com/c-bata/go-prompt@v0.2.5/prompt.go:261 +0x505
github.com/c-bata/go-prompt.Input({0x561e7a2b8feb, 0x6}, 0x561e7a2bba07?, {0xc0001f7798, 0xf, 0x561e7a3cbf20?})
    github.com/c-bata/go-prompt@v0.2.5/shortcut.go:16 +0xc5
github.com/chriswalz/bit/cmd.SuggestionPrompt({0x561e7a2b8feb, 0x6}, 0xc0001f78a8?)
    github.com/chriswalz/bit/cmd/util.go:275 +0x605
github.com/chriswalz/bit/cmd.glob..func1(0x561e7a6c9a80, {0x561e7a2b9da7?, 0x0?, 0x0?})
    github.com/chriswalz/bit/cmd/bit_cmd.go:33 +0xda
github.com/spf13/cobra.(*Command).execute(0x561e7a6c9a80, {0xc000024230, 0x0, 0x0})
    github.com/spf13/cobra@v1.1.3/command.go:856 +0x663
github.com/spf13/cobra.(*Command).ExecuteC(0x561e7a6c9a80)
    github.com/spf13/cobra@v1.1.3/command.go:960 +0x39d
github.com/spf13/cobra.(*Command).Execute(...)
    github.com/spf13/cobra@v1.1.3/command.go:897
github.com/chriswalz/bit/cmd.Execute()
    github.com/chriswalz/bit/cmd/bit_cmd.go:68 +0x25
main.bitcli(...)
    github.com/chriswalz/bit/main.go:78
main.main()
    github.com/chriswalz/bit/main.go:66 +0xb1e

OS: linux amd64
bit version v1.1.2
git version 2.38.1

What I have done: "alt+right", "up", "down". But any other similar "troublesome" keypress will do. I reproduce this in: Alacritty, Kitty, WezTerm, Foot (with or without foot-terminfo installed) and Linux console (using "alt+backspace"), with either bash or fish shell. I have not tried others.

In case it matters, I run the Sway WM (hence Wayland, though with XWayland).

I do not have an ~/.inputrc, only /etc/inputrc which is:

/etc/inputrc

fish❯ pacman -Qo /etc/inputrc
/etc/inputrc is owned by readline 8.2.001-1

fish❯ cat /etc/inputrc
File: /etc/inputrc
# do not bell on tab-completion
#set bell-style none

set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

$if mode=emacs

# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[7~": beginning-of-line
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word

# for rxvt
"\e[8~": end-of-line

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif

I tried removing /etc/inputrc, no difference. I tried appending to inputrc entries for \eb/\ef, \e62/\e66, \e[1;3C/\e[1;3D, no difference. I tried to run it with rlwrap, no difference. I recompiled bit commenting out those two OptionAddASCIICodeBind, no difference. I also tried rebooting, even though AFAIK it shouldn't be necessary and restarting the terminal should be enough.

Frankly I have no idea if the above attempts make sense, this is just one of many things I do not understand LOL.

That said, I may be wrong but it seems to me the problem is somewhere between go-prompt, go-tty and term.

---

edit: another failed shot in the dark:

# in /etc/inputrc
"\e[1;3C": "\ef"
"\e[1;3D": "\eb"

which, in theory, should translate those sequences to the expected ones.

And here I get to something: I replaced the "\ef"/"\eb" with "forward"/"backward" and (only in bash, perhaps because of shell configuration) pressing "alt+left"/"alt+right" at the command prompt results in those strings being typed, but not when running bit (I still get the display glitch and the crash, rlwrap or not).

I conclude that inputrc is not involved at all, and likely that is the root of the problem.

I did not find any reference to readline or inputrc anywhere in the sources of those three packages I mentioned above; there is func ReadLine in go-tty but it has nothing to do with "the" readline.

After all, what those OptionAddASCIICodeBind do, isn't it what an inputrc binding would have done?

---

edit: disregard mentions of rlwrap, I forgot -a (which makes it do its thing, too bad it also messes up display its own way)

^{(terminals... are like women: one can only love them, but never truly understand them)}