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

Michael Kazarian: What is Python's biggest disadvantage?

2019-01-28T08:09:39+00:00

1) Python seems simple at first glance. There are a lot of points that always need to keep in mind. Since 2003 I used Python because it was simple. Since 2016 I use Emacs Lisp instead of Python for disposable tasks, prototypes and text processing.

2) Backward incompatibility of language and libraries more than of Java, Delphi or Emacs.

3) Dynamic typing per se. This is good for little project/team but, it is a pain in another case. I wrote a library for type checking in a big project.

4) Dynamic typing implementation makes Python slow. Even slower than Emacs Lisp. Common Lisp implementations prove that dynamically typed languages could be faster.

Emacs@Habrahabr: Голосование по второй бета-версии Revised 7 Report on Algorithmic Language Scheme (Large Language)

2018-11-28T02:21:03+00:00

Открыто голосование по содержанию второй (из восьми) бета-редакции алгоритмического языка Scheme R7RS-large (Tangerine Edition), а также сбор предложений по третьей бета-редакции (Orange Edition).
Читать дальше →

Emacs@Habrahabr: Как начать писать код на Lisp?

2018-06-03T09:33:00+00:00

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

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

Читать дальше →

Emacs LJ community: Emacs как IDE для Go

2016-06-08T08:00:33+00:00

(оригинал: ReanGDblog)

Цель статьи дать обзор инструментов в Emacs для работы с Go кодом. Настроить горячие клавиши, возможно добавить алиасы и сделать их удобнее для повседневного использования - на вашей совести. Хочу отметить, что поддержка языка в Emacs - на высоком уровне: подсветка кода, автодополнение, сниппеты, рефакторинг, подсветка ошибок, отображение документации, тестирование, компиляция и многое другое. Сразу оговорюсь, что проверял я только под Linux, под альтернативные OS могут быть особенности, которые тут не освещены.

Общая настройка Go

Надеюсь у вас уже стоит go, правильно настроены "GOPATH" и т.п., поскольку отдельные плагины чувствительны к подобного рода вещам. Не забудьте добавить "$GOPATH/bin" в PATH, что бы утилиты, который будем ставить, запускались без указания полного пути. Так же я рассчитываю, что с основами Emacs и Go вы знакомы.

Вся настройка в одном месте

Сначала коротко о настройке. Устанавливаем набор приложений, которые необходимы плагинам:

go get -u github.com/nsf/gocode
go get -u github.com/rogpeppe/godef
go get -u github.com/jstemmer/gotags
go get -u github.com/kisielk/errcheck
go get -u golang.org/x/tools/cmd/guru
go get -u github.com/golang/lint/golint
go get -u golang.org/x/tools/cmd/gorename
go get -u golang.org/x/tools/cmd/goimports
sudo go get -u golang.org/x/tools/cmd/godoc

Обратите внимание, что "godoc" нуждается в "sudo", т.к. ставятся в системную директорию, остальные будут установлены в локальный "GOPATH". Я бы посоветовал ставить "godoc" последним, что бы он не создавал директорий с правами root.

Из плагинов Emacs понадобятся следующие: go-mode, go-eldoc, company, company-go, yasnippet, go-rename, multi-compile, flycheck, gotest, go-scratch, go-direx, go-guru.

Как альтернативу company и company-go можно использовать auto-complete и go-autocomplete.

Flycheck заменяется flymake-go, так же посмотрите на golint, go-errcheck и govet.

Вместо go-scratch иногда используют go-playground.

Полная настройка специфичная для go-mode режима выглядит у меня вот так:

(require 'company)
(require 'flycheck)
(require 'yasnippet)
(require 'multi-compile)
(require 'go-eldoc)
(require 'company-go)

(add-hook 'before-save-hook 'gofmt-before-save)
(setq-default gofmt-command "goimports")
(add-hook 'go-mode-hook 'go-eldoc-setup)
(add-hook 'go-mode-hook (lambda ()
                            (set (make-local-variable 'company-backends) '(company-go))
                            (company-mode)))
(add-hook 'go-mode-hook 'yas-minor-mode)
(add-hook 'go-mode-hook 'flycheck-mode)
(setq multi-compile-alist '(
    (go-mode . (
("go-build" "go build -v"
   (locate-dominating-file buffer-file-name ".git"))
("go-build-and-run" "go build -v && echo 'build finish' && eval ./${PWD##*/}"
   (multi-compile-locate-file-dir ".git"))))
    ))

Go mode

Теперь по порядку. Go-mode - базовый пакет, вокруг которого строится остальное. Кроме подсветки, он приносит с собой поддержку команд:

M-x godef-jump (C-c C-j) - перейти к реализации функции под курсором (вернуться назад, можно через M-*)

M-x godef-jump-other-window (C-x 4 C-c C-j) - аналогично "godef-jump" только открывается в новом окне

M-x godoc-at-point - покажет документацию по команде под курсором

M-x go-goto-imports (C-c C-f i) - перейти к секции "import" текущего файла

M-x go-goto-function (C-c C-f f) - перейти к началу функции, внутри которой находится курсор

M-x go-goto-arguments (C-c C-f a) - перейти к аргументам текущей функции

M-x go-goto-docstring (C-c C-f d) - перейти к комментариям функции

M-x go-goto-return-values (C-c C-f r) - перейти к описанию возвращаемого значения для функции

M-x beginning-of-defun (C-M-a) - перейти к началу функции

M-x end-of-defun (C-M-e) - перейти к концу функции

Есть базовая поддержка imenu для функций и типов

Форматирование исходников я делаю через "goimports", который установили выше. Он помимо собственно форматирования, умеет добавлять необходимые импорты в текущем файле и вычищать неиспользуемые. Удобно вызывать его автоматически, при сохранении:

(add-hook 'before-save-hook 'gofmt-before-save)
(setq-default gofmt-command "goimports")

Вручную вызывается через "M-x gofmt".
Вот как это выглядит:

Go eldoc

Плагин go-eldoc - умеет показывать в строке состояния информацию о переменной или аргументе\возвращаемом значении функции находящейся под курсором. Фактически документация по сигнатурам. Скриншот я нагло украл у автора:

Для настройки добавьте вот такие строки:

(require 'go-eldoc)
(add-hook 'go-mode-hook 'go-eldoc-setup)

Автодополнение

Я предпочитаю для автодополнения company, поэтому ставим ещё company-go и добавляем в конфиг:

(require 'company)
(require 'company-go)
(add-hook 'go-mode-hook (lambda ()
                            (set (make-local-variable 'company-backends) '(company-go))
                            (company-mode)))

Это единственная специфичная настройка для Go, сам "company", кто пользуется им, настраивать умеют.

Если вам нравится auto-complete, то для go понадобиться go-autocomplete, а настройка описана вот тут.

Сниппеты

Тут стандарт - yasnippet, который поставляется с поддержкой Go, если у вас "yasnippet" не включён глобально, достаточно добавить хук для go-mode:

(require 'yasnippet)
(yas-reload-all)
(add-hook 'go-mode-hook 'yas-minor-mode)

Доступные сниппеты смотрите в репозитории. Если вас они не удовлетворяют, существуют альтернативные наборы: yasnippet-go и go-snippets, но там, на мой вкус, ничего интересного.

Переименование функций и структур

Переименование самый используемый из методов рефакторинга. Он поддерживается плагином go-rename и вызывается при помощи "M-x go-rename". Из недостатков - go-rename не работает, если в проекте есть синтаксические ошибки.

Подсветка ошибок

Сильно ускоряет разработку - подсветка ошибок до компиляции. Для этого ставим flycheck и делаем общие настройки, по необходимости. Затем переключаемся в буфер в котором включен режим go-mode и проверяем, что flycheck видит все необходимые утилиты: "M-x flycheck-verify-setup", у меня получилось так:

  go-gofmt
    - predicate:  t
    - executable: Found at /usr/bin/gofmt
  go-golint
    - predicate:  t
    - executable: Found at /home/user/go/bin/golint
  go-vet
    - predicate:  t
    - executable: Found at /usr/bin/go
  go-build
    - predicate:  t
    - executable: Found at /usr/bin/go
  go-test
    - predicate:  nil
    - executable: Found at /usr/bin/go
  go-errcheck
    - predicate:  t
    - executable: Found at /home/user/go/bin/errcheck
Flycheck Mode is enabled.

Если что-то не найдено, то вы поставили не все утилиты из списка в начале статьи или не добавили их в PATH. go-test тут не включён, т.к. он срабатывает только для файлов имя которых оканчивается на "_test.go".

Настройка заключается в том, что бы включить "flycheck-mode" для режима go:

(require 'flycheck)
(add-hook 'go-mode-hook 'flycheck-mode)

Об общих настройках flycheck, я надеюсь рассказывать не нужно.

Поклонники flymake - сделают аналогичное при помощи пакета flymake-go (инструкции по настройке у автора в репозитории), а так же goflymake. При желании посмотрите на golint, go-errcheck и govet. Но на мой взгляд flycheck функциональнее.

Компиляция и запуск

Тут сразу две проблемы:

Стандартный модуль compile позволяет настроить только одну команду для режима. А я хочу меню с компиляцией, компиляцией и запуском, запуском тестов и т.п.

Я перерыл пол интернета и не нашёл способ обнаружения корня проекта на Go. Если у вас сложная иерархия проекта и открыт файл внутри этого проекта - найти место где нужно грубо говоря запустить build это та ещё задачка.

Первая проблема решается при помощи плагина multi-compile, подробнее читайте в этой статье. А вот вторая в каждом конкретном случае решается особо. Для себя я решил считать корнем проекта ту директорию, где лежит ".git", поскольку любой проект начинаю с "git init". А для экспериментов с языком - использую go-scratch.

Настройка для плагина multi-compile выглядит вот так:

(require 'multi-compile)
(setq multi-compile-alist '(
    (go-mode . (
("go-build" "go build -v"
   (locate-dominating-file buffer-file-name ".git"))
("go-build-and-run" "go build -v && echo 'build finish' && eval ./${PWD##*/}"
   (multi-compile-locate-file-dir ".git"))))
    ))

Да, на первый взгляд - сложно, но если разобраться, то не очень.

Тут написано что для файла открытого в режиме "go-mode" добавить два пункта меню "go-build" и "go-build-and-run" . Первый вызывает консольную команду "go build -v". Второй "go build -v && echo 'build finish' && eval ./${PWD##*/}".

Как рабочая директория у обеих команд устанавливается та, внутри которой лежит ".git", т.е. если у нас открыт файл "~/go/go1/go.go" плагин поищет директорию ".git" внутри "~/go/go1/", если не найдёт, ищет уровнем выше - в "~/go/". Как только нужная директория найдена - она считается рабочей из которой и вызваются скрипты.

Теперь о страшных bash командах: "go build -v" вопросов не вызовет - стандартная компиляция проекта. А вот вторая сложнее:

go build -v && echo 'build finish' && eval ./${PWD##*/}

Конструкция "${PWD##*/}" разворачивается в имя последнего элемента текущей директории. Н-р для "~/go/super_project", получим "super_project". Т.е. для этого примера, команда превращается вот в это:

go build -v && echo 'build finish' && eval ./super_project

Теперь читается проще - компилируем, пишем в консоль, что компиляция завершилась и запускаем получившийся бинарник. Go по умолчанию называет бинарник по имени директории, где находится проект, в нашем случае это "super_project".

Меню с командами компиляции вызывается вот так: M-x multi-compile.

Больше примеров настройки на github.

Тестирование

Я для тестирования пользуюсь goconvey, который умеет самостоятельно обнаруживать изменения в файлах, и перезапускать тесты. Но часто запуск всего набора тестов - лишнее действие, которое сильно грузит процессор и заставляет менять контекст переключаясь в браузер. Поэтому хочется иметь возможность запустить только один тест или все тесты в данном файле оставаясь в Emacs. В этом нам поможет пакет gotest.

Дополнительной настройки он не требует (ну может только горячие клавиши назначить). Умеет он следующее:

M-x go-test-current-test - запустить тест внутри которого находится курсор

M-x go-test-current-file - запустить тесты внутри текущего файла

M-x go-test-current-project - запустить тесты для текущего проекта

M-x go-test-current-benchmark - по аналогии - запустить бенчмарк внутри которого находится курсор

M-x go-test-current-file-benchmarks - запустить бенчмарки в файле

M-x go-test-current-project-benchmarks - запустить бенчмарки в проекте

Локальный Go Playground

Что-бы попробовать как работает та или иная часть Go, обычно пользуются play.golang.org, но у него большой недостаток - он работает в браузере, это не удобно. А локально создавать проект для каждой мелочи лень. Эту нишу покрывает плагин go-scratch. После команды "M-x go-scratch" откроется новый буфер с заготовкой функции main. Компиляция запускается сочетанием клавиш "C-c C-c".

Существует похожий плагин go-playground, но мне он не понравился, т.к. физически создаёт файл на диске, а чистить за ним не хочется.

Отображение структуры кода

Если вас не устраивает imenu, поддержку которого добавляет go-mode, то воспользуйтесь go-direx, который, нужно отдать должное, покажет структуру текущего кода в гораздо более наглядном виде. Как-то настраивать его не нужно, достаточно вызвать "M-x go-direx-switch-to-buffer".

Go guru

Я не могу не упомянуть ещё об одном плагине - go-guru. Он умеет много интересных и полезных вещей, но в рамки статьи они не поместятся. Подробно почитать о них можно в oracle-user-manual, там правда речь идёт о предыдущем названии "go-oracle", сейчас проект переименован в "go-guru", но суть осталась прежней.

Для затравки покажу как найти места откуда вызывается функция. Вызываем:

M-x go-guru-set-scope

И вводим пакет с которым работает (в моём случае это "github.com/ReanGD/go-web-search"). После этого ставим курсор на интересующую функцию и вызываем

M-x go-guru-callers

В отдельном буфере отобразиться список мест откуда функция вызывается. На gif надеюсь понятнее:

Из недостатков - работает медленно, но в любом случае - руками делать подобные вещи дольше. И как я слышал, авторы сейчас серьёзно взялись за проект, надеюсь работать станет удобнее и быстрее.

Emacs LJ community: Мой первый пакет для Emacs: multi-compile

2015-10-06T20:07:18+00:00

(оригинал: 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")))
    ))

Ну и перед включением конечно нужно установить пакет, (предварительно подключив Melpa репозиторий, если его у вас нет):

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")))
    ))

Теперь по отображаемому меню: по умолчанию оно формируется через ido, но можно использовать helm, а для сторонников default конфигурации Emacs есть опция "default":

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

Ну и собственно вызов меню компиляции осуществляется через "M-x multi-compile-run". Какие-то горячие клавиши я добавлять не стал, каждый добавит свои по вкусу.

Если кому интересно, то исходники лежат на github и вот ссылка на сам пакет multi-compile на Melpa.

Alexander Sviridov: Встречайте: undercover.el

2014-10-06T10:23:27+00:00

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

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

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

Добавьте свой репозиторий в Coveralls.
Добавьте undercover.el в Cask файл проекта:

(source gnu)
(source melpa)

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

(development
  (depends-on "undercover"))

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

(require 'undercover)

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

(require 'awesome-package)

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

Michael Kazarian: python-mode, памятка

2014-09-29T14:17:59+00:00

cedet из cvs теперь принудительно дергает python.el (он у меня в /usr/share/emacs/23.1/lisp/progmodes), который конфликтует с python-mode.el, который мне нравится больше. Лечится правкой cedet/semantic/wisent/wisent-python.el Находится строчка (require 'python nil t) и комментируется. При желании перекомпилируется.
Нормальная работа восстановлена и глюков пока не замечено.

Alexander Sviridov: Emacs Lisp Style Guide

2014-09-07T05:56:53+00:00

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

Ilya Zonov: EDE боль

2014-08-18T20:00:00+00:00

Примерно раз в год я возвращаюсь к работе над некоторыми 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, только хардкор.

Pavel Vyazovoi: Как готовить Emacs в OS X

2014-05-12T02:53:00+00:00

Установка

Самая лучшая сборка 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)

Pavel Vyazovoi: Скромное мнение о редакторах текста

2014-05-12T00:40:00+00:00

Я люблю экспериментировать с разными редакторами кода для программистов. Особый интерес проявляю к так называемым “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 уже используют его в работе.

Kostafey: Fuzzy matching в popup-switcher с использованием flx

2014-05-03T11:02:35+00:00

Наконец добрался до fuzzy matching в popup-switcher. Есть несколько решений для осуществления нечеткого поиска в Emacs. Например:

Настройка

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

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

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

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

Кроме этого, необходимо установить psw-use-flx в значение t


 (setq psw-use-flx t)

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

Например, неообходимо найти функцию psw-get-item-by-name. Вызываем psw-switch-function (любым выбранным клавиатурным сочетанием), набираем первые буквы слов "get" и "item" - "gi", flx сузит список поиска и отсортирует по релевантности:

Пример использования flx в popup-switcher.

P.S.

Happy hacking! :)

Kostafey: popup-switcher - переключение буферов и навигация по функциям, используя TUI-меню

2013-11-05T14:06:19+00:00

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

С некоторого времени для разработки на Java я использую IntelliJ IDEA. Какова там навигация по файлам или по методам! Нажимаешь C-S-n (или C-n для классов) и появляется окошко поиска со списком. Вводишь буквы из названия файла и список сокращается - самый удобный способ навигации по файлам проекта. Аналогично C-F12 для навигации по методам открытого класса - интерактивно изменяющееся меню на основе вводимых символов из имени метода. Ничего эргономичнее до этого не видел.

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

В emacs это все есть, безусловно, но выглядит это... в emacs вообще все выглядит абсолютно самобытно. Именно самобытно. Думаю, вряд ли кто-то скажет, что emacs предоставляет GUI - интерфейс, возможно лишь местами. В большинстве случаев, emacs не предоставляет и CLI - да, он часто интегрируется и CLI-инструментами: CLI-утилита является back-end-ом, а emacs предоставляет свою обертку, он имеет внутренние оболочки shell-ы и repl-ы, может сам быть запущен из внешних, но этот интерфейс, хоть и играет важную роль, все же является скорее вспомогательным. Выходит TUI? Во-многом, да. Но он зачастую деформируется механизмом окон. Если взять, например, mc, far, ndd, старые, времен DOS, среды разработки, антивирусы, архиваторы, предоставляющие TUI-интерфейс, то там любое диалоговое окно - часть общего текстового рабочего пространства. В emacs же окна жестко механически разделяют текстовые области. Данный подход стал идиоматическим. Скажем, org-mode и magit - примеры эффективного разделения возможностей TUI в рамках основного буфера и добавления вспомогательных окон и буферов. Такие буферы имеют свои специальные режимы с удобными таблицами ключей. Может оно и хорошо, и у такого подхода безусловно есть свои плюсы, но всегда ли это нужно? На каждый чих создается новое окно и в нем свой буфер. Лично мне куда приятнее чаще видеть старый-добрый TUI-интерфейс там, где создание отдельного окна избыточно.

TUI в emacs

Библиотеки popup-el (выпадающие меню) и direx-el (деревья) - примеры расширений, предоставляющих некоторую функциональность TUI. К сожалению, предоставляется лишь некоторая часть возможных виджетов, но тем не менее, имеющиеся весьма удобны.

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

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

Пример навигации по буферам.

Пример навигации по функциям в файле с исходным кодом на Clojure.

Установка

Установка расширения довольно проста. Добавьте MELPA в вашу переменную package-archives (если у вас он еще не был добавлен):


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

Далее popup-switcher устанавливается командой:


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

Кроме того, в файле инициализации .emacs необходимо указать:


 (require 'popup-switcher)

Настройка

После установки psw-in-window-center в значение t всплывающее меню будет появляться в середине окна. По умолчанию появляется в посередине меду левым краем окна и значением fill-column.


 (setq psw-in-window-center t)

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


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

Для активации возможности навигации по функциям/методам необходимо установить последнюю версию CEDET и подключить библиотеку eassist. Это не является обязательным, и вы можете использовать popup-switcher без CEDET (и, очевидно, без данной функциональности). Пример настройки:


 ;; 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))

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

Добавлять новые применения механизма переключения очень просто, так функция psw-switch-buffer выглядит следующим образом:


 (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 - функция, описывающая что делать с выбранным элементом.

Заключение

Для emacs существуют хоть и не всеобъемлющие, но весьма удобные библиотеки работы с TUI. Например, popup-elуже использующаяся в проектах auto-complete и emacs-jedi, а теперь и в popup-switcher.

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

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

Ilya Zonov: Emacs + Java

2013-08-24T20:00:00+00:00

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

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

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

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

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

Немного впечатлений о каждом расширении. Все пробовал на 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 это наше все и смотреть в другие стороны лучше не стоит?

Oleksandr Gavenko: Сортируем без повторений в Emacs.

2013-01-31T18:18:27+00:00

Только для сортировки строк в Emacs имеется встроенная функция: M-x sort-lines.

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

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

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

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

Eugene Burmako: сублайм => емакс

2012-12-11T10:24:36+00:00

После недавнего дискашена у metaclass и tonsky (клик клик) решил снова попробовать емакс. Особенно с учетом того, что сублайм closed source и развитие его, еще три-четыре месяца назад весьма бодрое, полностью остановилось.

Подумал и с удивлением заметил, что в сублайме для меня киллер фич не так уж и много. Первое это очень быстрый поиск по файлам в проекте (find + grep гораздо медленнее, к сожалению). Второе это возможность сохранять стейт проекта (открытые файлы, позиции в них) между запусками. Третье и четвертое это сниппеты и дефинишены синтаксиса (использующиеся для подсветки, комментирования и выщемливания определений - классов, методов, и т.п.). Вроде бы, все. Какой в этом плане state of the art в емаксе?

Еще доставляет go to symbol, который показывает список всех определений в файле и предоставляет для них fuzzy matching. Особенно удобно то, что по мере набора имени определения положение вьюпорта меняется, прокручивая файл к текущему в данный момент айтему. Вдвойне удобно, что по нажатию Escape вьюпорт откатывается обратно на позицию до начала поиска. Интересно, есть ли что-то такое уже существующее для емакса?

С нетерпением жду релиза и свободного времени, чтобы продолжить эксперименты с емаксом.

Alex Ott: Новая версия статьи про CEDET

2012-10-30T18:39:42+00:00

Только что залил на сайт новую версию своей статьи про настройку CEDET. Я также оставил доступной старую версию статьи, но в виде отдельной страницы.
Новая версия описывает новую схему расположения исходного кода, а также новый способ активации под-режимов, так что статья теперь применима и к версии из bzr, и к версии идущей в составе GNU Emacs (после того как выпустят новую его версию).
Кроме того, я добавил небольшое описание того, как настроить связку CEDET + Java, а также небольшое описание настройки дополнений через auto-complete.

Вместо моего конфига, который очень уж сильно замусорен, теперь лучше воспользоваться отдельным конфигом.

P.S. кстати, в последних снапшотах, CEDET умеет находить проекты Maven, и получать информацию о classpath прямо из них, так что теперь работает и дополнение имен для классов из сторонних библиотек. Например, вот так (Это дополнение при работе с кодом Apache Tika):

P.P.S. If you found error, or typo - please write comment on page, or fork source code on github (it's enough to fix only .muse file), and create pull request :-)

Jason McBrayer: Running Emacs on an Android tablet

2012-07-20T01:50:55+00:00

One of the things I've always wanted in a portable computer is the ability to run Emacs. The main reason is that since 2005 or so, my whole life has been run in org-mode, and, slightly before that, in howm. So, of course, when I got a low-end Android tablet, an Archos 70, of course, I...didn't install Emacs on it. As EmacsWiki implies, there's no perfectly obvious way to do so. And, there's MobileOrg-Android. When I first got my tablet, MobileOrg-Android was pretty bad. But it got better. Today, it's got a great user interface, syncing is fast and generally reliable, and there's an active core group of developers who are constantly adding features and contributing back to org-mode itself.

But...after quite a bit of trying, I still haven't made the MobileOrg workflow work for me. I keep my org files in a Mercurial repository on my home machine, and carry a clone with me. I run org-mobile-push and org-mobile-pull from the home repository, which requires it to be up to date, which usually can be done without manual intervention, but not always. And both pushing and pulling can make changes, which have to be committed. And you really have to sync on the mobile device twice: once before you push/pull, and once after, if you want the desired effect of pushing all your changes and captures to the repository, and having them all reflected on your device. The MobileOrg workflow is based on the idea that your mobile device doesn't have the horsepower to compute agendas on the fly. But is that true these days? I'll return to that issue later.

After seeing that some people had successfully run an Ubuntu user environment in a chrooted loopback filesystem on a similar tablet, I decided to try to get my Emacs that way. It didn't exactly work out right a way, and it took me quite a while to make time for the yak-shaving involved. Finally, I did, but with my preferred GNU/Linux distribution, Fedora.

Overview (the short version, aka tl;dr)

My sdcard is formatted ext3, and has the Fedora 13 rootfs unpacked into it. From a root prompt in ConnectBot, I bind-mount some required special filesystems under Fedora's root, then chroot into it, and start sshd. Then I can ssh into localhost with ConnectBot and run Emacs (and other things).

Longer version

Don't take this as a step-by-step instruction guide. What works and doesn't work on my device is likely to be quite different from what works and doesn't work on yours (unless yours is an Archos Gen8). This is really more to give you an idea of the kind of yak-shaving involved in getting this working.

First I rooted my tablet. I would have done this even if I weren't planning on running Emacs. For reference, the tablet is an Archos 70, running the latest version of the stock (Froyo) firmware, with a rooted initramfs.

Then, I tried installing the Ubuntu loopback images mentioned above. This didn't work for me, because the stock Archos kernel doesn't include the loop device, and for some reason, even when I built custom kernels with the loop device enabled, I couldn't get it to work.

Fortunately, my device has a microSD card slot, which is above and beyond the internal storage that the Archos firmware treats as an sdcard for the purposes of App2SD and so forth. I formatted a card as ext3, and tried to unpack the Ubuntu image onto it. This should have worked, but for some reason, my tablet didn't like having so much data pushed onto it over USB, and I lost the enthusiasm I needed to work on it.

Later, I unpacked the Fedora 14 ARM root filesystem more successfully, and tried chrooting into it, only to find that my kernel was too old for the version of glibc in Fedora 14. This also tragically sapped my motivation, causing me to stop working on it again for a while.

When I got another round tuit, I started with the Fedora 13 ARM root filesystem, and it worked pretty straightforwardly. This is what I did:

# umount /mnt/storage/sdcard
# mount -o noatime,nodiratime /dev/block/mmcblk2p1 /mnt/storage/sdcard

The sdcard is mounted with the options nodev,noexec,fmode=0666, and several other options that would make running it as the root filesystem of a normal linux slightly inconvenient. Some of the other parameters could be reset with mount -o remount,blah,noblah, but there doesn't seem to be a way to do that for fmode and dmode, so unmount and remount it is.

# cd /mnt/storage/sdcard/fedora
# mount --bind /dev dev
# mount --bind /dev/pts dev/pts
# mount --bind /proc proc
# mount --bind /sys sys

Now mount the various special filesystems that Fedora is going to need, that are provided by the kernel.

# chroot . /bin/bash -
# service sshd start

Now chroot into the Fedora environment, and start sshd. I've omitted some other stuff, like setting a (new?) password on the root account, and so forth. Technically, even starting sshd isn't necessary. You can just chroot into Fedora and run what you want to. Having sshd running makes it easier to reconnect to the Fedora environment without having to go through the process of cd'ing and chrooting to the Fedora directory.

From here on out, it's just installing stuff with yum. I've tried to avoid installing anything except what I particularly need.

# yum install -y emacs-nox git mercurial aspell aspell-en \
  diffutils patch man screen

What works

Installing things with yum!

There are things in the Fedora repositories that aren't supported on ARM, but I haven't had cause to install them yet.

Emacs!

Fedora 13 had Emacs 23.2.1, which is not exactly the latest and greatest, but it's not old enough to cause serious compatibility problems, either. I used hg to pull in my emacs startup code from my desktop, then created a mobile branch to strip it down and remove features I wouldn't be using, and to change paths to work with my mobile setup. Everything works as expected.

Emacs startup is surprisingly snappy. I had slower emacs startup times on my desktop as recently as 5 or 6 years ago, and this isn't exactly a fast tablet.

You might think it would be hard to use Emacs with a mobile keyboard, but Hacker's Keyboard takes care of that, by and large. It's still an onscreen keyboard, but it's an onscreen keyboard with all the keys you'd expect on a standard PC keyboard.

Color themes work, as long as they would work under xterm-256color. Sorry for not including a nice one in the screenshots, but those were taken right after I got emacs running.

Org-mode!

This was where I had some concerns going in. The design of org-mobile was premised on the idea that mobile devices didn't have enough oomph to generate agendas on the fly, so emacs pushes pre-generated agendas. I have fairly large org-mode files. They'd be smaller if I archived to file more often, but I don't. So, is emacs on my tablet able to generate my agendas?

The answer is yes, mostly. The first time I run org-agenda, emacs spends a very long time reading in my org-mode files; I suspect that the slow sdcard I'm running this from may be part of the problem. The first time, it was 30s, but similar 'cold' agenda startups have been around 10s since then. Subsequently, however, the agendas are generated perfectly quickly.

All in all, my orgmode workflow works perfectly on the tablet, with the exception that hg tries to use vimdiff to do merges, for some reason!

Also, one other issue is that since I am using emacs in a (local) terminal window, I have to use the alternate tty keys.

What doesn't work well

Writing a lot.

This is not exactly a surprise. Unless I go to another machine and ssh into my tablet (and what would be the point?), I'm constrained to use the onscreen keyboard. And not only that, it's worse trying to write with the onscreen keyboard in a regular Android app, because the predictive text is not active in ConnectBot.

If I had a small hardware keyboard, I'd be more inclined to do actual writing on this setup.

Another alternative is to let Emacs do the text completion, using either Predictive Mode or auto-complete. However, while both of those do prose completion fairly well (different strengths), neither does autocorrection, which is just as important with a soft keyboard.

Leaving an Emacs session running all the time

I'm used to never exiting Emacs. On my desktop/home-server machine, Emacs is started for me by systemd, which runs it with --daemon, and restarts it if it should ever crash. On my tablet, I started out by running it under screen, and switching back to it as needed. It turns out that this is fine, as long as I want to stay in the Fedora environment, but it doesn't leave enough memory for my usual set of Android apps to perform normally.

Conclusion

I haven't tried the next logical step, which would be to install Xvnc and its dependencies, and to run a local X session, to be displayed in an Android VNC client. I may not do so, because it looks like the keyboard situation in the main free Android VNC clients is not much better (if at all) than in the terminal, in terms of having the full set of keysyms available. And it is worse, in that in ConnectBot, Emacs's screen gets resized to accommodate the soft keyboard, whereas in VNC, the soft keyboard sits on top of part of the display area, which is not resized.

On the whole I'm happy with this experiment. I don't think it will replace my use of Jota for note taking, because of the text auto-completion and auto-correction issue. I'm not sure whether it will completely replace MobileOrg for me. I'm enjoying finding out.

kashnikov: Говорим и пишем правильно

2012-01-19T15:31:29+00:00

Расширение writegood-mode [1] для Emacs помогает аспирантам избежать распространенных стилистических ошибок. Это расширение основано на советах и скриптах от Мэта Майта (Matt Might) [2].

________________________
[1] https://github.com/bnbeckwith/writegood-mode
[2] http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/

Eugene Burmako: емакс, часть 4: ретроспектива

2011-12-10T14:32:42+00:00

емакс, часть 1: первый взгляд
емакс, часть 2: восторг
емакс, часть 3: windows
емакс, часть 4: ретроспектива

Вдохновленный сегодняшним выступлением @alexott на митапе scala.by, я тоже решил поделиться наблюдениями из своего опыта. Экспы у меня не то чтобы много, но постараюсь быть максимально адекватным. Если я чего-то не догоняю, это не со зла - вы меня поправьте, ладно?

1) Емакс действительно крут. Главные его плюсы, на мой взгляд - неинтрузивность, программируемость и естественная интеграция с консолью. Например, недавно я соорудил наколенную билд-систему, с помощью которой застримлайнил свою работу над абсолютно разнородными проектами в универе. Она прекрасно заинтегрировалась в фар, и не менее замечательно - в емакс. Чтобы из емакса запустить какой-нибудь процесс и вбросить аутпут в буфер, нужны буквально пару телодвижений. Повесить на это все хоткеи и сделать гиперлинки на ошибки - еще немного работы. Пару обтачиваний и вуаля: myke-backend.el. Страшно представить, как что-то похожее сделать в Эклипсе.

2) Практически все можно пилить самому. Это прекрасно и очень вдохновляет (например, одним телодвижением можно посмотреть, на какой именно код забинджен тот или иной ключик), но есть и обратная сторона. Практически все придется допиливать самому. Даже банальную ширину таба нужно настраивать секретным образом (см. отдельную настройку для tab-stop-list), что уж говорить про такие вещи как копипасту, анду или прокрутку (кстати, у меня до сих пор через раз работает выделение мышкой). Это не то что бы уж очень плохо, но надо иметь ввиду, что первые пару недель емакс будет отнимать колоссальное количество времени.

3) Лисп не античеловечный, но и не простой в освоении. Довольно быстро я научился колбасить говнокод (что, наверняка, уже увидели уважаемые гуру емакса, пробежавшись по моему конфигу), но что-либо сложное я предпочитаю писать на чем-нибудь другом. Например, билд-система, упоминавшаяся выше, естественным образом выросла из ад-хок сниппетов на елиспе, но попытки превратить ее в что-то более-менее стройное успехом не увенчались, поэтому я по-быструхе переписал все с нуля на сишарпе. Наверняка, проблемы с удобством стандартной библиотеки и структур данных - всего лишь следствие моего несистемного подхода к изучению елиспа, но что вижу, то и пою. В любом случае, крайне помог бложек Стива Йегги, например, вот этот пост: Emergency Elisp.

4) Емакс - не панацея, что бы не писали в инете (по крайней мере для меня). Для разработки компилятора Скалы я юзаю Эклипс (контрол + клик на дефинишен и дебаг слишком важны, чтобы от них отказываться), для коммитов и истории я юзаю TortoiseGit (magit работает через раз + для чего-то нетривиального в VCS тупо нужен гуй). Вначале я думал, что это я такой нехардкорный, а потом увидел, что все в команде делают то же самое (только гуй к гиту другой, ибо никто не сидит на венде). Даже Мартин, который юзает емакс уже лет двадцать.

5) И все же я очень доволен емаксом. За денек я интегрировал в него греп по проектам с персональными свистелками, после чего выкинул поиск эклипса. Для сложных сессий репла Скалы я тоже юзаю емакс (идея консоли в буфере просто прелестна!). Да и домашки по алгоритмам в латеке я тоже фигачу в емаксе, ибо там подсветка синтаксиса и вручную прикрученный side-by-side превью.

Вот так и живем. Браузинг кода и дебаг в эклипсе, компиляция в фаре, текстовый поиск и реплы в емаксе. Use the right tools for the right job. Искренне ваш, кэп.

Andy Legkiy: Организационная пичалька

2011-10-27T22:04:40+00:00

Org-mode очень хороший аутлайнер. Не являясь ярым сторонником емакса, я люблю этот mode всем сердцем.

У меня тут и журнал для личного пользования, и домашние дела, и рабочие дела. Рабочие дела, на одной работе, были и в виде каких-то крупных кусков, разбитых на мелкие подзадачи, и в виде справочной информации, и как неоформленные мысли и черновые наброски. Описание проб, итд. Так как рабочий процесс там полностью устаканен, это почти не создавало проблем. Для второй работы тоже пытался его использовать, но не так успешно.

А в чем же проблема? Да дело в том, что на каждой работе есть свои вики, трекеры, итд. Необходимость использовать разных средства организации дел ведет к дублированию, устареванию одной из копий (или в org-mode, или на рабочих ресурсах).

Если какая-то область новая, и какую-то задачу через время уже видишь под совсем новым углом, то на подгонку своих мыслей, примечаний, добавление новой информации, только в одном "органайзере", уходит определенное кол-во усилий, на которое я c радостью готов пойти. Но, кроме этого, больше усилий уходит на синхронизацию разных источников, ведь синхронизация происходит руками. А вот тут и начинается главная проблема. Отказываться от org-mode не хочется, потому что он очень удобный, быстрый, очень гибкий, и не зависит от наличия интернета. Но и дублировать информацию, перенося из одного формата в другой, разбивая по разным сущностям (страницы wiki, milestone, tickets) -- довольно таки трудно и неприятно.

Попал в ситуация, когда на рабочую систему забиваешь, а в org-mode сильно много не плодишь, а пишешь или справочную информацию, или как-то аморфно, просто забивая на конкретизацию. Ведь знаешь, что когда-то все прийдется переносить руками в другую систему, с другой структурой и организацией поддокументов, и будет большое количества мартышкиного труда.

И вот пришло, нужно использовать рабочую систему, и это не какая-то там бюрократия, а элементарная необходимость.

А что делать? Да пока выбор не большой. Коллегам нужно не только видеть план работ и ход его выполнения, перестройки, уточнения, но еще в нем участвовать.

1. Можно было бы воспользоаться имеющимся html-экспортом, на каком-нибудь рабочем ресурсе, и это было бы неплохим выходом, на начальных этапах. Но для перечисленных выше потребностей коллег оно совсем не расчитанно. Так что, увы, отпадает.
2. Полностью валить на рабочую систему, что и будет сделано, в итоге.
3. Использовать org-mode как буфер для небольших кусков, возможно приделав некоторое подобие простого экспорта. Но это костыль и полумера. После экспорта вся гибкость средств оrg-mode полностью теряется. Кто пользовался, тот знает о чем я. Но без средств автоматического переноса это может привести к очередному накоплению и завалу. Но как добавить дела в кучу, чтобы потом рассортировать, вполне может подойти.

Вот такой небольшой фейл использования для работы замечательного средства организации дел. А жаль.

UPD: Если у кого есть мысли или опыт сопряжения org-mode с популярными средствами управления проектами, буду рад услышать.

kashnikov: Цветовая схема для текстового редактора.

2011-08-22T18:41:14+00:00

Для Emacs я долгое время пользовался какой-то хитрой тёмной схемой составленной из кучи других схем найденных в интернетах. Некоторое время назад перешёл на схему от уважаемого мэтра емаксоведения alexott. Его схема рулит.

Для Vim это torte в консоли. Но в графической версии torte, что называется "бьёт по глазам". Подумываю о переводе схемы alexott для Vim.

Какой цветовой схемой пользуетесь вы?

Ruslan Kosolapov: grundik @ 2011-07-04T11:16:00

2011-07-04T04:16:42+00:00

"Попробуйте, к примеру, дотянитесь одной рукой одновременно до f и p. Клавиши находятся на большом расстоянии друг от друга, и точное позиционирование курсора с использованием стандартных комбинаций – жуткая морока."

Блять!!1111 ЗАЧЕМ дотягиваться одной рукой до кнопок, которые надо нажимать разными руками?!

И вот так у них всё - берут лопату, и пытаются одной рукой ей пользоваться. Зачем блять?! Лопате надо две руки и две ноги, и это фича, а не баг.

Andy Legkiy: Совсем не вовремя заглючил аутлайнер

2011-06-17T11:45:33+00:00

Нашел в org-mode 7.5 ошибку, которая слегка попортила нервы.
В agenda day/week view, при определенных условиях, не отображаются хидлайны, помеченные как scheduled, если используется настройка "org-enforce-todo-dependencies".

Воспроизводится легко. Новый файлик, без каких-либо свойств, всего с тремя хидлайнами, у второго хидлайна есть подзадача, отмеченая состоянием TODO.

* 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>

В day-agenda не отображается "task 2" (второй хидлайн верхнего уровня).

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

Не отображается, но если попробовать выделить и скопировать текст из Agenda (хотя бы строку с "task 1"), "task 2" в буфере будет присутствовать.

Чтобы второй пункт отобразился, нужно:
- Убрать TODO с "task 1",
- Или убрать TODO c "subtask 2-1",
- Или убрать из конфига "(org-enforce-todo-dependencies t)".

Jason McBrayer: Instapaper client for Emacs

2011-04-18T21:00:00+00:00

I'm a serious user of Instapaper, a web site that describes itself as "a simple tool to save web pages for reading later". It's rather more than that, though: it will also reformat pages for distraction-free reading, much like the now-defunct Readability bookmarklet, it works as a social bookmarking service (though I don't really use this functionality), and it will bundle your pending reads into an ePub or Mobipocket ebooklet. There is an official freedom-hating iOS app, and several unofficial Android apps; the one I use is iPaper, which is still a little freedom-hating, but provides offline reading, which just using the website doesn't, barring a strict ePub export/sync routine or some futzing around with wwwoffle or similar.

I use Instapaper to push articles that would otherwise cut into my productive time into my less productive time: adding them from my browser, syncing with iPaper once or twice a day, and reading mostly in the evenings. For saving articles, I mostly use the Firefox add-on Instaright, which is handy because I can add links without following them. Most of the articles I save for later come from Google Reader, which I use mainly from Firefox, so that works well. What didn't work so well was my other main source of linkspam: identi.ca. I use identica-mode for my microblogging needs, so saving a link from identi.ca means a trip from emacs -> follow link to dent or site in Firefox -> Instaright. Obviously this is far too much opportunity to be tempted to read the article now rather than later, so I wrote an Instapaper client for Emacs.

The code is on bitbucket, and the instructions for using it are in the source header. It should be fairly self-explanatory. It saves URLs to your Instapaper account, and can get them either manually, by url-at-point, or, if you have w3m installed, from the current w3m page's URL or selected link. It doesn't provide any services for reading from Instapaper (offline or otherwise), and because of the terms of service on the official API and my lack of desire to do screen-scraping in Emacs Lisp, I don't plan on adding any. A combination of w3m and wwwoffle or polipo is probably your best bet if you need to read Instapaper in Emacs.

Edited to add: Naturally, when I released this, it contained a significant bug, to whit: due to changes in url.el, it only worked in Emacs 24. This has been fixed, though if you byte-compile it under Emacs <= 23, you will get a compile warning.

Alex Ott: Добавления в haskell-mode

2011-02-02T07:44:12+00:00

На новогодних каникулах сделал давно запланированное добавление к haskell-mode - добавил поддержку для hlint (команда hs-lint) и haskell style scanner (команда hs-scan). Как и в предыдущей реализации, hs-lint поддерживает замену кода на предлагаемый вариант.
Патчи отправлены мейнтейнеру, но пока они не закоммиченны в основной репозиторий, эти изменения доступны в моем форке. Замечания и пожелания приветствуются...

swizard: Emacs на nokia n900 tutorial

2011-01-18T17:58:51+00:00

Сабжу весьма благоприятствуют два факта:

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

Разумеется, самое главное во втором пункте -- это наличие железной кнопки Ctrl =)

Итак, воспользуемся следующим туториалом одного нашего японского друга: link.

Продублирую его (на всякий случай) на русском.

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

Далее, нам предстоит решить такую проблему: на клавиатуре телефона отсутствуют очень полезные для емакса кнопки Meta (Esc) и Tab. Наш верный японский соратник предлагает такую клавиатурную карту для English US: link или mirror.

На стандартном английском макете Meta в этой карте работает через Fn+left, а Tab через Fn+right. Лично для меня табуляция вышла очень удачной (не знаю даже, почему), а мета -- ну так, сойдет.

Инсталлируем карту так:

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

Далее, надо решить небольшую проблему с емаксовым фуллскрином. Дело в том, что по-дефолту статусная строка внизу уезжает за пределы экрана.

Японец предлагает поставить специальный мод maxframe.el (здесь mirror). С ним чето мутновато: сначала он у меня не сработал, а после порта моих .emacs.d и .emacs с десктопа, неожиданно заработал. Ладно, пусть его.

В .emacs maxframe.el активируется так:

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

Теоретически, можно тащить настройки и все остальное с десктопа и использовать.

Но для моих нужд (у меня там схемка guile) мне потребовалось кое-что подпилить напильником.

Во-первых, на десктопе я олдфажно использую ctrl+ins / shift+ins для копипаста. На n900 таких кнопок нет, поэтому пришлось перевесить:

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

Ничего, нормально.

Во-вторых, не вызывается экранная клавиатура и спец-клавиатура для символов (по Fn+Ctrl). По-большому счету, мне это нафиг не надо, поэтому я даже не заморачивался. Но пары символов критически не хватает: это угловые скобки < и >. Пришлось их вешать на емаксовые комбинации:

(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)

Ну и пока вроде все, IDE для scheme у меня построился отличный. Все остальное, как на десктопе: guile, quack.el и т.д.

Иногда ловлю себя на мысли, что не хватает кнопок home, end и page up/down, но пока еще нужда лень не победила.

Jason McBrayer: Todochiku notifications in identica-mode

2011-01-04T17:00:00+00:00

Just a quick response to Gabriel Saldaña's recent post on identica-mode notifications: the code for using todochiku for identica-mode notifications is as follows:

(add-hook \'identica-new-dents-hook
  (lambda nil
    (let ((n identica-new-dents-count))
      (todochiku-message \"Emacs Identica-mode New dents\"
                         (format \"You have %d new dent%s.\" n (if (> n 1) \"s\" \"\"))
                         (todochiku-icon \'social)))))

The advantage of using todochiku here is that you can let it handle talking to different notification systems (KDE vs. Gnome vs.Growl on MacOS vs Snarl on MS Windows), and have the same configuration everywhere.

Oleksandr Gavenko: Определение рабочего окружения и возможностей платформы в Emacs

2010-12-21T19:57:37+00:00

Для правильной работы файла настроек .emacs на различных платформах и различных версиях Emacs требуется проверять множество условий.

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

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

emacs-major-version emacs-minor-version window-system - 'nil' if in terminal, 'w32' if native Windows build, 'x' if under X Window window-system-version - for windows only operating-system-release - release of the operating system Emacs is running on system-configuration - like configuration triplet: cpu-manufacturer-os system-name - host name of the machine you are running on system-time-locale system-type - indicating the type of operating system you are using: 'gnu' (GNU Hurd), 'gnu/linux', 'gnu/kfreebsd' (FreeBSD), 'darwin' (GNU-Darwin, Mac OS X), 'ms-dos', 'windows-nt', 'cygwin' system-uses-terminfo window-size-fixed

а также указанные функции:

(fboundp ...) - return t if SYMBOL's function definition is not void (featurep ...) - returns t if FEATURE is present in this Emacs (display-graphic-p) - return non-nil if DISPLAY is a graphic display; graphical displays are those which are capable of displaying several frames and several different fonts at once (display-multi-font-p) - same as 'display-graphic-p' (display-multi-frame-p) - same as 'display-graphic-p' (display-color-p) - return t if DISPLAY supports color (display-images-p) - return non-nil if DISPLAY can display images (display-grayscale-p) - return non-nil if frames on DISPLAY can display shades of gray (display-mouse-p) - return non-nil if DISPLAY has a mouse available (display-popup-menus-p) - return non-nil if popup menus are supported on DISPLAY (display-selections-p) - return non-nil if DISPLAY supports selections

Виполняйте проверки наподобии того как делается ниже:

(when window-system ...) (when (eq window-system 'x) ...) (when (>= emacs-major-version 22) ...) (when (fboundp '...) ...) (when (featurep '...) ...)

Voins: Untitled

2010-10-22T13:41:08+00:00

Обновив coreutils до версии 8.6, обнаружил случайно, что tramp больше не хочет открывать файлы через sudo. То есть это я потом уже понял, что причиной такого поведения стало обновление coreutils, а сначала это было довольно неприятно. Пришлось отвлечься от того, чем занимался, и посвятить вечер разбирательствам с поломкой. Как выяснилось в процессе, кто-то зачем-то поменял формат вывода в утилите stat. Наблюдается это вот так, например:

<new>$ stat . -c "%Y" 1287747411.000000000

Тогда как раньше было:

<old>$ stat . -c "%Y" 1287747411

Tramp пользуется stat'ом для получения атрибутов файлов. Если находит. Можно было, конечно, обмануть его, и заставить думать что stat, который он нашёл, несовместим с тем, что он привык считать stat'ом, но это не наш путь. Наш путь привёл к появлению маленького автомата, определяющего в каком формате нам были выданы циферки, и выдающего правильные и ожидаемые циферки на выходе. Делать полноценный патч мне было лениво. Так что есть только это.

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

Michael Kazarian: What is Python's biggest disadvantage?

Emacs@Habrahabr: Голосование по второй бета-версии Revised 7 Report on Algorithmic Language Scheme (Large Language)

Emacs@Habrahabr: Как начать писать код на Lisp?

Emacs LJ community: Emacs как IDE для Go

Общая настройка Go

Вся настройка в одном месте

Go mode

Go eldoc

Автодополнение

Сниппеты

Переименование функций и структур

Подсветка ошибок

Компиляция и запуск

Тестирование

Локальный Go Playground

Отображение структуры кода

Go guru

Emacs LJ community: Мой первый пакет для Emacs: multi-compile

Alexander Sviridov: Встречайте: undercover.el

Michael Kazarian: python-mode, памятка

Alexander Sviridov: Emacs Lisp Style Guide

Ilya Zonov: EDE боль

Pavel Vyazovoi: Как готовить Emacs в OS X

Установка

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

Emacs Mode в KeyRemap4MacBook

EmacsClient

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

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

org-protocol

Pavel Vyazovoi: Скромное мнение о редакторах текста

VIM (MacVim)

Emacs

Sublime Text 3

Atom

LightTable

Kostafey: Fuzzy matching в popup-switcher с использованием flx

Настройка

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

P.S.

Kostafey: popup-switcher - переключение буферов и навигация по функциям, используя TUI-меню

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

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

TUI в emacs

Установка

Настройка

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

Заключение

Ilya Zonov: Emacs + Java

JDEE

Malabar-mode

Eclime

Auto Java Complete

Cedet Dev

Oleksandr Gavenko: Сортируем без повторений в Emacs.

Eugene Burmako: сублайм =&gt; емакс

Alex Ott: Новая версия статьи про CEDET

Jason McBrayer: Running Emacs on an Android tablet

Overview (the short version, aka tl;dr)

Longer version

What works

What doesn't work well

Conclusion

kashnikov: Говорим и пишем правильно

Eugene Burmako: емакс, часть 4: ретроспектива

Andy Legkiy: Организационная пичалька

kashnikov: Цветовая схема для текстового редактора.

Ruslan Kosolapov: grundik @ 2011-07-04T11:16:00

Andy Legkiy: Совсем не вовремя заглючил аутлайнер

Jason McBrayer: Instapaper client for Emacs

Alex Ott: Добавления в haskell-mode

swizard: Emacs на nokia n900 tutorial

Jason McBrayer: Todochiku notifications in identica-mode

Oleksandr Gavenko: Определение рабочего окружения и возможностей платформы в Emacs

Voins: Untitled

Eugene Burmako: сублайм => емакс