typedef

Наверное, первое, что неприятно поражает новичка в Emacs — невозможность использовать системные средства для переключения языка ввода. Не в том смысле, что оно не работает. А в том, что переключение на любой отличный от английского язык средствами ОС превращает Emacs в Notepad. Перестают работать все клавиатурные комбинации! Паника!

К счастью, Emacs, как и всякая уважающая себя ОС, имеет собственный механизм переключения языков, кодировок и прочего. И все это даже работает. Одна беда — нельзя повесить переключение и в системе, и в Emacs на одну и ту же клавишу, потому что система в таком случае тоже будет переключаться. А пользоваться разными сочетаниями в Emacs и вне него… Что ж, я долгое время так и поступал. Неудобно.

Итак, задача:

1. Хотим переключаться везде по одной и той же клавише. Причем, чтобы если мы нажимаем эту клавишу в Emacs, использовался его внутренний механизм, в остальных случаях пусть этим занимается ОС.
2. Хотим, чтобы п. 1 работал и в Windows, и в Linux. И желательно чтобы сценарий загрузки был общим.

Первый пункт, исходя из общечеловеческой логики, может быть разрешен двумя путями:

• убедить ОС не переключаться, пока активен Emacs;
• после одновременного переключения и в ОС, и в Emacs, переключить ОС обратно.

Оказывается, первый вариант реализуем в Linux, а второй в Windows. Дальнейшее изложение предполагает, что в качестве универсальной клавиши переключения выбран Caps Lock.

Для Linux палочкой-выручалочкой оказывается сочетание SCIM/iBus и xmodmap. С помощью xmodmap можно переназначить Caps Lock на какое-нибудь неиспользуемое действие, например, F13. Для этого в файл ~/.Xmodmap вписываем строку:

keycode 66 = F13

Число 66 — это код соответствующей клавиши. Скорее всего, у вас будет такой же, но лучше в этом убедиться с помощью утилиты xev.

Дальше убиваем системную переключалку раскладок (без особых зверств), и настраиваем SCIM/iBus на переключение по F13, а затем отключаем переключение для Emacs, вписывая в ~/.Xdefaults строку:

Emacs*useXIM:false

Теперь остается только подправить стартовый сценарий Emacs (.emacs или init.el), вставив туда:

(global-set-key [f13] 'toggle-input-method)

Выходим из сеанса, входим обратно, тратим еще пару часов на доработку напильником, и все заработает. Для Linux это все. Я намеренно опустил некоторые подробности про настройку SCIM/iBus, поскольку времена меняются, и старые инструкции становятся устаревшими. А тут я как бы не причем: «настройте iBus на переключение по F13» еще долго не устареет. В конце концов, гугл никто не отменял. Идея использовать SCIM и его аналоги не новая, об этом много где можно прочитать.

В Windows такой фокус не пройдет, но зато один вдумчивый камрад предложил очень изящное решение (ссылка не работает?..), которое упомянуто выше: после переключения вернуть системную раскладку обратно. (Для установки Caps Lock в качестве клавиши переключения системной раскладкой нужно воспользоваться чем-то вроде lswitch или лезть в реестр.)

Теперь остается только вооружиться переменной system-type, и получим сценарий, который кроссплатформенно решает нашу задачу:

(if (eq system-type 'windows-nt)
    ((defvar safe-language-change-flag nil)
     (defun safe-language-change ()
       (interactive)
       (setq safe-language-change-flag (not safe-language-change-flag))
       (when safe-language-change-flag
         (toggle-input-method)
         (w32-toggle-lock-key 'capslock)))
     (global-set-key (kbd "<language-change>") 'safe-language-change))
  (global-set-key [f13] 'toggle-input-method))

Правда, в случае запуска в натуральной консоли проблема все еще остается.

(1 голосов, средний: 5,00 из 5)

 Loading ...

С новым годом, кстати.

Настройка Emacs — это определенно то дело, которым стоит заниматься линуксоидам в Windows (после сборки чего-нибудь из исходников, разумеется). Замечательно успокаивает нервы и нормализует давление.

Что бы там ни говорили, а Emacs невыгодно отличается от своих аналогов долгим временем начальной загрузки, особенно если в процессе оной грузится пара десятков дополнительных модулей. Но если для открытия файлов, скажем, *.el, назначить файл runemacs.exe редактором по умолчанию, то попытка открыть несколько файлов приведет к открытию равного количества экземпляров Emacs, со всеми вытекающими задержками и издержками. Мы же хотим, чтобы было как в Notepad++: редактор запускается один раз, и дальше все файлы открываются в нем.

Как сказал один емаксер, «учитесь любить Emacs Server». Учимся:

1. типы файлов, которые хотим открывать Emacs’ом, ассоциируем с %EMACSDIR%\bin\emacsclientw.exe;
2. создаем переменную окружения ALTERNATE_EDITOR="%EMACSDIR%\bin\runemacs.exe";
3. в начало файла .emacs (или init.el, у кого что) вставляем:
   # run emacs server
(server-start)

Теперь когда мы открываем файл, emacsclientw пытается найти запущенный Emacs-сервер. Если не находит, обращается к альтернативному редактору (runemacs), который открывает файл и запускает сервер. Если же сервер уже запущен, то файл просто открывается в новом буфере.

(2 голосов, средний: 5,00 из 5)

 Loading ...

Установил я как-то Windows 7, и зело он мне приглянулся. Пожалуй, из всего, что я видел, здесь самый удобный интерфейс и самая высокая работоспособность «из коробки» (правда, я не пробовал еще MacOS и всякие маргинальные клавиатурно-ориентированные иксовые оболочки вроде xmonad). И GUI визуально шустрее, чем на моей Федоре. Так что на данный момент «господин назначил Windows любимой осью», и пингвинов загружает только по необходимости или нестерпимому зову сердца.

Чем занимается линуксоид, обретя свежую винду? Конечно же, собирает что-нибудь из исходников! Вот я и решил собрать себе последнюю Qt, да не просто собрать (этак можно MinGW прикрутить и спать спокойно), а так, чтобы почти вся разработка происходила в Visual Studio, и компилятор использовался местный, а не портированный. И чтоб отладка тоже из IDE.

Ну что ж, дело нехитрое:

1. качаем Qt и устанавливаем ее, скажем, в C:\qt\2009.05;
2. на всякий случай копируем в C:\qt\4.6;
3. устанавливаем переменные окружения:
   QTDIR=C:\Qt\4.6\qt;
   QMAKESPEC=win32-msvc2008;
   добавляем C:\Qt\4.6\qt\bin в Path;
4. дистрибутив версии 4.6 содержит забытые авторами временные файлы, которые приводят к ошибкам при сборке (настоящий opensource не собирается с первого раза, но зато всегда можно найти ответ на официальном сайте), поэтому нужно удалить файлы:
   C:\Qt\4.6\qt\src\script\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\script\tmp\moc\release_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\release_shared\mocinclude.tmp
   будем надеяться, что в следующих релизах эта ошибка будет исправлена;
5. запускаем Visual Studio, и из нее консоль (Tools ? Visual Studio 2008 Command Prompt);
6. переходим в C:\Qt\4.6\qt;
7. запускаем configure, отвечаем на его вопросы; начнется подготовка к сборке, которая продлится минут 5-10;
8. запускаем nmake, начнется сборка, которая продлится несколько часов (есть смысл оставить на ночь); в ходе сборки будет куча предупреждений, но не стоит принимать это близко к сердцу, главное чтобы процесс сборки не завершился сообщением об ошибке;
9. закрываем Visual Studio, качаем и устанавливаем add-in;
10. запускаем Visual Studio, идем в Qt ? Qt Options и указываем там версию вместе с путем к установленному Qt;
11. C:\Qt\2009.5 можно стирать;
12. все.

Незнание пункта 4 стоило мне нескольких часов потраченного напрасно времени, которое мои читатели теперь смогут потратить более продуктивно. Благодарности принимаются в произвольной форме.

Если ставить LGPL-версию Qt, то Qt Designer не будет интегрирован в VS, а запустится отдельно при открытии UI-файла. Это, конечно, неудобство, но не критичное.

(4 голосов, средний: 5,00 из 5)

 Loading ...