Commit Graph

19 Commits

Author SHA1 Message Date
Avi Halachmi (:avih) 3abb23d70f command: don't hardcode commands list to be repeatable
Previously, a list of commands was always considered repeatable.

This behavior was added at 6710527a (and moved around since then),
in order to fix #807 (impossible to make a repeatable list).

The problem was that a list doesn't have the normal repeatability
flags and so it was never repeatable, so it was hardcoded to be
repeatable instead. Presumably it was deemed good enough.

However, this made it impossible to have a non-repeatable list.

This commit changes the behavior so that a list repeatability is
that of the first command at the list.

This way, any list can be made either repeatable or non-repeatable
using the following idiom (e.g. at input.conf), based on the fact
that the "ignore" command is not repeatable by default:

  x            ignore; cmd1...; cmd2...   # non-repeatable
  y repeatable ignore; cmd1...; cmd2...   # repeatable

Fixes #7841
2021-08-17 22:45:39 +03:00
Avi Halachmi (:avih) 9f6cbf3a4d input: arguments quoting: support single-quotes
Users expect single quotes to work when the value includes literal
backslashes or double-quotes (or as general quoting like in shell).

The updated docs also include some previously-missing notes:
- newline is only supported in double quotes.
- adjacent (quoted) arguments don't join into one.

Supporting mixed quoting (adjacent quoted strings) would make
mpv's parsing more complete, but would require delicate effort of
larger scope, for two reasons:
- We'd need to also support escaping outside of quotes and do our
  best about backward compatibility.
- The parsed value can either be a substring of the input or
  a newly-allocated string, which would be delicate when joining.

Not critical to add right now.
2021-07-30 09:52:34 +03:00
Avi Halachmi (:avih) 73c9509720 input: argument custom quotes: use ` instead of !
Custom quotes were added in 4f129a3e and began with !, however, this
required quoting "!reverse" (used for the cycle-values command), which
is inconvenient, and was not taken into account when ! was chosen for
custom quotes. Also, ` is more natural for quoting than !.

This does break backward compatibility with the earlier form of custom
quotes, but at least we didn't make a release yet since custom quotes
were added (the last release - 0.33[.1] doesn't support it).
2021-07-30 09:52:34 +03:00
Avi Halachmi (:avih) 4f129a3eca input.conf syntax: support custom quotes !XstringX!
Where X is any ASCII char chosen by the user. An argument is only
interpreted as custom-quoted if it starts with '!' and the line doesn't
end right after it. Custom quotes don't interpret backslash-escape.

This change only affects command arguments which mpv parses (not array
commands), and not tokens before the arguments (where applicable - key
name, input section, command prefixes, command name).
2020-12-31 12:54:33 +02:00
wm4 2567997ecf input: log commands with parameter names 2020-02-19 16:25:18 +01:00
wm4 da913998d3 input: fix cycle 2nd argument stringification
Triggered the fallback code that formatted the argument as "(NULL)".
2020-01-19 20:53:26 +01:00
wm4 4b168bcda3 input: escape command parameters when logging
Some complex commands (like commands generated by scripts to define key
bindings or the OSD overlay command) contain new lines, which "corrupts"
logging.

Fix this by escaping the parameters C-style. Abuse the JSON writer for
this, which already has code to vaguely produce C-style escapes.

At first I considered stripping the quotes, but then I thought it's
actually a good idea to leave them in, as it makes things clearer.

Follows an idea by avih.
2020-01-12 01:04:33 +01:00
wm4 2dc6b27ee7 input: export input.conf comments ot input-bindings property
This is supposed to turn input.conf comments into inline documentation.
Whether this will be useful depends on whether there'll be a script
using this field.

This changes a small aspect of input.conf parsing fundamentally: this
attempts to strip comments/whitespace from the command string, which
will later be used to generate the command when a key binding is
executed. This should not have any negative effects, but there could be
unknown bugs. (For some reason, every command is parsed when input.conf
is parsed, but it still only stores the string for the command. I guess
that saves some minor amount of memory.)
2019-11-23 01:18:49 +01:00
wm4 6e0e39b79f input: change mp_cmd.original from bstr to cstr
No reason to have this as bstr, just makes everything more complex.

Also clear mp_cmd.sender when it's copied. Otherwise it would be a
dangling pointer. Apparently it's never set to non-NULL in this
situation, but this is cleaner anyway.
2019-11-23 01:18:49 +01:00
wm4 21f2468d67 input: add text produced by key to script key events
Particularly for "any_unicode" mappings, so they don't have to
special-case keys like '#' and ' ', which are normally mapped to
symbolic names for input.conf reasons. (Though admittedly, this is a
pretty minor thing, since API users could map these manually.)
2019-11-22 01:15:08 +01:00
wm4 b3968ecf05 input: remove now unused "abort command" and cancel infrastructure
The previous commit removed all uses.
2018-05-24 19:56:35 +02:00
wm4 0a7a4779a3 input: slightly improve --input-cmdlist output
Output argument names, whether varargs are used, and indicate optional
arguments correctly (instead of only half of them).
2018-05-24 19:56:34 +02:00
wm4 332907e1d7 command: give named arguments to almost all commands
Before this change, only 1 command or so had named arguments. There is
no reason why other commands can't have them, except that it's a bit of
work to add them.

Commands with variable number of arguments are inherently incompatible
to named arguments, such as the "run" command. They still have dummy
names, but obviously you can't assign multiple values to a single named
argument (unless the argument has an array type, which would be
something different). For now, disallow using named argument APIs with
these commands. This might change later.

2 commands are adjusted to not need a separate default value by changing
flag constants. (The numeric values are C only and can't be set by
users.)

Make the command syntax in the manpage more consistent. Now none of the
allowed choice/flag names are in the command header, and all arguments
are shown with their proper name and quoted with <...>.

Some places in the manpage and the client.h doxygen are updated to
reflect that most commands support named arguments. In addition, try to
improve the documentation of the syntax and need for escaping etc. as
well.

(Or actually most uses of the word "argument" should be "parameter".)
2018-05-24 19:56:34 +02:00
wm4 1aae88b487 input: add glue code for named arguments
Named arguments should make it easier to have long time compatibility,
even if command arguments get added or removed. They're also much nicer
for commands with a large number of arguments, especially if many
arguments are optional.

As of this commit, this can not be used, because there is no command yet
which supports them. See the following commit.
2018-05-24 19:56:34 +02:00
wm4 b440f6dfb3 command: add infrastructure for async commands
This enables two types of command behavior:

1. Plain async behavior, like "loadfile" not completing until the file
   is fully loaded.
2. Running parts of the command on worker threads, e.g. for I/O, such as
   "sub-add" doing network accesses on a thread while the core
   continues.

Both have no implementation yet, and most new code is actually inactive.
The plan is to implement a number of useful cases in the following
commits.

The most tricky part is handling internal keybindings (input.conf) and
the multi-command feature (concatenating commands with ";"). It requires
a bunch of roundabout code to make it do the expected thing in
combination with async commands.

There is the question how commands should be handled that come in at a
higher rate than what can be handled by the core. Currently, it will
simply queue up input.conf commands as long as memory lasts. The client
API is limited by the size of the reply queue per client. For commands
which require a worker thread, the thread pool is limited to 30 threads,
and then will queue up work in memory. The number is completely
arbitrary.
2018-05-24 19:56:34 +02:00
wm4 dc00566963 command: handle list commands like normal commands
Pretty annoying.
2018-05-24 19:56:33 +02:00
wm4 88498bcc92 input: rename weirdly named function 2018-05-03 01:20:01 +03:00
wm4 9fa0e6bf6a input: merge cmd_list.c with cmd.c
It doesn't really make sense to keep a separate cmd_list.c file, which
does _not_ contain a command list, but only a few minor helper
functions.
2018-05-03 01:20:01 +03:00
wm4 e5f884e68c input: rename cmd_parse.c to cmd.c
Done separately from the cmd.h rename to avoid issues with git being bad
at tracking mixed content and filename changes.
2018-05-03 01:20:01 +03:00