Emacs, Ctrl/Alt/Shift + Arrow keys

[incomingstick]

It seems that Ctrl Shift and Alt do not work properly with Arrow keys when using xst, this makes using programs such as emacs extremely difficult. I can confirm that these keys input fine with urxvt and xterm, but not xst. I have been hunting for answers on this and have not found anything yet. It looks like there was a fix for something like this in st back in 2016 here.

It appears rather than intended behavior, the terminal inputs 5A for Ctrl+Up, 5B for Ctrl+Down, 5C for Ctrl+Right, and 5D for Ctrl+Left. Doing this with Alt gets you 3A-D, and with both Ctrl+Alt together you get 7A-D. Shift+Arrow keys gets you 2A-D, Ctrl+Shift is 6A-D, Alt+Shift is 4A-D. I think you can see the point.

I have included a gif below to show the issue.

System Info

OS: Arch Linux Kernel: 5.2.8 Shell: Bash 5.0.7 WM: i3 xst version: xst 0.7 (c) 2010-2016 st engineers

[incomingstick]

Also, I probably should have used .Xresources for the gif instead of .Xdefaults, but oh well 🤷‍♂️

[incomingstick]

So this seems to be a discrepancy between how these are handled as characters in xst vs other terminals, against how Emacs would expect to read them. The default character codes can be manually forced in Emacs to read this input properly, however it would be nice to see this handled by xst to work with Emacs more seamlessly.

Here is what I needed to add to the emacs config to force it to understand the xst input for these character combinations:

(unless (display-graphic-p)
  (progn
    (define-key input-decode-map "\e[1;2A" [(shift up)])
    (define-key input-decode-map "\e[1;2B" [(shift down)])
    (define-key input-decode-map "\e[1;2C" [(shift right)])
    (define-key input-decode-map "\e[1;2D" [(shift left)])
    (define-key input-decode-map "\e[1;3A" [(alt up)])
    (define-key input-decode-map "\e[1;3B" [(alt down)])
    (define-key input-decode-map "\e[1;3C" [(alt right)])
    (define-key input-decode-map "\e[1;3D" [(alt left)])
    (define-key input-decode-map "\e[1;5A" [(control up)])
    (define-key input-decode-map "\e[1;5B" [(control down)])
    (define-key input-decode-map "\e[1;5C" [(control right)])
    (define-key input-decode-map "\e[1;5D" [(control left)])
))

Edit: I do want to point out that I did fork the repo and am going to try and take a look myself. I am getting my toes wet with a few smaller changes (such as a patch for setting the paste mouse button via Xresources (I actually already have this working) for people without a middle mouse button, such as laptop users). Once I have a better idea of the actual flow of the terminal process I will take a closer look at how those key codes are handled vs a terminal like urxvt.

[actionless]

It looks like there was a fix for something like this in st back in 2016 here.

have you tried applying the same patch to xst's config.h?

[incomingstick]

I have already looked into it. That patch made it into st, and as a result was already a part of xst. 🤷‍♂️ Shorter answer: yes, I had.

I have also noticed the Delete key does not to a forward delete as would be expected. I have not had time to look into that further either.

[amno1]

I have build st few days ago and also discovered that delete key, home and end keys didn't work properly. I fixed those in my config, which can be seen on my repo. I am also Emacs user and I haven't experienced any strange behaviour with Emacs as seen in your gif. If you haven't fixed your st build yet, you might look into config.h in my st repo, if it helps.