Use our types instead of int/uint32_t in a few places

Signed-off-by: Ran Benita <ran234@gmail.com>
state: fix bad EFFECTIVE check in *_is_active()

This is a regression introduced in ed78fbcb30888cbfc6cd00.
XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is
completely wrong. So test/state shows for example:
    dumping state for LCtrl down:
            group English (US) (0): effective depressed latched locked
            mod Control (2): depressed latched locked
    dumping state for LCtrl + RAlt down:
            group English (US) (0): effective depressed latched locked
            mod Control (2): depressed latched locked
            mod Mod1 (3): depressed latched locked
    dumping state for RAlt down:
            group English (US) (0): effective depressed latched locked
            mod Mod1 (3): depressed latched locked
    dumping state for Caps Lock:
            group English (US) (0): effective depressed latched locked
            mod Lock (1): depressed latched locked
            led Caps Lock (0): active
    dumping state for Alt-Shift-+
            group English (US) (0): effective depressed latched locked
            mod Shift (0): depressed latched locked
            mod Mod1 (3): depressed latched locked
which is bogus.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: don't ignore type argument in xkb_state_mod_*_are_active

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

Signed-off-by: Ran Benita <ran234@gmail.com>
Remove the XKB_NUM_VIRTUAL_MODIFIERS limit

Turn the virtual modifiers arrays in the keymap to a single darray,
which doesn't use this limit. The number of virtual modifiers is still
limited by the size of xkb_mod_mask_t, so we make sure not to go over
that.

Signed-off-by: Ran Benita <ran234@gmail.com>
keysym-utf: make keysym->unicode table a bit smaller

Saves a few kbytes, and unlikely to change.

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: don't allow "none" in LookupModIndex

LookupModMask handles this before calling LookupModIndex, and the only
other user in symbols.c doesn't handle this return value at all.

Signed-off-by: Ran Benita <ran234@gmail.com>
Omit struct '_Name' from non-recursive struct typedefs

Just a pet peeve.

Signed-off-by: Ran Benita <ran234@gmail.com>
vmod: remove merge argument from HandleVModDef

It's unused and unneeded.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: don't needlessly fetch the xkb_key

It's a leftover.

Signed-off-by: Ran Benita <ran234@gmail.com>
vmod: don't allow to add a vmod with the name of a real mod

Otherwise strange thing might ensue.

Signed-off-by: Ran Benita <ran234@gmail.com>
Remove VModInfo for now

VModInfo currently is only used to track which virtual modifiers were
declared in the file which owns the VModInfo. This, in turn, is only
used in ResolveVirtualModifier, which in turn is only used to resolve
the virtualModifier field in an interpret statement (compat.c). In other
words, it is used to ensure that interprets can only use a vmod which
was declared in the same map.

We remove this now, because it doesn't do much and distracts from other
changes; we will later re-add it properly. Specificly, we will make it
so that virtual modifiers are not the exception in that they modify the
keymap directly, instead of keeping the changes in some *Info struct and
commiting them to the keymap at the end of the compilation. (This is bad
because if a vmod is added to the keymap, and then the compilation of
this specific file fails, the change sticks around nonetheless).

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: don't expose LookupModIndex

The Lookup* functions should remain a private implementation detail of
the expr.c file.

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't use shifted virtual modifier masks

Modifier masks can be confusing in some places. For example,
key->vmodmap only contains virtual modifiers, where the first is in
position 0, the second in 1 etc., while normally in a xkb_mod_mask_t the
virtual modifiers start from the 8th (XKB_NUM_CORE_MODS) position. This
happens in some other places as well.

Change all of the masks to be in the usual real+virtual format, and when
we need to access e.g. keymap->vmods we just adjust by
XKB_NUM_CORE_MODS. (This also goes for indexes, e.g.
interpret->virtual_modifier).

This makes this stuff easier to reason about.

Signed-off-by: Ran Benita <ran234@gmail.com>
Keep real and virtual mods in the same table in the keymap

We change the keymap->vmods array into keymap->mods, and change it's
member type from struct xkb_vmod to struct xkb_mod. This table now
includes the real modifiers in the first 8 places. To distinguish
between them, we add an enum mod_type to struct xkb_mod.

Besides being a more reasonable approach, this enables us to share
some code later, remove XKB_NUM_CORE_MODS (though the 0xff mask still
appears in a few places), and prepares us to flat out remove the
distinction in the future. This commit just does the conversion.

Signed-off-by: Ran Benita <ran234@gmail.com>
text: share code for modifiers

Add static common functions which take enum mod_type, and change the
existing ones to use them.

Signed-off-by: Ran Benita <ran234@gmail.com>
text: explicitly take mod_type in mod functions

This essentially "tags" each invocation of the functions with the
modifier type of the argument, which allows for easy grepping for them
(with the aim being, to remove anything but MOD_BOTH).

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: share code for modifier functions

We can make more use of the functions in text.c now and remove some
cruft.

Signed-off-by: Ran Benita <ran234@gmail.com>
Remove now-unneeded mod type annotations

Most of the mod type annotations can now be changed to MOD_BOTH, because
if you pass a mask which can only contain real mods in the first place to
e.g. ModMaskText, then MOD_REAL and MOD_BOTH will give the same result.

In the cases where MOD_BOTH is only ever the argument, we just remove
it. What's left is where it really "matters".

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: unify the real and virtual modifier functions

This again pushes the mod type annotation to the original call site, to
make it easier to grep to see where the real/virtual distinction
matters.

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