bind-key b open-in-browser fails in article view

[rnkn]

Newsbeuter version (copy from newsbeuter -v):

newsbeuter 2.9 - http://www.newsbeuter.org/
Copyright (C) 2006-2010 Andreas Krennmair

newsbeuter is free software and licensed under the MIT/X Consortium License.
Type `newsbeuter -vv' for more information.

Compilation date/time: Sep 27 2016 05:30:27
System: Darwin 16.6.0 (x86_64)
Compiler: g++ 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
libcurl: libcurl/7.51.0 SecureTransport zlib/1.2.8 (compiled with 7.49.1)
SQLite: 3.19.3 (compiled with 3.14.2)
libxml2: compiled with 2.9.4

Steps to reproduce the issue:

1. add bind-key b open-in-browser to config
2. launch newsbeuter
3. navigate to an article
4. press b

Other info you think is relevant:
Any other key works, including B. Just b fails... Weird.

I've also tried adding bind-key b open-in-browser article.

[Minoru]

Congratulations! You've discovered a bug that has been with us for a decade. In short, the b key is hard-coded to mean "page up" in article and help dialogs. This can't be fixed in 2.9, sorry.

And fixing it for 2.10 turned out to be harder than I thought. (What follows is mostly notes to myself.)

• Bindings for arrow keys, PgUp, PgDown, Home and End aren't handled in Newsbeuter itself—we delegate this to STFL.
• The method above asks keymap for just one key for each operation (that's just how keymap::getkey() works.) This means we can't readily bind both PgUp and "b" to pageup operation.
• keymap::getkey() has an inconvenient contract here: when asked about context X, it will respond only about this particular context, even if there's a suitable binding in "all". We'd rather have it check X and if nothing's found there look into "all".

keymap needs a slight, backwards-compatible redesign to fix all this.

[Minoru]

Pushed some sketches to bugfix/580-cant-bind-b, will pick it up some other time.

[rnkn]

Interesting. Thanks for investigating.