nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
gri3-wm/include/commands_parser.h

33 lines
964 B
C
Raw Normal View History

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
/*
* vim:ts=4:sw=4:expandtab
*
* i3 - an improved dynamic tiling window manager
* © 2009-2012 Michael Stapelberg and contributors (see also: LICENSE)
*
* commands.c: all command functions (see commands_parser.c)
*
*/
Use #pragma once #pragma once is safer and simpler. According to Wikipedia it's supported by all major compilers.
2013-12-29 03:11:50 +01:00
#pragma once
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
Send proper error messages upon parser failures, use yajl for generating command replies Fixes: #693
2012-05-02 22:01:50 +02:00
#include <yajl/yajl_gen.h>
Refactor the interface of commands.c This change has two implications: 1) tree_render() will now be called precisely once for input which consists of multiple commands (like "focus left; focus right"). Also, the caller of parse_command() has to call it. This makes us able to fix tickets such as ticket #608 (where multiple tree_render() calls are noticable). 2) The output of a command is now a JSON array of return values of the individual subcommands. In the case of "focus left; focus right", this is: [{"success":true}, {"success":true}] While this is incompatible with what i3 returned before, the return value of commands was undocumented and therefore not subject to our API stability.
2012-02-07 23:38:21 +01:00
/*
Change the names of parser result structs Change the name of structs CommandResult and ConfigResult to CommandResultIR and ConfigResultIR to show they are an intermediate representation used during parsing.
2014-05-18 06:44:19 +02:00
* Holds an intermediate represenation of the result of a call to any command.
* When calling parse_command("floating enable, border none"), the parser will
* internally use this struct when calling cmd_floating and cmd_border.
Refactor the interface of commands.c This change has two implications: 1) tree_render() will now be called precisely once for input which consists of multiple commands (like "focus left; focus right"). Also, the caller of parse_command() has to call it. This makes us able to fix tickets such as ticket #608 (where multiple tree_render() calls are noticable). 2) The output of a command is now a JSON array of return values of the individual subcommands. In the case of "focus left; focus right", this is: [{"success":true}, {"success":true}] While this is incompatible with what i3 returned before, the return value of commands was undocumented and therefore not subject to our API stability.
2012-02-07 23:38:21 +01:00
*/
Change the names of parser result structs Change the name of structs CommandResult and ConfigResult to CommandResultIR and ConfigResultIR to show they are an intermediate representation used during parsing.
2014-05-18 06:44:19 +02:00
struct CommandResultIR {
Send proper error messages upon parser failures, use yajl for generating command replies Fixes: #693
2012-05-02 22:01:50 +02:00
/* The JSON generator to append a reply to. */
yajl_gen json_gen;
Refactor the interface of commands.c This change has two implications: 1) tree_render() will now be called precisely once for input which consists of multiple commands (like "focus left; focus right"). Also, the caller of parse_command() has to call it. This makes us able to fix tickets such as ticket #608 (where multiple tree_render() calls are noticable). 2) The output of a command is now a JSON array of return values of the individual subcommands. In the case of "focus left; focus right", this is: [{"success":true}, {"success":true}] While this is incompatible with what i3 returned before, the return value of commands was undocumented and therefore not subject to our API stability.
2012-02-07 23:38:21 +01:00
use the new parser by default you can force the old parser with the command line flag --force-old-config-parser-v4.4-only (which will be present in v4.4 only, as the name suggests)
2012-10-08 13:26:42 +02:00
/* The next state to transition to. Passed to the function so that we can
* determine the next state as a result of a function call, like
* cfg_criteria_pop_state() does. */
int next_state;
re-shuffle struct members to save a bit of memory Analysis done with pahole(1).
2013-06-08 15:37:41 +02:00
/* Whether the command requires calling tree_render. */
bool needs_tree_render;
Refactor the interface of commands.c This change has two implications: 1) tree_render() will now be called precisely once for input which consists of multiple commands (like "focus left; focus right"). Also, the caller of parse_command() has to call it. This makes us able to fix tickets such as ticket #608 (where multiple tree_render() calls are noticable). 2) The output of a command is now a JSON array of return values of the individual subcommands. In the case of "focus left; focus right", this is: [{"success":true}, {"success":true}] While this is incompatible with what i3 returned before, the return value of commands was undocumented and therefore not subject to our API stability.
2012-02-07 23:38:21 +01:00
};
Change the names of parser result structs Change the name of structs CommandResult and ConfigResult to CommandResultIR and ConfigResultIR to show they are an intermediate representation used during parsing.
2014-05-18 06:44:19 +02:00
struct CommandResultIR *parse_command(const char *input);