Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003007Dwarf FortressTechnical -- Input/Keybinding/Macrospublic2010-08-11 08:162022-04-19 14:53
Assigned ToBaughn 
PlatformLinuxOSLinuxOS Version2.6.35
Product Version0.31.12 
Target VersionFixed in Version 
Summary0003007: Can't send shift + <whatever> to the terminal
DescriptionThe 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 ReproduceSet output mode to text, and try to use command that requires holding shift.
TagsNo tags attached.
Attached Files

- Relationships
parent of 0005494acknowledgedlethosor Shift-enter to save changes to schedule orders does not work in TEXT print mode 
has duplicate 0006899resolvedFootkerchief Modifier keys don't process correctly in text mode 
has duplicate 0008962resolvedlethosor PRINT_MODE:TEXT Shift-key combinations do not work 
Not all the children of this issue are yet resolved or closed.

-  Notes
ILikePie (reporter)
2010-08-11 08:19
edited on: 2010-08-12 04:52

Whoops, forgot to proof-read, please excuse any errors.

Baughn (manager)
2010-08-12 05:34

There is no portable way to deal with shift. Sorry.
Footkerchief (manager)
2014-07-09 19:45

Reopening due to 0006899
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. [^]
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.
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.)
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.
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.

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.
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...
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.
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.

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.
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

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker