Implement a new parser for commands. (+test)
On the rationale of using a custom parser instead of a lex/yacc one, see this
quote from src/commands_parser.c:
We use a hand-written parser instead of lex/yacc because our commands are
easy for humans, not for computers. Thus, it’s quite hard to specify a
context-free grammar for the commands. A PEG grammar would be easier, but
there’s downsides to every PEG parser generator I have come accross so far.
This parser is basically a state machine which looks for literals or strings
and can push either on a stack. After identifying a literal or string, it
will either transition to the current state, to a different state, or call a
function (like cmd_move()).
Special care has been taken that error messages are useful and the code is
well testable (when compiled with -DTEST_PARSER it will output to stdout
instead of actually calling any function).
During the migration phase (I plan to completely switch to this parser before
4.2 will be released), the new parser will parse every command you send to
i3 and save the resulting call stack. Then, the old parser will parse your
input and actually execute the commands. Afterwards, both call stacks will be
compared and any differences will be logged.
The new parser works with 100% of the test suite and produces identical call
stacks.
2012-01-14 20:53:29 +01:00
|
|
|
set filetype=i3cmd
|
|
|
|
|
syntax case match
|
|
|
|
|
syntax clear
|
|
|
|
|
|
|
|
|
|
syntax keyword i3specStatement state call
|
|
|
|
|
highlight link i3specStatement Statement
|
|
|
|
|
|
|
|
|
|
syntax match i3specComment /#.*/
|
|
|
|
|
highlight link i3specComment Comment
|
|
|
|
|
|
|
|
|
|
syntax region i3specLiteral start=/'/ end=/'/
|
2012-10-08 13:23:48 +02:00
|
|
|
syntax keyword i3specToken string word number end
|
Implement a new parser for commands. (+test)
On the rationale of using a custom parser instead of a lex/yacc one, see this
quote from src/commands_parser.c:
We use a hand-written parser instead of lex/yacc because our commands are
easy for humans, not for computers. Thus, it’s quite hard to specify a
context-free grammar for the commands. A PEG grammar would be easier, but
there’s downsides to every PEG parser generator I have come accross so far.
This parser is basically a state machine which looks for literals or strings
and can push either on a stack. After identifying a literal or string, it
will either transition to the current state, to a different state, or call a
function (like cmd_move()).
Special care has been taken that error messages are useful and the code is
well testable (when compiled with -DTEST_PARSER it will output to stdout
instead of actually calling any function).
During the migration phase (I plan to completely switch to this parser before
4.2 will be released), the new parser will parse every command you send to
i3 and save the resulting call stack. Then, the old parser will parse your
input and actually execute the commands. Afterwards, both call stacks will be
compared and any differences will be logged.
The new parser works with 100% of the test suite and produces identical call
stacks.
2012-01-14 20:53:29 +01:00
|
|
|
highlight link i3specLiteral String
|
|
|
|
|
highlight link i3specToken String
|
|
|
|
|
|
|
|
|
|
syntax match i3specState /[A-Z_]\{3,}/
|
|
|
|
|
highlight link i3specState PreProc
|
|
|
|
|
|
|
|
|
|
syntax match i3specSpecial /[->]/
|
|
|
|
|
highlight link i3specSpecial Special
|