Русская планета Emacs

Часто приходится видеть, как новички пробуют Common Lisp и потом жалуются, что с ним невозможно нормально работать. Как правило, это происходит из-за того, что они не понимают как настроить себе процесс, обеспечивающий тот самый "быстрый отклик" от среды разработки, когда ты поменял функцию, скомпилировал её и изменения тут же начали использоваться внутри уже "бегущей" прогрммы без её перезапуска.

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

(оригинал: ReanGDblog)
Я часто пишу заметки о Emacs, в формате: скопируйте вот эти строки подкорректируйте под себя, вставьте в конфиг, установите ещё вот этот плагин и т.п. Сегодня решил выйти на "новый уровень" и сделал полноценный пакет для Emacs и что бы нанести пользу максимально большой аудитории - разместил его в melpa. Конечно подготовить его несколько сложнее, чем просто пример конфига для блога, но для меня это своеобразное возвращение долгов за используемые мной open-source решения.

Начну с описания проблемы. Для компиляции проектов обычно используют стандартный модуль compile. Если вкратце то для его настройки нужно для интересующего вас режима переопределить локальную переменную compile-command командой, которую модуль compile выполнит при компиляции. Допустим для "c++-mode" она может быть вот такой:

make --no-print-directory -C 

Проблема подхода в том, что одной команды не хватает, часто помимо компиляции требуется ещё запуск тестов, компиляция в release\debug, запуск скомпилированного кода и т.п. Как вариант решения предлагают создавать для каждого режима свой набор функций, по одной на каждый подобный use case, где будет вызываться "compile" с нужными параметрами и потом вешать их на горячие клавиши. Это мягко говоря не удобно, поскольку все простые сочетания давно заняты, а запоминать 5-6 новых пальцедробительных не хочется.

Мне кажется удобным решением было бы при компиляции показывать меню со всеми вариантами действий, что собственно я и реализовал, выглядит это вот так:

(require 'multi-compile)

(setq multi-compile-alist '(
    (rust-mode . (("rust-debug" . "cargo run")
                  ("rust-release" . "cargo run --release")
                  ("rust-test" . "cargo test")))
    ))

M-x package-install multi-compile

(setq multi-compile-alist '(
    (c++-mode . (("cpp-run" . "make --no-print-directory -C %make-dir")))
    (rust-mode . (("rust-debug" . "cargo run")
                  ("rust-release" . "cargo run --release")
                  ("rust-test" . "cargo test")))
    ))

• "%path" - "/tmp/prj/file.rs" - полный путь к открытому файлу.


• "%dir" - "tmp/prj" - директория, где он лежит.


• "%file-name" - "file.rs" - имя текущего файла.


• "%file-sans" - "file" - имя без расширения.


• "%file-ext" - "rs" - расширение файла.


• "%make-dir" - "tmp" - просматривается вся иерархия директорий текущего файла и возвращается та, в которой лежит "Makefile".

(setq multi-compile-alist '(
    ("\\.txt\\'" . (("text-filename" . "echo %file-name")))
    (c++-mode . (("cpp-run" . "make --no-print-directory -C %make-dir")))
    (rust-mode . (("rust-debug" . "cargo run")
                  ("rust-release" . "cargo run --release")
                  ("rust-test" . "cargo test")))
    ))

;;(setq multi-compile-completion-system 'ido)
(setq multi-compile-completion-system 'helm)
;; (setq multi-compile-completion-system 'default)

В арсенале Emacs Lisp разработчика доступна весьма неплохая коллекция инструментов для тестирования: evm, ert, ecukes, Cask, Travis CI и многое-многое другое.

Сегодня я рад анонсировать undercover.el – новую библиотеку, рассчитывающую покрытие тестами файлов вашего Emacs Lisp проекта и визуализирующую результат с помощью сервиса Coveralls.

Добавить undercover.el в ваш проект очень просто:

• Добавьте свой репозиторий в Coveralls.

• Добавьте undercover.el в Cask файл проекта:

1
2
3
4
5
6
7

(source gnu)
(source melpa)

(package-file "awesome-package.el")

(development
  (depends-on "undercover"))

• Перед тем как загрузить ваш проект для тестирования (например, в файле test/test-helper.el, если вы используете ert-runner), укажите, для каких файлов будет выполняться проверка покрытия тестами:

1
2
3
4
5

(require 'undercover)

(undercover "*.el" "awesome-extensions/*.el" (:exclude "*-test.el"))

(require 'awesome-package)

• Все! При следующей сборке проекта в Travis CI отчет по покрытию тестами будет автоматически сформирован и отправлен.

Божидар Батсов на днях стартовал Emacs Lisp Style Guide. Присоединяйтесь!

Примерно раз в год я возвращаюсь к работе над некоторыми C/C++ проектами. И каждый раз я сталкиваюсь с неудобствами работы CEDET + EDE. Сначала я попробую описать свои невзгоды, а в конце предложу свой вариант сделать жизнь чуточку лучше. Комментарии приветствуются.

Какова вообще задача использовать EDE? Я хочу указать где-то все зависимости для конкретного проекта и передать эту информацию в semantic для навигации по коду и авто дополнений. И есть (по-моему здравое) желание не смешивать эту информацию для различных проектов. По-идее большего от EDE мне не надо. Ну может еще команду для сборки проекта добавить. Хотя предпочитаю делать подобное в отдельно взятой консоли. Итак, что нам предлатает Emacs Development Environment.

Пара слов про проекты по-умолчанию (то что создается с помощью ede-new). Больше всего меня бесит настройка через customize-подобный интерфейс. Им вообще не пользоваться для настройки Emacs'а в принципе. Если пойдешь сам что-то править в EDE файле, то точно натолкнешься на беду. Как минимум придется перезапускать Emacs или пересоздавать проект. Кроме того, либо я что-то потерял, либо в проекте по-умолчанию нельзя указать список include папок. Смысла в данном типе EDE-проекта на мой взгляд нет. Можно видимо использовать его для генерации make-файлов, но как показывает практика их писать и поддерживать лучше самому. Automake и подобное вам в помощь.

Также с помощью EDE можно добавить и работать с некоторыми существующими проектами. Например, есть проекты для C/C++ (ede-cpp-root-project), Java (ede-java-root-project) и другие. В них как раз можно указать внешние зависимости, и Semantic с переменным успехом их обрабатывает. Но есть одно но: почему-то эти настройки нельзя положить в Project.ede файл для полного счастья.

Видел такое решение: указать настройки всех проектов в конфигурационных файлах Emacs. Это мне тоже не нравится. Моя Emacs конфигурация все пухнет и пухнет, как я не пытаюсь ее аккуратно структурировать. Если еще там будет информация о всех проектах жизнь станет ужасна.

Была у меня идея положить все настройки в .dir-locals.el. Но тут мы сталкиваемся с проблемой множественного создания одного и того же проекта для каждого открытого файла. По-идее можно написать всю обработку этого случая внутри .dir-locals.el, но так пришлось бы тянуть и копировать это решение в каждый проект. Не айс. Хочется более универсального решения.

В общем к чему это я все. Для себя я написал небольшой хук для c-mode, который загружает конфигурацию проекта из .Project файла, если он еще не был загружен. Также он обновляет список include путей для clang, который используется в auto-complete-clang и flycheck.

(defun init/project-update ()
  (let* ((proj-file ".Project")
         (ede-proj (ede-current-project))
         (proj-dir-tmp (locate-dominating-file buffer-file-name proj-file))
         (proj-dir (when proj-dir-tmp (expand-file-name proj-dir-tmp)))
         (root-dir (when ede-proj
                     (expand-file-name
                      (ede-project-root-directory ede-proj)))))

    (when (and proj-dir (not (equal proj-dir root-dir)))
      (message "load project %s" proj-dir)
      (let ((default-directory proj-dir))
        (load (expand-file-name proj-file)))))

  (let* ((ede-proj (ede-current-project))
         (root-dir (when ede-proj
                     (ede-project-root-directory ede-proj))))
    (when root-dir
      (setq flycheck-clang-include-path
            (mapcar (lambda (item)
                      (concat root-dir item))
                    (oref ede-proj include-path)))
      (make-variable-buffer-local 'ac-clang-flags)
      (setq ac-clang-flags
            (mapcar
             (lambda (item)
               (concat "-I" item))
             flycheck-clang-include-path)))))

А сам .Project файл лежит в корне проекта и содержит только описание проекта (как видите реальной проверки на это нету). Например вот такое:

(ede-cpp-root-project "NewProject"
                      :name "NewProject"
                      :file "Makefile"
                      :include-path '("/inc")
                      :system-include-path '("/usr/include/")
                      :spp-table '(("PROJECT_EXPORT" . "")))

В душе я надеюсь, что я что-то делаю не так, что все в реальности легко и просто настраивается. Что на самом деле я просто где-то пропустил правильный вариант настройки в мануале CEDET. Если это действительно так, укажите на мою ошибку. Если же эти хуки являются единственным вариантом для удовлетворения моих запросов, то оформлю минорный мод для поддержки автоматической загрузки проектов. В общем делитесь вашими вариантами и впечатлениями от использования EDE.

P.S. Все эти негативные впечатления от использования EDE видимо возникли в результате годового использования Eclipse и Idea для программирования на Java. Пробовал Emacs заточить для Java, но затея не увенчалась успехом. Но для C/C++ проектов только Emacs, только хардкор.

Установка

Самая лучшая сборка Emacs для OS X устанавливается следующим образом (у тебя ведь уже есть homebrew, верно?):

brew tap railwaycat/emacsmacport
brew install emacs-mac --icon-modern
brew linkapps

Это свежий GNU Emacs с рядом патчей “под макось”.
Например, этот порт по-умолчанию меняет местами ⌘ и ⌥ в Emacs, потому что так удобнее. Но это отключается. А полный список патчей здесь.

Клавиатура под Emacs

Теперь займемся хардварной оптимизацией. Необходимо демонтировать клаву вашего макбука и заменить на… Да я шучу, конечно =)

Не обязательно, но рекомендую: для комфортной работы в Emacs надо немного поменять расположение самых часто используемых клавиш. А именно: нужно поменять местами левый control с caps lock (это почти обязательно), и правый контрол с return (желательно, чтобы не превратиться в осьминога).

Шутки шутками, а без этого не знаю смог бы ли я познать всю внутреннюю красоту емакса со сломанными пальцами.

Левый контрол с капсом легко меняются средствами системы. Ключ вот здесь:

С правым контролом чуть сложнее – понадобится программа KeyRemap4MacBook. Зато она умеет много других полезных штук, например – переключаться на английский язык по одиночному нажатию левой клавиши ⌘, и на русский – по нажатию правой.

В KeyRemap4MacBook нужно включить опцию “Change Return Key > Return to Control_L”. При этом стандартная функция кнопки Return тоже сохраняется – срабатывает в том случае, если нажата только одна клавиша Return, без сочетания с другими. Правда ты же подсел на Emacs, теперь ты должен использовать только ⌃M, точнее сказать C-m, %username%.
Единственный неприятный момент – на такой Return не совсем адекватно реагирует Alfred. Но это было давно, может уже само починилось.

Emacs Mode в KeyRemap4MacBook

В этой программе есть целая группа опций под названием Emacs Mode. Она позволяет применять Emacs-like хоткеи для всей системы. На самом деле, во всех полях ввода OS X уже и так работают Emacs-like хоткеи. Но только основные, а эти опции могут сделать больше, например, транслировать ⌥W в ⌘C (для копирования в emacs-стиле).

EmacsClient

Для того, чтобы открывать файлы из командной строки в emacs, служит emacsclient, который устанавливается в /usr/local/bin, если ты воспользовался рекомендуемым мной способом установки Emacs. Это не относится к OS X, но на всякий случай уточнил, что он работает. Не забудь только сделать (server-start) в одном инстансе емакса.

Настройки OSX-only

Для тех, кто использует один конфиг Emacs на разных ОС, существует возможность задавать настройки локально. Для OS X это делается следующим образом:

(when (eq system-type 'darwin)
; ты знаешь что делать
)

Сразу рекомендую прописать туда:

(menu-bar-mode 1)

Дело в том, что любой уважающий себя емаксер сразу отключает тулбар, менюбар и, не редко, скроллбар. В емаксе это всё лишнее расходование экранного пространства, но вышеозначенная опция все-таки менюбар включает. Дело в том, что в OS X меню расположено в панели, а вот если его отключить, окно меняет свой тип и его уже не получится развернуть в фулл-скрин, а также будут проблемы с потерей фокуса.

Переключение языков в Emacs

Хорошо бы написать аналог программы emxkb для оконной системы OS X, чтобы удобно переключать языки ввода в Emacs. Подробнее про emxkb.

org-protocol

Org-mode это обалденный пакет. Если ты им пользуешься и тебе нужен рабочий org-protocol в OS X, то читай дальше.

Подробнее что зачем и почему написано вот здесь.

Реализация для Aquamacs здесь.

Реализацию для GNU Emacs из brew я сделал и положил сюда. Нужно просто скачать и положить в /Applications.

Есть ещё один нюанс: у меня в safari не работали букмарклеты для org-protocol пока я не заменил двойные слеши на одинарные, вот так:

javascript:location.href='org-protocol:/store-link:/'+encodeURIComponent(location.href)

Я люблю экспериментировать с разными редакторами кода для программистов. Особый интерес проявляю к так называемым “hackable” редакторам кода (затрудняюсь перевести на русский). Давно хотел написать такой пост – просто мнение о тех редакторах, на которые обращаю внимание.

VIM (MacVim)

Автор vim-плагина Airline очень хорошо охарактеризовал его, когда сваливал на Emacs. Он написал примерно так: “VIM лучше в редактировании текста, но Emacs лучше для работы”. Я полностью согласен, команды vim очень хороши в навигации по тексту и его редактировании. Только для того, чтобы понять эту магию, необходимо хорошо изучить vim. Но vim тормоз и ограниченный. Если попытаться добавить в него часть функциональности, которую я привык видеть в Emacs, он начинает дико тормозить. Я пробовал профилировать плагины, тормозят все по немногу.

Emacs

До сих пор считаю эту среду лучшей для множества задач. Emacs это не редактор, а интерпретатор лиспа – этим всё сказано. Если в виме есть работа с метками (закладками) и история изменений в виде дерева, то для Emacs существует несколько пакетов рыботы с метками и пакет для реализации истории, как в vim. Всё это реализовано на elisp и программист (у Emacs нет “просто пользователей”) может в реальном времени изменять или полностью переделывать реализацию этих функций. Emacs – замечательный почтовый и jabber клиент, лучший органайзер и т.д. Но всё это великолепие затмевается высоким порогом вхождения. Если не углубиться в Emacs и сразу свалить на vim, то так и не познаешь всю эту магию (у большинства заявляющих “пробовал я этот ваш emacs” именно так и было, не распробовал). Кстати, упомянутый выше автор Airline перешел на Emacs только потому, что для Emacs существует лучшая реализация эмуляции vim-а. Работают все команды, которые я знаю в vim (а я их знаю много, целенаправленно изучал). Некоторые считают evil-mode реализацией недостающего текстового редактора в операционной системе Emacs. Для него даже замечательный плагин surround реализован и работает точно как в vim, а не так, как жалкое подобие в sublime.

Sublime Text 3

Действительно хороший редактор, но с ним как-то скучно. UI для плагинов у него слишком простой, но зато это единственный редактор, в котором есть умный авто-комплит и переход к определению для PHP. Всё благодаря плагину Sublime CodeIntel, код которого был взят из Komodo IDE. Плагины в саблайме работают в отдельном потоке, именно поэтому линтеры работают в фоне, а не при каждом сохранеии (как vim). И именно поэтому возможна реализация CodeIntel, который в фоне индексирует код. Не тормозит с кучей плагинов, красивый, всё работает.

Atom

Вроде как “hackable editor for the 21st Century”, но пока слишком тормозной. Зато сразу на старте появилась почти вся нужная мне функциональность, потому что плагины клепают очень быстро, они ведь на javascript (и coffee). Плагины на javascript это хорошо. А вот “taking the web native” пока не в полной мере присутствует. Где live-coding для javascript как в LightTable? Кстати, они, кажется, хотели его продавать. А как это, если исходники открыты под либеральной лицензией?

LightTable

По задумке классный проект, но в данный момент больше напоминает демку. Из коробки live coding для нескольких языков: html/css, javascript, clojure, clojurescript, python. Можно ещё плагин для ruby доустановить. Live coding реализован классно – можно видеть результат выполнения кода прямо в редакторе, а можно подключиться к своему браузеру/repl/приложению и выполнять его там. Но много чего пока нету и самое печальное – нет документации для разработчиков. Так – пару статей в блогах о внутренностях LT. Короче говоря нет такой инструкции как у атома – садимся и за пять минут пишем демо-плагин. Кстати, сделан этот редактор (IDE?) тоже на web-технологиях, поэтому в качестве редактора используется CodeMirror. Ощущения от редактирования как-то не очень, хотя тормозит меньше чем atom. Тем не менее, что бы я там себе не думал, программисты на clojure уже используют его в работе.

• flx
• fuzzy-el

Настройка

В popup-switcher используется flx. ИМХО, это просто прекрасный движек для нечеткого поиска, хотя автор и предупреждает о том, что проект достаточно молодой и возможно еще остались ошибки.

В flx-ido есть более высокоуровневые функции, поэтому фактически зависимость именно от flx-ido.

Как и в случае с CEDET и projectile, явно зависимость не указывается (чтобы не превращать popup-switcher в монстра с большим количеством обязательных зависимостей). Чтобы воспользоваться возможностью нечеткого поиска, необходимо установить flx и flx-ido любым удобным вам способом, например через MELPA:

 M-x package-install [RET] flx-ido [RET]

 (setq psw-use-flx t)

Пример использования

P.S.

Эргономика промышленных решений

Изящество и красота текстовых интерфейсов

TUI в emacs

Так, например, первая из них позволила мне реализовать в TUI некоторые из идей, используемых в IntelliJ IDEA: popup-switcher. Вызов интерактивной функции

• psw-switch-buffer - приведет к появлению списка открытых буферов. Ввод символов имени буфера будет сокращать список. Именно в качестве (еще одного) механизма переключения буферов и задумывался изначально popup-switcher, однако на самом деле, он может быть использован для переключения чего угодно (отсюда и название).
• psw-switch-projectile-files - работает со всеми файлами проекта (файлы проекта рассматриваются в контексте расширения projectile).
• psw-switch-function - работает с функциями/методами в текущем файле.

Установка

 (require 'package)
 (add-to-list 'package-archives
              '("melpa" . "http://melpa.milkbox.net/packages/"))
 (package-initialize)

 M-x package-install [RET] popup-switcher [RET]

 (require 'popup-switcher)

Настройка

 (setq psw-in-window-center t)

 (global-set-key [f2] 'psw-switch-buffer)
 (global-set-key (kbd "C-S-n") 'psw-switch-projectile-files)

 ;; Activate semantic
 (semantic-mode 1)
 
 ;; Load contrib library
 (add-to-list 'load-path "~/.emacs.d/cedet/contrib/")
 (require 'eassist)
 
 (eval-after-load "eassist"
   '(global-set-key [f3] 'psw-switch-function))

Добавление переключений

 (defun psw-switch-buffer ()
    (interactive)
    (psw-switcher
     :items-list (psw-get-buffer-list)
     :item-name-getter 'buffer-name
     :switcher 'switch-to-buffer))

• items-list - список, в котором осуществляется выбор (psw-get-buffer-list - просто использует встроеную функцию buffer-list с некоторыми дополнительными фильтрами).
• item-name-getter - функция получения текстового обозначения каждого элемента списка в меню выбора.
• switcher - функция, описывающая что делать с выбранным элементом.

Заключение

Библиотека direx-el используется, например, в проекте emacs-jedi-direx. direx-el потенциально может выступать в качестве основы для более простого и современного аналога ECB. Конечно, в данном случае создание нового окна будет необходимо, но мне кажется, что это как раз тот случай, когда это оправдано.

Надеюсь, вас зантересовала идея более широкого применения TUI в emacs, а также написания и развития расширений, как использующих эти возможности, так и предоставляющих новые возможности для TUI - виджетов.

Появилась у меня в последнее время необходимость основательно познать Java. Очень долго не смотрел в его сторону, были у меня некоторые предубеждения. Я всегда думал, что plain C и Lisp это наше все. И этого достаточно. А сейчас работа повернулась стороной с Java лицом и соответственно захотел быстренько познать его особенности, а также настроить свой любимый редактор для удобной работы с этим популярным языком программирования.

Для каждого языка программирования в Emacs я стараюсь настроить следующие возможности:

• Подсветка синтаксиса (есть из коробки)
• Авто дополнения (желательно через auto-complete)
• Навигация по коду
• Работа с проектами (опционально, люблю работать в консоли вне Emacs)
• REPL (также опционально, но очень помогает во время обучения)

Из коробки в java-mode фактически работает только подсветка синтаксиса. Cedet идущий с Emacs'ом также позваляет настроить автодополнения и навигацию внутри классов. Но вот, например, системные вещи наотрез отказывается предлагать в качестве дополнений.

В общем я решил посмотреть, какие сейчас есть удобств для работы с Java в Emacs. При этом я наткнулся на следующие вещи:

• JDEE
• malabar-mode
• Eclime for Emacs
• Auto Java Complete
• CEDET Developer Version (Bazaar repo)

Немного впечатлений о каждом расширении. Все пробовал на MacBook Air, OS X, Emacs 24.3.1 из MacPorts.

JDEE

Старое и похоже переставшее развиваться расширение. Сразу не понравилось, что тянет с собой свою цветовую схему. Мелочи, но они всегда бросаются в глаза. Также JDEE каким-то образом умудряется нарушить работу whitespace-mode, который перестает подсвечивать вообще что-либо. Данную проблему решить не смог. Есть у меня подозрение, что это связано с перекрашиванием буфера, но глубока не капал за ненадобностью. Нечто похожее сейчас есть в markdown-mode. Ну и каких-то особых возможностей здесь не нашел. Все плюшки сделаны через Cedet, соответственно их можно получить и без JDEE.

Malabar-mode

Завязан на Maven, про который ранее слышал совсем чуть-чуть и отдаленно. Быстренько глянул, как работать с этим менеджером проектов. Создал тестовый проект, но производительность malabar-mode вообще не порадовала. Он как я понял использует Groovy console для формирования дополнений. И это похоже порой не быстрый процесс. В общем от этого варианта тоже отказался. Кроме того проект также загибается. Хотя в знакомстве с malabar-mode есть свой плюс: я узнал что такое Maven и как с ним работать.

Eclime

Вот это вообще монстр. Идея затащить в Emacs (изначально в Vim) функционал Eclipse через некий интерфейс тоже на деле оказывается не шибко производительна. В данном случае eclime запускает Eclipse на заднем плане и общается с ним, чтобы получить автодополнения и еще некоторый функционал (рефакторинг, навигация по коду и т.п.). Скорость отзывчивости данной системы еще меньше, чем у Malabar.

Auto Java Complete

Смысл данного расширения прост: сгенерировать теги необходимых Java библиотек и предоставить интерфейс для auto-complete. Я попробовал использовать готовые теги и это работает достаточно быстро и удобно. Но тут мы получаем только информацию системных библиотек и того что сами укажем ручками при генерации тегов. В принципе в связке со стандартным Cedet идущим с Emacs'ом должно всего этого хватить.

Cedet Dev

Самый удобный, как мне кажется, вариант это использовать последнюю версию Cedet из Bazaar репозитория. Тут сейчас Java хорошо поддерживается. Maven проекты кстати тоже отлично воспринимаются. По работе и настройке Cedet лучше обращаться к статье Alex Ott'а.

На данный момент я остановился на последнем варианте: Cedet Dev + auto-complete. Есть у кого еще предложения как улучшить жизнь в Emacs при работе с Java? Или все таки Cedet это наше все и смотреть в другие стороны лучше не стоит?

Для сортировки без повторений выполняем:

• выделить область
• C-u M-| sort -u RET

С включенными режимами transient-mark-mode и delete-selection-mode можно сразу заменить выделенную область отсортированными без повторения строками:

• выделить область
• M-| sort -u RET

* TODO task 1
  SCHEDULED: <2011-06-16 Thu>
* task 2
  SCHEDULED: <2011-06-16 Thu>
** TODO subtask 2-1
* task 3
  SCHEDULED: <2011-06-16 Thu>

  NOTES:      Scheduled:  TODO task 1
  NOTES:      Scheduled:  task 3

1. maemo является полноценным линуксом
2. n900 оснащается хардварной клавиатурой-слайдером

1. Скачиваем пакет на устройство отсюда или с моего зеркала.
2. Под рутом выполняем dpkg -i emacs_23.1.1_armel.deb.
3. Обновляем apt и доставляем недостающие пакеты: apt-get -f install

cp /usr/share/X11/xkb/symbols/nokia_vndr/rx-51 /usr/share/X11/xkb/symbols/nokia_vndr/rx-51.orig
cp rx-51.qole /usr/share/X11/xkb/symbols/nokia_nvdr/rx-51
setxkbmap

(add-to-list 'load-path "/path/to/maxframe")
(require 'maxframe)
(add-hook 'window-setup-hook 'maximize-frame t)
(maximize-frame)

(global-set-key (kbd "C-c c") 'clipboard-kill-ring-save)
(global-set-key (kbd "C-c v") 'clipboard-yank)

(defun insert-less-symbol ()
  (interactive)
  (insert "<"))

(defun insert-more-symbol ()
  (interactive)
  (insert ">"))

(global-set-key (kbd "C-c C-,") 'insert-less-symbol)
(global-set-key (kbd "C-c C-.") 'insert-more-symbol)

Я собрал несколько из них.

Итак посмотрите на указанные переменные: