[3.4.0] Bug with parsing empty keymaps

[AnonymousHero]

There's a bug in the prefs parsing in 3.4.0 related to keymaps which map a key to (nothing). That is, if you do this:

1. "Create keymap"
2. Press some key (doesn't matter which, really)
3. Type "$" to terminate the keymap
4. Press "y" to save the keymap

and then append your keymaps to a file, Angband will refuse to load the keymap on next startup.

Here's a patch which fixes it, can this please be added before 3.5.x (or even 3.4.1 if that ever happens)?

diff --git a/src/prefs.c b/src/prefs.c
index 0c486df..116d7e0 100644
--- a/src/prefs.c
+++ b/src/prefs.c
@@ -864,13 +864,15 @@ static enum parser_error parse_prefs_b(struct parser *p)
 
 static enum parser_error parse_prefs_a(struct parser *p)
 {
-	const char *act;
+	const char *act = "";
 
 	struct prefs_data *d = parser_priv(p);
 	assert(d != NULL);
 	if (d->bypass) return PARSE_ERROR_NONE;
 
-	act = parser_getstr(p, "act");
+	if (parser_hasval(p, "act")) {
+		act = parser_getstr(p, "act");
+	}
 	keypress_from_text(d->keymap_buffer, N_ELEMENTS(d->keymap_buffer), act);
 
 	return PARSE_ERROR_NONE;
@@ -1022,7 +1024,7 @@ static struct parser *init_parse_prefs(bool user)
 		/* XXX should be split into two kinds of line */
 	parser_reg(p, "B uint idx str text", parse_prefs_b);
 		/* XXX idx should be {tval,sval} pair! */
-	parser_reg(p, "A str act", parse_prefs_a);
+	parser_reg(p, "A ?str act", parse_prefs_a);
 	parser_reg(p, "C int mode str key", parse_prefs_c);
 	parser_reg(p, "M int type sym attr", parse_prefs_m);
 	parser_reg(p, "V uint idx int k int r int g int b", parse_prefs_v);

[Magnate]

Excellent spot, thanks - logged as #1683.

[fizzix]

Thanks, we'll try to get this in for 3.4.1 We've been fixing some minor bugs behind the scenes, and we'll probably get 3.4.1 out after the competition is over.

[AnonymousHero]

Originally Posted by fizzix

Thanks, we'll try to get this in for 3.4.1 We've been fixing some minor bugs behind the scenes, and we'll probably get 3.4.1 out after the competition is over.

Cool, thanks.

(Btw, the reason this is quite important to me is that I use empty keymaps to rebind Return/Enter to do nothing so that I can avoid the in-game action menu when going through messages using those keys.)

[Magnate]

Originally Posted by AnonymousHero

(Btw, the reason this is quite important to me is that I use empty keymaps to rebind Return/Enter to do nothing so that I can avoid the in-game action menu when going through messages using those keys.)

Given that we have an FAQ which advises precisely this ("How do I turn off that annoying Enter menu?", or something like that), it's probably a good idea that we un-break it.

[fizzix]

I actually could not reproduce the incorrect behavior on the Windows7 build. Nevertheless, I've checked your patch and it works also. So I've sent a pull request for it. Hopefully someone can test it out and we can put it in 3.4.1.

[AnonymousHero]

Originally Posted by fizzix

I actually could not reproduce the incorrect behavior on the Windows7 build.

Wow. That's weird -- I wouldn't think that this has any sort of platform-dependence... but perhaps there's an extra "\r" in the .pref file (on Windows)? This would probably be enough to convince the parser that there's actual content there?

[fizzix]

Originally Posted by AnonymousHero

Wow. That's weird -- I wouldn't think that this has any sort of platform-dependence... but perhaps there's an extra "\r" in the .pref file (on Windows)? This would probably be enough to convince the parser that there's actual content there?

Not sure! Regardless, can you test out the current build on github, to make sure that it is fixed. If all is good I'll pull it into the 3.4.x release branch.

edit: The nightlies build on rephial should be updated by now as well.

[AnonymousHero]

Originally Posted by fizzix

Not sure! Regardless, can you test out the current build on github, to make sure that it is fixed. If all is good I'll pull it into the 3.4.x release branch.

edit: The nightlies build on rephial should be updated by now as well.

Well, the github patch looks exactly identical to mine and I've been running master + my patch for a few days, so it should be hunky-dory.