Re: [dev] [st] [PATCH] Fix F28 key definition.

From: Mark Edgar <>
Date: Sat, 28 Dec 2013 14:47:09 +0100

On Wed, Dec 18, 2013 at 8:04 AM, Roberto E. Vargas Caballero
<> wrote:
> I'm going to apply these patches, except the last one, the patch about designators
> use. It is a big table, and having all the values help to understand it.

How does having all the values help to understand a row?

The reason I'm suggesting the patch is that it is currently easy to
lose track of the order of the mode columns because the table is so
large that the column names cannot always be viewed on the same screen
as most of the rows. The keysym, mask, and string columns are easy to
keep track of since the values of those have distinct forms. But
because the three mode columns all share the same form (+1, 0, -1) it
is easy to lose track.

Consider the following row. Is that appkey=+1 or appcursor=+1?

      { XK_KP_Up, XK_ANY_MOD, "\033OA", 0, +1, 0},

Here, it's obvious:

      { XK_KP_Up, XK_ANY_MOD, "\033OA", .appcursor = +1},

It seems that labeling the modes and leaving out the unused (0-valued)
modes makes the table easier to read.

Received on Sat Dec 28 2013 - 14:47:09 CET

This archive was generated by hypermail 2.3.0 : Sat Dec 28 2013 - 14:48:06 CET