nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
gri3-wm/parser-specs/commands.spec

322 lines
7.6 KiB
RPMSpec
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=2:sw=2:expandtab
#
# i3 - an improved dynamic tiling window manager
# © 2009-2012 Michael Stapelberg and contributors (see also: LICENSE)
#
# parser-specs/commands.spec: Specification file for generate-command-parser.pl
# which will generate the appropriate header files for our C parser.
#
# Use :source highlighting.vim in vim to get syntax highlighting
# for this file.
state INITIAL:
# We have an end token here for all the commands which just call some
# function without using an explicit 'end' token.
end ->
'[' -> call cmd_criteria_init(); CRITERIA
'move' -> MOVE
'exec' -> EXEC
'exit' -> call cmd_exit()
'restart' -> call cmd_restart()
'reload' -> call cmd_reload()
'border' -> BORDER
'layout' -> LAYOUT
'append_layout' -> APPEND_LAYOUT
'workspace' -> WORKSPACE
'focus' -> FOCUS
'kill' -> KILL
'open' -> call cmd_open()
'fullscreen' -> FULLSCREEN
'split' -> SPLIT
'floating' -> FLOATING
'mark' -> MARK
'resize' -> RESIZE
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
'rename' -> RENAME
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
'nop' -> NOP
'scratchpad' -> SCRATCHPAD
'mode' -> MODE
state CRITERIA:
ctype = 'class' -> CRITERION
ctype = 'instance' -> CRITERION
ctype = 'window_role' -> CRITERION
ctype = 'con_id' -> CRITERION
ctype = 'id' -> CRITERION
ctype = 'con_mark' -> CRITERION
ctype = 'title' -> CRITERION
Implement urgency flag matcher Currently it supports the following options: "oldest": match the first window that triggered an urgent event "latest": match the last window that triggered an urgent event
2012-01-25 00:00:27 +01:00
ctype = 'urgent' -> CRITERION
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
']' -> call cmd_criteria_match_windows(); INITIAL
state CRITERION:
'=' -> CRITERION_STR
state CRITERION_STR:
cvalue = word
-> call cmd_criteria_add($ctype, $cvalue); CRITERIA
# exec [--no-startup-id] <command>
state EXEC:
nosn = '--no-startup-id'
->
command = string
-> call cmd_exec($nosn, $command)
Implement variable border widths for pixel/normal fixes #325
2012-09-24 01:14:00 +02:00
# border normal|none|1pixel|toggle|1pixel
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
state BORDER:
Implement variable border widths for pixel/normal fixes #325
2012-09-24 01:14:00 +02:00
border_style = 'normal', 'pixel'
-> BORDER_WIDTH
border_style = 'none', 'toggle'
-> call cmd_border($border_style, "0")
border_style = '1pixel'
-> call cmd_border($border_style, "1")
state BORDER_WIDTH:
end
-> call cmd_border($border_style, "2")
border_width = word
-> call cmd_border($border_style, $border_width)
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
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
# layout default|stacked|stacking|tabbed|splitv|splith
# layout toggle [split|all]
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
state LAYOUT:
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
layout_mode = 'default', 'stacked', 'stacking', 'tabbed', 'splitv', 'splith'
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
-> call cmd_layout($layout_mode)
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
'toggle'
-> LAYOUT_TOGGLE
# layout toggle [split|all]
state LAYOUT_TOGGLE:
end
-> call cmd_layout_toggle($toggle_mode)
toggle_mode = 'split', 'all'
-> call cmd_layout_toggle($toggle_mode)
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
# append_layout <path>
state APPEND_LAYOUT:
path = string -> call cmd_append_layout($path)
# workspace next|prev|next_on_output|prev_on_output
# workspace back_and_forth
# workspace <name>
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
# workspace number <number>
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
state WORKSPACE:
direction = 'next_on_output', 'prev_on_output', 'next', 'prev'
-> call cmd_workspace($direction)
'back_and_forth'
-> call cmd_workspace_back_and_forth()
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
'number'
-> WORKSPACE_NUMBER
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
workspace = string
-> call cmd_workspace_name($workspace)
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
state WORKSPACE_NUMBER:
workspace = string
-> call cmd_workspace_number($workspace)
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
# focus left|right|up|down
# focus output <output>
# focus tiling|floating|mode_toggle
# focus parent|child
# focus
state FOCUS:
direction = 'left', 'right', 'up', 'down'
-> call cmd_focus_direction($direction)
'output'
-> FOCUS_OUTPUT
window_mode = 'tiling', 'floating', 'mode_toggle'
-> call cmd_focus_window_mode($window_mode)
level = 'parent', 'child'
-> call cmd_focus_level($level)
end
-> call cmd_focus()
state FOCUS_OUTPUT:
output = string
-> call cmd_focus_output($output)
add comments to src/commands.c
2012-01-27 23:32:40 +01:00
# kill [window|client]
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
state KILL:
kill_mode = 'window', 'client'
-> call cmd_kill($kill_mode)
end
-> call cmd_kill($kill_mode)
add comments to src/commands.c
2012-01-27 23:32:40 +01:00
# fullscreen [global]
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
state FULLSCREEN:
fullscreen_mode = 'global'
-> call cmd_fullscreen($fullscreen_mode)
end
-> call cmd_fullscreen($fullscreen_mode)
# split v|h|vertical|horizontal
state SPLIT:
parser: reorder v/h/vertical/horizontal This eliminates an error message upon split horizontal which did not occur in older i3 versions. The command itself worked just fine.
2012-06-10 17:56:28 +02:00
direction = 'horizontal', 'vertical', 'v', 'h'
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
-> call cmd_split($direction)
# floating enable|disable|toggle
state FLOATING:
floating = 'enable', 'disable', 'toggle'
-> call cmd_floating($floating)
# mark <mark>
state MARK:
mark = string
-> call cmd_mark($mark)
# resize
state RESIZE:
way = 'grow', 'shrink'
-> RESIZE_DIRECTION
state RESIZE_DIRECTION:
Implement resize <grow|shrink> <width|height>, use it in the default config Fixes: #576
2012-04-08 15:59:49 +02:00
direction = 'up', 'down', 'left', 'right', 'width', 'height'
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
-> RESIZE_PX
state RESIZE_PX:
resize_px = word
-> RESIZE_TILING
end
-> call cmd_resize($way, $direction, "10", "10")
state RESIZE_TILING:
'px'
->
'or'
-> RESIZE_TILING_OR
end
-> call cmd_resize($way, $direction, $resize_px, "10")
state RESIZE_TILING_OR:
'ppt'
->
resize_ppt = word
->
end
-> call cmd_resize($way, $direction, $resize_px, $resize_ppt)
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
# rename workspace <name> to <name>
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
# rename workspace to <name>
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
state RENAME:
'workspace'
-> RENAME_WORKSPACE
state RENAME_WORKSPACE:
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
old_name = 'to'
-> RENAME_WORKSPACE_LIKELY_TO
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
old_name = word
-> RENAME_WORKSPACE_TO
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
state RENAME_WORKSPACE_LIKELY_TO:
'to'
-> RENAME_WORKSPACE_NEW_NAME
new_name = word
-> call cmd_rename_workspace(NULL, $new_name)
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
state RENAME_WORKSPACE_TO:
'to'
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
-> RENAME_WORKSPACE_NEW_NAME
state RENAME_WORKSPACE_NEW_NAME:
end
-> call cmd_rename_workspace(NULL, "to")
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
new_name = string
-> call cmd_rename_workspace($old_name, $new_name)
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
# move <direction> [<pixels> [px]]
Bugfix: Correctly parse `move ... workspace *_on_output` The parse spec for `move ... workspace ...` ordered next/prev before next_on_output/prev_on_output causing the parser to match next/prev before next_on_output/prev_on_output. Ticket: http://bugs.i3wm.org/report/ticket/941
2013-01-29 09:05:23 +01:00
# move [window|container] [to] workspace [<str>|next|prev|next_on_output|prev_on_output|current]
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
# move [window|container] [to] output <str>
# move [window|container] [to] scratchpad
# move workspace to [output] <str>
# move scratchpad
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
# move [window|container] [to] [absolute] position [ [<pixels> [px] <pixels> [px]] | center ]
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
state MOVE:
'window'
->
'container'
->
'to'
->
'workspace'
-> MOVE_WORKSPACE
'output'
-> MOVE_TO_OUTPUT
'scratchpad'
-> call cmd_move_scratchpad()
direction = 'left', 'right', 'up', 'down'
-> MOVE_DIRECTION
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
method = 'position'
-> MOVE_TO_POSITION
method = 'absolute'
-> MOVE_TO_ABSOLUTE_POSITION
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
state MOVE_DIRECTION:
pixels = word
-> MOVE_DIRECTION_PX
end
-> call cmd_move_direction($direction, "10")
state MOVE_DIRECTION_PX:
'px'
-> call cmd_move_direction($direction, $pixels)
end
-> call cmd_move_direction($direction, $pixels)
state MOVE_WORKSPACE:
Bugfix: Properly parse commands like “move workspace torrent” (Thanks rasi) fixes #955
2013-02-19 00:27:55 +01:00
'to '
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
-> MOVE_WORKSPACE_TO_OUTPUT
Bugfix: Correctly parse `move ... workspace *_on_output` The parse spec for `move ... workspace ...` ordered next/prev before next_on_output/prev_on_output causing the parser to match next/prev before next_on_output/prev_on_output. Ticket: http://bugs.i3wm.org/report/ticket/941
2013-01-29 09:05:23 +01:00
workspace = 'next_on_output', 'prev_on_output', 'next', 'prev', 'current'
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
-> call cmd_move_con_to_workspace($workspace)
fixes #776 this implements both the "move container to workspace back_and_forth" command and movements to the same workspace when auto_back_and_forth is set. it includes documentation and test suite additions by michael. it also simplifies the workspace_show_by_name function (making use of workspace_get accepting NULL pointers).
2012-09-04 10:51:18 +02:00
'back_and_forth'
-> call cmd_move_con_to_workspace_back_and_forth()
Implement 'move [container|window] to workspace number <number>'
2012-04-08 20:33:46 +02:00
'number'
-> MOVE_WORKSPACE_NUMBER
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
workspace = string
-> call cmd_move_con_to_workspace_name($workspace)
Implement 'move [container|window] to workspace number <number>'
2012-04-08 20:33:46 +02:00
state MOVE_WORKSPACE_NUMBER:
number = string
-> call cmd_move_con_to_workspace_number($number)
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
state MOVE_TO_OUTPUT:
output = string
-> call cmd_move_con_to_output($output)
state MOVE_WORKSPACE_TO_OUTPUT:
'output'
->
output = string
-> call cmd_move_workspace_to_output($output)
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
state MOVE_TO_ABSOLUTE_POSITION:
'position'
-> MOVE_TO_POSITION
state MOVE_TO_POSITION:
'center'
-> call cmd_move_window_to_center($method)
coord_x = word
-> MOVE_TO_POSITION_X
state MOVE_TO_POSITION_X:
'px'
->
coord_y = word
-> MOVE_TO_POSITION_Y
state MOVE_TO_POSITION_Y:
'px', end
-> call cmd_move_window_to_position($method, $coord_x, $coord_y)
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
# mode <string>
state MODE:
mode = string
-> call cmd_mode($mode)
state NOP:
comment = string
-> call cmd_nop($comment)
state SCRATCHPAD:
'show'
-> call cmd_scratchpad_show()