This uses the new support introduced in f0f31bc305 in the docs and in
tests/run.sh, removing an useless use of cat/echo.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 78abb4a54c made awesome-client fail with a
non-zero exit code when sending a command that it got from stdin failed.
Commit f0f31bc305 added the possibility to specify
commands to run as arguments to awesome-client. However, the exit code was still
zero even when such a command failed.
This commit makes awesome-client signal errors with its exit code even for code
specified via arguments.
Note that this means that following arguments will not be executed if some
argument fails. I do not know if this is the best behaviour or not, but I am
implementing it like this here due to its simplicity to implement.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Otherwise there is a small, unimportant memory leak. More important is the fact
that later such flags overwrite earlier flags.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This code removes code which could only be hit be running awesome --search '' or
awesome -c ''. In both cases there are many possibilities for weird/invalid
arguments and I don't see why the empty string deserves special treatment.
Note that awesome --search does NOT hit this code, because getopt_long handles
the case of "completely missing" arguments itself.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When you run "awesome --foobar", a warning will be printed (by getopt_long())
and awesome just ignores the invalid argument. That's unusual and weird.
This commit produces an error instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In some languages, invoking commands with command-line arguments is
significantly simpler than setting up pipes for writing to a command's
standard input.
This adds an additional way for sending commands through awesome-client;
so all of these will be equivalent:
$ awesome-client 'awesome.restart()'
$ echo 'awesome.restart()' | awesome-client
$ awesome-client <<<'awesome.restart()'
$ awesome-client
awesome# awesome.restart()
awesome# ^D
$
Note that this sends each command line argument as a separate message
over dbus.
The index was updated on an unordered table. As the elements
order did not match the relative indices once they have been
changed, further calls to set_index produced garbage.
The default taglist didn't notice because it use screen.tags
table index instead of the tag index. A debug using
echo 'for _,t in ipairs(mouse.screen.tags) do
print("INDEX:", _, t.index, t.name) end' | awesome-client
Would have shown two or more elements with the same index. To
debug issues related to tag indices, this bash script can be
enabled:
while true; do
echo 'for _,t in ipairs(mouse.screen.tags) do
assert( _==t.index) end' | awesome-client
sleep 0.5
done
This commit add the last placement function imported from the
Radical module.
It allows to place a wibox/client next to another object. It tries
to find the best fit. It also support wibox widgets.
This is intended for tooltips and menus, but can also be used in
`awful.rules` to place the new client as close as possible to the
focused one without overlap.
The build is no longer aborted when one of the "example tests" produces a
message on stderr. However, on Travis this requirement is still made. This
should catch "bad errors" via Travis while not breaking the build for users.
Fixes: https://github.com/awesomeWM/awesome/issues/821
Signed-off-by: Uli Schlachter <psychon@znc.in>
The same effect could be achieved by modifying $LUA_PATH or with symlinks, but
having a special option to do this seems easier.
Note that the man page translations were generated via Google translate. I'm
looking forward to people submitting correct translations...
Inspired-by: https://github.com/awesomeWM/awesome/pull/485
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently a leftover when it was in .travis.yml, but it still makes
sense to use those env vars instead of calling `git-confog`, which is
not stateless.
[ci skip]
This reverts commit facf676b13.
Using capi.client.focus.screen to decide which screen is focused breaks
a multiscreen setup. At least makes it extremely annoying to use.
In particular, if you have a focused client on screen 1, move the mouse
to screen 2 and launch a new client, the new client appears in screen 1,
since screen.focused reports that current focused screen is 1, not 2
because of the focused client.
Close#1035Fix#1029
blueusername
Akulen
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallée
Fernando Vezzosi
Daniel Hahler
Uli Schlachter
cmertz