Хотя да, извините, вижу, вы на это и ссылаетесь. Этот пункт различается в зависимости от версии GPL. Если это вторая версия, то плагин можно лицензировать под любой лицензией. Третья версия настаивает на GPL.
Да сам уже запутался :) Обычно те с alt, хотя, в принципе, никто не мешает назначить их на любую комбинацию, в т.ч. и на одну клавишу. Да, все-таки dead keys.
А как проще? Чтобы проверить соответствие грамматике, нужно описание грамматики, тут никуда не деться. Разве что упрощенную грамматику описать, а то там, я смотрю, вплоть до callback'ов :) Для XML вроде как есть инструменты, составляющие схему по образцу (хотя затруднюсь их назвать), но для JSON надо писать вручную. Если схема есть, сама проверка — просто вызов функции.
Разумнее трезво оценивать шансы такой ошибки. Если сервер ваш и клиент ваш вполне можно установить больший уровень доверия. Или если сервер не ваш, но из документации видно, что разработчики понимают проблему и дают, скажем, версионированный API.
Меня, кстати, смутила ваша «не валидация» — ведь проверка соответствия структуры известной схеме и называется валидацией. Только сейчас сообразил, что, говоря «не валидация», вы имели в виду «проверка не данных, а структуры». По аналогии с XML сейчас таких инструментов много и для JSON, JSON Schema та же, ссылки вам дали.
Ну Артемий в своем репертуаре. Видите ли, проявлять фантазию здесь только хуже. Как говорят дизайнеры интерфейсов, don't do it original, do it right, а у вас выходит ровно наоборот.
Лебедев придумал удачное мероприятие, удачно назвал его словом «фуршет», и популяризовал его в своем блоге. Теперь все знают, что такое «фуршет» в контексте социальных сетей. Другое сообщество хочет провести такое же мероприятие. Такое же. Надо дать людям понять, что оно такое же. Как? Ну конечно же, самое лучшее — назвать его иначе. А в комментариях объяснять, что это как фуршет у Лебедева, только мы решили назвать его по-своему. Чтобы никто не догадался. Замечательно. Назовите тогда его «Операция Ы», это как раз подойдет.
IMHO, достаточно проверить это unit-тестом на сервере (если это ваш сервер), а в приложении проверять бизнес-логику. Проверить, может быть, одно поле с типом ответа, если оно есть, конечно. Проверять входной JSON имеет смысл когда это публичный API, куда данные может слать кто угодно. Если данные шлет только один известный отправитель, разумнее положиться, что он шлет их правильно. Хотя зависит от отправителя, конечно :) если он ненадежен, то да.
Если вы под Windows пишете, то в Win32 это будет GetTextExtentPoint32. Насколько я понимаю, нужно предварительно настроить device context, который идет первым параметром (шрифт, размер, наверное разрешение и т. п.), а уж затем измерять. Из шрифтов считывать тоже можно, но тут уже вроде как все готово.
