Move ISEMPTY to utils.h

Signed-off-by: Ran Benita <ran234@gmail.com>
Allocate xkb_component_names on stack

Instead of malloc'ing it as well. Also improve the error handling.

Signed-off-by: Ran Benita <ran234@gmail.com>
Organize xkbcomp/ header files

Various non-functional changes:
- Re-add keycodes.h and move some stuff there.
- Add parser-priv.h for internal bison/flex stuff.
- Don't include headers from other headers, such that file dependencies
  are immediate in each file.
- Rename xkbcomp.h -> ast.h, parseutils.{c,h} -> ast-build.{c,h}
- Rename path.{c,h} -> include.{c,h}
- Rename keytypes.c -> types.c
- Make the naming of XkbFile-related functions more consistent.
- Move xkb_map_{new,ref,unref} to map.c.
- Remove most extern keyword from function declarations, it's just
  noise (XKB_EXPORT is what's important here).
- Append XKBCOMP_ to include guards.
- Shuffle some code around to make all of this work.

Splitting this would be a headache..

Signed-off-by: Ran Benita <ran234@gmail.com>
rulescomp: remove bad failtests

Since we now handle empty model/layout, the last couple of tests should
not fail. The reason they do is bacause they try to use a non-existent
"base" rules file. When the file is brought in these tests do not fail.
Since we already test for non-existent rules file, we can remove them,
and refine the other tests a bit.

Signed-off-by: Ran Benita <ran234@gmail.com>
types: add "Effects on keymap" to overview

Signed-off-by: Ran Benita <ran234@gmail.com>
action: convert action field type to enum

We can also hide the ActionInfo definition inside action.c.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: add general overview

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: small changes

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: ignore "locking" field in sym interprets

This field is used in conjunction with key behaviors, which we don't
support since c1ea23da5. This is also unused in xkeyboard-config.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove dead NoAutomatic code

The xkblib spec, table 7.1 (indicators), says:
XkbIM_NoAutomatic: Xkb does not automatically change the value of the
                   indicator based upon a change in the keyboard state,
                   regardless of the values for the other fields of the
                   indicator map.

xkbcomp (the real one) never actually implemented a way for an indicator
statement to set this flag, so it's just dead unused code. We definitely
don't want to implement it ourselves, so remove any mention of it.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: ignore "index" field in indicator statements

The current code allows to set the "index" field in an indicator
statment's body. This would bind the indicator to the specified index,
instead of by name (which was declared previously in xkb_keycodes).
Doing this is a bad idea, for the same reasons as in 3cd9704, and is
also happily not used anywhere.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: get rid of BindIndicators

Now that 1fba6189e67 removed support for binding indicator maps by index
instead of name, we can remove some more magic which happens now: if an
indicator map specifies an indicator name which was not previously
declared in a 'indicator 5 = "Caps Lock"'-like statement in
xkb_keycodes, we can just look at the next free index and assign it.

This also allows us to use a darray for the LEDInfo's instead of a list.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: ignore "group" (compatibility) statements

Group compatibility statements are like the following:
    group 3 = AltGr;
This currently results in:
    keymap->groups[2].mask = <real mod mapped from AltGr vmod>
And we don't do any thing with this value later. The reason it exists in
XKB is to support non-XKB clients (i.e. XKB support disabled entirely in
the server), which do not know the concept of "group", and use some
modifier to distinguish between the first and second keyboard layouts
(usually with the AltGr key). We don't care about all of that, so we can
forget about it.

One artifact of this removal is that xkb_map_num_groups no longer
works, because it counted through keymap->groups (this wasn't entirely
correct BTW). Instead we add a new num_groups member to the keymap,
which just hold the maximum among the xkb_key's num_groups. This also
means we don't have to compute anything just to get the number of
groups.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: ignore "ledDrivesKbd" in indicator statements

We don't support it, as mentioned in the README, so we should stop
processing it and print a message about it.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: ignore "allowExplicit" in indicator statements

Using !allowExplicit sets the XkbIM_NoExplicit flag of the indicator,
which means that an XKB client cannot change the state of the indicator
using e.g. XkbSetNamedIndicator().
We do not support changing the state of an indicator; furthermore doing
it is probably only useful in conjunction with led-drives-keyboard
behavior, which we also do not support. This is because setting an
indicator without led-drives-keyboard would make the indicator and the
modifier/group it's bound to to get out of sync.

We can re-add this if we need this info.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove "flags" field from xkb_indicator_map

We don't set this field any more.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: use darray instead of list for interps

No need for a list here.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: disallow changing global defaults from within an interpret

It's currently possible to write something like this:
    interpret Num_Lock+Any {
        virtualModifier = NumLock;
        action = LockMods(modifiers=NumLock);
        !indicator.allowExplicit;
    };
The final statement has the same effect as writing it in the global file
scope, which changes the default indicator (which all subsequent
indicators start off as). This very strange and also unused; if someone
does it he probably expects it to affect only the local scope, and he
might then get unexpected behavior. So don't allow it.

Also, HandleInterpVar is clearly a misnomer (as it can also change
indicator defaults) so rename it.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: only compute 'bool report' once

Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp: seperate keymap-copying code from Compile functions

Signed-off-by: Ran Benita <ran234@gmail.com>