0003007: Can't send shift + <whatever> to the terminal

Notes
(0011717) ILikePie (reporter) 2010-08-11 08:19 edited on: 2010-08-12 04:52	Whoops, forgot to proof-read, please excuse any errors.

(0011742) Baughn (manager) 2010-08-12 05:34	There is no portable way to deal with shift. Sorry.

(0025455) Footkerchief (manager) 2014-07-09 19:45	Reopening due to 0006899

(0025480) eropple (reporter) 2014-07-09 21:49	You can't trap keys with getch(), but libtermkey (pretty widely used these days) plays nicely with ncurses and extends it to do this. libtermkey is MIT-licensed. It's compatible with everything I know of; I've used it in Cygwin, Linux, and OS X. http://www.leonerd.org.uk/code/libtermkey/ [^]

(0032696) lightman (reporter) 2015-05-17 16:53	Why is this "not-fixable"? It's easy to distinguish between the arrow-keys and shift-arrow-keys.

(0032697) lethosor (manager) 2015-05-17 17:28	These are the sequences produced in my terminal emulator (results in others may vary, but I've seen this elsewhere as well): left: ^[[D shift-left: ^[[1;2D right: ^[[C shift-right: ^[[1;2C up: ^[[A shift-up: ^[[A down: ^[[B shift-down: ^[[B This can probably be configured depending on the terminal emulator you're using, but as far as I know, ncurses doesn't support shift+arrow keys due to their lack of portability. I did manage to get shift+left/right to work correctly with libtermkey, so that could be a usable alternative. ("not fixable" is a field that wasn't cleared when this issue was previously reopened. Fixed.)

(0032699) lightman (reporter) 2015-05-17 19:09	Thank you for updating the status. I tested the shift-arrow keys with ncurses and they are supported (using the default PuTTY terminal). In fact, the ncurses maintainer has confirmed that shift-enter will work with the right initialization of the terminal. Again, the problem I see is that DF is only allowing single-byte codes to be interpreted.

(0032700) lethosor (manager) 2015-05-17 19:28 edited on: 2015-05-17 19:42	If DF (or ncurses, more accurately) were only interpreting single-byte codes, no arrow keys would work at all since they're represented with multiple bytes (e.g. ^[ [ A, or ESC [ A, corresponds to the up arrow). What do you mean by "they are supported"? From my tests, neither libtermkey nor ncurses can detect Shift-Enter, and multiple sources state that this isn't possible with ncurses. If it is possible with some additional setup, can you provide a source/example? Edit: I managed to get Shift-Up and Shift-Down to work in my terminal emulator. They appear to send different sequences by default (^[[1;2A and ^[[1;2B) in xterm, but Shift-Enter still produces the same result.

(0032701) lightman (reporter) 2015-05-17 19:47	You're right about the single-byte theory and the arrow keys. I hadn't looked at that properly. I mean that ncurses does not prohibit anything and "only knows how to read a sequence of bytes from the terminal". So, for example, I modified a simple ncurses program to make it show the code it receives for whatever key is pressed. Arrows keys and shift-arrow keys produce different codes. When I tried in DF, it definitely registers something different for 'up' vs. 'shift-up'. I think Toady needs to look into how it interprets the input because the codes are different. I'll look into the shift-enter scenario but I might modify PuTTY directly, to support that. I wonder what code DF expects for that combination. Maybe Toady could give me some insight.

(0036178) Treah (reporter) 2017-01-16 21:39	I can confirm this is still a problem using the TEXT output on modern terminals ( gnome, Mate Term ) and the as of this writing current version of DF. 0.43.05 There has to be some type of workaround for this out there tho since the TEXT mode has been in DF for a very long time...

(0036474) alexchandel (reporter) 2017-04-28 13:00	This can be partially fixed immediately. Shift+Left and Shift+Right are read as KEY_SLEFT and KEY_SRIGHT by ncurses, which is why they don't do anything in DF in TEXT mode right now. Many other shifted keys work like this, include Home and End. Unfortunately, Shift+Up and Shift+Down just produce KEY_UP and KEY_DOWN, so this doesn't fully fix the problem. To deal with those (and other common/default shifted keys), you could use define_key(), which lets you define any key combination you want.

(0037579) huelter (reporter) 2018-01-10 06:02	I would like to chime in. I've been playing DF exclusively on TEXT mode on an old computer as it is faster, but this Shift+Key bug is halting my progress. The problem lies on the military menu, schedule orders. When you are assigning specific training orders to a squad, it is requested that you pres Shift+Enter to confirm the order. There is also no way to rebind this to another key. The only solution I found is save+exit the game, restart in default mode, assign the orders that I wanted, then reload the game using TEXT. This takes about 10 minutes every time. If the bug is not gonna be solved, I would like to ask that at least this combination be possible to rebind. Thanks

(0040099) seeschloss (reporter) 2020-02-18 06:09	I was able to "fix" these issues (or more accurately, hack around them) from DF's key bindings screen. First I removed the numpad bindings from the normal movement commands and assigned them to the fast movement commands, so I can now do both fine movement with the arrow keys and fast movement with the numpad. I couldn't find a way to use shift a a modifier. And for the military screen, I simply added a new binding and pressed shift-enter there which DF interpreted as "U+A". It shows as "◙" within the interface, but works fine when I press shift-enter. That's using DF in a screen in gnome-terminal, if it matters.

(0041241) cizra (reporter) 2022-04-19 14:53	Thanks seeschloss for the hint! I discovered that Alt+numpad works better - you can still use the numpad for regular movement, and Alt+numpad for fast movement. Works (tested) in xorg+urxvt locally, and xorg+urxvt+SSH+tmux. Doesn't work in Linux virtual terminal+SSH+tmux (some crtl-b or such gets detected. Perhaps you could redefine the keys and it'd start working?)

Issue History
Date Modified	Username	Field	Change
2010-08-11 08:16	ILikePie	New Issue
2010-08-11 08:19	ILikePie	Note Added: 0011717
2010-08-12 04:52	ILikePie	Note Edited: 0011717	View Revisions
2010-08-12 05:34	Baughn	Note Added: 0011742
2010-08-12 05:34	Baughn	Status	new => closed
2010-08-12 05:34	Baughn	Assigned To	=> Baughn
2010-08-12 05:34	Baughn	Resolution	open => not fixable
2010-08-14 10:28	Footkerchief	Status	closed => resolved
2010-10-26 12:52	technolem	Issue Monitored: technolem
2014-07-09 19:45	Footkerchief	Relationship added	has duplicate 0006899
2014-07-09 19:45	Footkerchief	Status	resolved => acknowledged
2014-07-09 19:45	Footkerchief	Note Added: 0025455
2014-07-09 21:49	eropple	Note Added: 0025480
2015-05-17 16:50	lethosor	Relationship added	has duplicate 0008962
2015-05-17 16:53	lightman	Note Added: 0032696
2015-05-17 16:53	lightman	Issue Monitored: lightman
2015-05-17 17:28	lethosor	Note Added: 0032697
2015-05-17 17:32	lethosor	Resolution	not fixable => open
2015-05-17 19:09	lightman	Note Added: 0032699
2015-05-17 19:28	lethosor	Note Added: 0032700
2015-05-17 19:42	lethosor	Note Edited: 0032700	View Revisions
2015-05-17 19:47	lightman	Note Added: 0032701
2017-01-16 21:39	Treah	Note Added: 0036178
2017-04-28 13:00	alexchandel	Note Added: 0036474
2018-01-10 06:02	huelter	Note Added: 0037579
2018-01-15 06:06	Loci	Relationship added	has duplicate 0010526
2018-01-15 15:27	lethosor	Relationship replaced	parent of 0010526
2020-02-18 06:09	seeschloss	Note Added: 0040099
2021-11-28 10:47	lethosor	Relationship added	parent of 0005494
2021-11-28 10:48	lethosor	Relationship deleted	parent of 0010526
2022-04-19 14:53	cizra	Note Added: 0041241