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.
This fixes ticket #100, and is best explained using a little example.
Consider the following layout:
+---+---+
| | X |
+---+---+
| X |
+---+---+
Where X marks a window, so you have an empty container in the upper
left, the container on the bottom is snapped to the right. Before
this commit, nothing would happen when focusing "above". After
this commit, the upper window gets focused.
This enables compilation with llvm-clang and thus closes ticket #101.
While it makes the code more ugly, I don’t see a beautiful solution
which would enable us to stay with the more elegant solution of
nested functions and still allow compilation with any other compiler
than gcc.
Thanks to Merovius for doing a proof of concept on this one and
being a driving force behind the idea.
Using RandR instead of Xinerama means that we are now able to use
the full potential of the modern way of configuring screens. That
means, i3 now has an idea of the outputs your graphic driver
provides, which allowed us to get rid of the ugly way of detecting
changes in the screen configuration which we used before. Now, your
workspaces should not be confused when changing output modes anymore.
Also, instead of having ugly heuristics to assign your workspaces
to (the screen at position X or the second screen in the list of
screens) you will be able to just specify an output name.
As this change basically touches everything, you should be prepared
for bugs. Please test and report them!
This fixes many problems we were having with a dynamically growing
array because of the realloc (pointers inside the area which was
allocated were no longer valid as soon as the realloc moved the
memory to another address).
Again, this is a rather big change, so expect problems and enable
core-dumps.
For example, you can create a mode which will let you resize windows
with some easy to use keys. So, instead of binding a combination
of your homerow and modifiers to resize, like this:
bind Mod4+44 resize right +10
bind Mod4+45 resize right -10
...
You can instead define a new mode:
mode "resize" {
bind 44 resize right +10
bind 45 resize right -10
...
bind 36 mode default
}
bindsym Mod4+r mode resize
So, if you press Mod4+r now, your keybindings will be set to the ones
defined in your resize mode above. You can then use your homerow
(without any other modifier) to resize the current column/row and
press enter to go back to the default mode when you are done.
Note that using this option requires you to enable the new lexer/parser
by passing the -l flag to i3 when starting.
Warning: This is not yet thoroughly tested, so be prepared to
encounter some segfaults. Please enable logging and coredumps,
so we can fix bugs quickly.
Using this command, you can limit the amount of columns or rows for
a stacking container. This allows for better usage of screen estate
when using stacking containers with many clients.
Examples:
i3-msg "stack-limit cols 2"
You will now have a stack window which has two columns of windows.
Commands are 'mark' and 'goto'. Both can be used either directly,
like 'mark a' and 'goto a', or interactively (just 'mark'). For
interactive mode, i3-input must be installed and in your PATH.
Before this fix, you could go upwards and select the screen which
was at the rightmost because it also was the one topmost (if all
screen’s top position is equal).
Please test this! Plug in screens, unplug them, use your video projector,
change resolutions, etc.
To use the assignments, use the following syntax:
workspace <number> [screen <screen>] [name]
Where screen can be one of:
<number> (It is not provided that these numbers stay constant, so use with care)
<x>x<y> (Coordinates where the screen starts, so 1280 will be fine to match the
screen right of the main screen if your main screen is 1280 pixels
width. However, 1281 will not match)
<x>
x<y>
Some examples follow:
workspace 1 screen 0
workspace 1 screen 1
workspace 1 screen 1280x0
workspace 2 screen 1280
workspace 3 screen x0
workspace 3 screen 1 www
workspace 4 screen 0 mail
Use bn (normal), bp (1-px), bb (borderless) as commands to change the
border style of the currently focused window. Feel free to use i3-msg
to do this.
