Fix workaround for user assigning a meta sequence to a key which has

a dedicated keyboard equivalent (arrows, home/end, page up/down, etc).
Not fully fixable so document the remaining issue in bug 79.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4220 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

BUGS

@@ -5,6 +5,10 @@
   of new if block for subnfunc values (75)
 - New backend code probably does not compile under anything but default options, 
   if that (76)
+- If a user only binds meta sequences to a function like left, right
+  page up/down, insert, and unbinds all other control and F keys for it,
+  nano will do the wrong thing when reading the key which is normally
+  assigned to it (79 - may not be worth fixing)
 
 
 ** Fixed BUGS **

src/global.c

@@ -249,13 +249,26 @@ void add_to_funcs(void *func, int menus, const char *desc, const char *help,
 
 const sc *first_sc_for(int menu, void *func) {
     const sc *s;
+    const sc *metasc = NULL;
 
     for (s = sclist; s != NULL; s = s->next) {
 	if ((s->menu & menu) && s->scfunc == func) {
+	    /* try to use a meta sequence as a last resort.  Otherwise
+	       we will run into problems when we try and handle things like
+	       the arrow keys, home, etc, if for some reason the user bound
+	       them to a meta sequence first *shrug* */
+	    if (s->type == META) {
+		metasc = s;
+		continue;
+	    } /* otherwise it was something else, use it */
 	    return s;
 	}
     }
 
+    /* If we're here we may have found only meta sequences, if so use one */
+    if (metasc)
+	return metasc->seq;
+
 #ifdef DEBUG
     fprintf(stderr, "Whoops, returning null given func %ld in menu %d\n", (long) func, menu);
 #endif