Add support requested by a user for number_pad:3 to use a phone-style
keypad layout where 1,2,3 are on the top row and 7,8,9 on the bottom,
opposite of the adding machine layout adopted by computer keyboards. Also
number_pad:4 combines that with the number_pad:2 hack to give different
behavior for the 5 key (also meta-5 and meta-0). And number_pad:-1 is a
rather absurd way to support German keyboards which have y and z keys
swapped, avoiding the need to add a new option for that. With it, z moves
upper-left and y zaps wands, with corresponding swap of the upper case,
control, and meta variations of those two letters. (There is a "German
keyboard patch" for this floating around the net, but it implements a
compile time configuration setting which results in hard-coded behavior
for those keys. This implementation lets it be toggled on or off at will.)
There's more here, intended to ultimately simplify rhack() quite a
bit. Most of that isn't finished yet. However, the part that is done
should produce same run-time behavior as before. I hope....
iflags.num_pad and iflags.num_pad_mode should now be viewed as opaque
items used for communicating dynamically updated option settings to the
core only. Ports and/or interfaces which feel inclined to peek at them
should switch to Cmd.num_pad,&c instead. (I've made that switch for a
couple of places which would have stopped compiling due to sdir and ndir
going away, and for vms+tty where I could directly test the change(s),
possibly plus one or two places which got heldover over from my earlier
attempt that did try to update all of them. Ports which haven't made the
change yet ought to continue to work as-is though.)
Eventually ports/interfaces which implement alternate ways to invoke
commands (pull down menus or extra keyboard buttons or whatever) should be
able to scan Cmd.commands[] to figure out which input characters trigger
which nethack functions. The ones that currently use hardcoded key lists
will probably need to migrate before any dynamic key binding functionality
gets implemented. (Which may never happen; it's definitely not on my own
to-do list.) Cmd.serialno is intended to be the way for them figure out
when the commands have been changed (which right now only happens when 'O'
is used to alter the number_pad setting); perhaps a new interface callback
would be better suited for communicating this.
It may be necessary to rearrange header inclusion so that func_tab.h
gets included before flag.h (and/or struct cmd gets moved from the latter
to the former--but then func_tab.h would be needed in a bunch of places
which don't currently use it) to support some pre-ANSI compilers. And the
command initialization might need to be moved to somewhere earlier than
init_options() at some point if port/interface initialization starts caring
about it.
projects / nethack / commit