Re: [Boost-bugs] [Boost C++ Libraries] #1201: Regexify the syntax highlighter

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1201: Regexify the syntax highlighter
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-08-26 09:37:27

#1201: Regexify the syntax highlighter
  Reporter: djowel | Owner: mumiee
      Type: Feature Requests | Status: assigned
 Milestone: To Be Determined | Component: quickbook
   Version: Boost 1.34.1 | Severity: Problem
Resolution: | Keywords: documentat ibd boost-doc regular expression lexer regex xpressive quickbook lexer syntax highlighting
Comment (by mumiee):

 Because the above is so terribly formated:[[BR]]

 Syntax idea so far:[[BR]]
 [sourcemode <NAME_OF_MODE> <' '-separated_LIST_OF_MODES>[[BR]]
 The first line defines the start rule, every occurance of a [[BR]]
 rulename inside the regular expressions will treated as a [[BR]]
 reference to the regex attached to that rulename. Hence[[BR]]
 recursion is possible. [[BR]]
 because [] are very common regex characters, we mitght switch to:[[BR]]
 We will probably use xpressive, because it already allows recursion[[BR]]
 and has a parser for strings. We would prefer spirit, if there was a[[BR]]
 "dynamic" spirit, since ebnfs with operator- and eps_p are easier to use
 than lookahead or lookbehind assertions.[[BR]]
 The ' ' separated list of modes should allow reusing existing source
 mode definitions. We might prefix rules of imported regex... [[BR]]

 An untested and incomplete C++ grammar could look like that:[[BR]]
 [sourcemode cpp [[BR]]
 comment "(//[NOT\n]*|/\*.*?\*/)" add_comment_markup[[BR]]
 preprocessor "#\s[NOT\n]*" add_preproc_markup[[BR]]
 keyword "(auto|bool|char|...)(?!\w)" add_keyword_markup[[BR]]
 keyword "(auto|and|and_eq|bool|char|...)(?!\w)" add_keyword_markup[[BR]]
 special "[\~!%&\*()+={\[}\]:;,<\.>?/\|\-]+" add_special_markup[[BR]]
 string "[lL]?\"([NOT\"]|\")*?\"" add_string_markup[[BR]]
 char "[lL]?'([NOT']?)'" add_char_markup[[BR]]
 number .....[[BR]]
 Stuff to decide:[[BR]]
 1) What if the regex defines marks, and grups submatches and so on, should
 every submatch become a parameter to the template. Shall we then omit the
 complete match from the parameter list. Or shall we always first submit
 compelete match then the first to nth submatch, as a parameter...?[[BR]]
 2) Should we implement a kind of binder syntax like in boost.bind, for the
 various matches? That way we would add a kind of substitution like
 rule "\(#\sdefine \)[NOT\n]*" [extendedn_preproc_markup _1.. macro
 contents are

 So "#define PI 3.14126.." would turn into a highlighted:[[BR]]
 "#define macro contents are secrets"[[BR]][[BR]]

 Development currently takes place at:[[BR]][[BR]]

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:56 UTC