Argument 1142 for lexing right...

Created attachment 165056 [details] [review]
Lexer patch

Utterly untested patch for lexing the whole string.

This patch looks pretty straightforward, but I don't quite understand how it would be used. .token is a token but currently they seem to be private to parser.y (at least git grep  shows something like  RANGE_SEP  only in that file.

Right.  Many tokens are just characters, but for those that aren't and
also are needed outside we need some kind of export mechanism.  We
might get away with a bare minimum.

Most of the characters are combined into single tokens (possibly due to GNM_EXPR_PARSE_UNKNOWN_NAMES_ARE_STRINGS). Currently I am defining  

#define  TOKEN_UNMATCHED_APOSTROPHY 273
#define  TOKEN_PARENTHESIS_OPEN 40
#define  TOKEN_PARENTHESIS_CLOSED 41
#define  TOKEN_BRACE_OPEN 123
#define  TOKEN_BRACE_CLOSED 125
#define  TOKEN_SEPARATOR 269
#define  TOKEN_NAME 258

in gnumeric-expr-entry.c

We clearly need to ensure that this listing matches what is created in parser.c:

#ifndef YYTOKENTYPE
# define YYTOKENTYPE
   /* Put the tokens into the symbol table, so that GDB and other debuggers
      know about them.  */
   enum yytokentype {
     STRING = 258,
     QUOTED_STRING = 259,
     CONSTANT = 260,
     RANGEREF = 261,
     tok_GTE = 262,
     tok_LTE = 263,
     tok_NE = 264,
     tok_AND = 265,
     tok_OR = 266,
     tok_NOT = 267,
     INTERSECT = 268,
     ARG_SEP = 269,
     ARRAY_COL_SEP = 270,
     ARRAY_ROW_SEP = 271,
     SHEET_SEP = 272,
     INVALID_TOKEN = 273,
     tok_RIGHT_EXP = 274,
     tok_LEFT_EXP = 275,
     tok_PLUS = 276,
     tok_NEG = 277,
     RANGE_INTERSECT = 278,
     RANGE_SEP = 279
   };
#endif

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/139.