[PATCH libxkbcommon 1/2] makekeys: add all symbols converted to lower-case

[Ran Benita]

On Tue, Oct 02, 2012 at 11:07:11AM +0200, David Herrmann wrote:
> On Tue, Oct 2, 2012 at 9:37 AM, Ran Benita <ran234 at gmail.com> wrote:
> > I like the idea, and it seems to work.
> >
> > First, one thing that's easy to miss, this should work:
> >     assert(test_string("xf86_switch_vt_5", XKB_KEY_XF86Switch_VT_5));
> > Have a look at src/keysym.c, it treats the "XF86_" case specially.
> 
> Argh, I overlooked that. Anyway, that's as easy as trying "xf86", too.
> I will add it.
> 
> > Second, I think that in the keymap files themselves (xkb_symbols etc.)
> > we should always do case-sensitive lookup, this would otherwise lead to
> > ambiguity, and the original xkbcomp won't be able to parse these files,
> > for no particularly good reason. So LookupKeysym() in xkbcomp/symbols.c
> > needs to adapt as well, e.g. by comparing to keysym_get_name. If it can
> > be made more efficient such that it doesn't need the extra lookup +
> > compare, that's even better.
> 
> That was my main concern, too. The current approach just makes any
> lower-case lookup succeed. So I was wondering whether converting this
> whole mess to "gperf" would be acceptable? I would then create two
> tables, a case-sensitive and a lower-case table.
> We can then decide, whether we add a flag to xkb_keysym_from_name() or
> whether we introduce a separate xkb_keysym_from_casename() or
> something like that (adj. strcasecmp()).
> 
> This would preserve the semantics of xkb_keysym_from_name(), which is
> probably what we want(?).

Yes, that sounds good to me. It would be nice to get rid of makekeys.

> > Also, this probably warrants a note in the xkb_keysym_from_name()
> > documentation, explaining how to use it for a case-sensitive and
> > case-insesitive lookup. I actually think that adding a flag to control
> > this would be best (which would break ABI/API if done directly), but
> > don't mind much.
> 
> I prefer the flags argument, too.
> 
> > Finally, some minor comments below.
> 
> Thanks for the code-review. But I think I might just try gperf to
> replace that unmaintainable "makekeys" program. Any objections?

I have used gperf successfully before, it works quite well. We could also
use it for some other stuff, later.

Ran