|Anonymous | Login | Signup for a new account||2022-05-19 15:23 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003007||Dwarf Fortress||Technical -- Input/Keybinding/Macros||public||2010-08-11 08:16||2022-04-19 14:53|
|Target Version||Fixed in Version|
|Summary||0003007: Can't send shift + <whatever> to the terminal|
|Description||The playing with TEXT output, pressing shift + <something> will send 'something' to the terminal, without the shift. Say, for example, trying to scroll quickly with shift + arrows doesn't work.|
|Steps To Reproduce||Set output mode to text, and try to use command that requires holding shift.|
|Tags||No tags attached.|
edited on: 2010-08-12 04:52
Whoops, forgot to proof-read, please excuse any errors.
|There is no portable way to deal with shift. Sorry.|
|Reopening due to 0006899|
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.
|Why is this "not-fixable"? It's easy to distinguish between the arrow-keys and shift-arrow-keys.|
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.)
|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.|
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.
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.
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...
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.
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.
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.
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?)
|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|
|Copyright © 2000 - 2010 MantisBT Group|