В названии, конечно, отсылка к фильму Spring, Summer, Fall, Winter… and Spring.

Обещал накатить вброс по Emacs, ибо как писали постом выше, народ заскучал. Речь идет о продолжении топика Жизнь после Emacs.

Вообще, суть моего мессенжа, пожалуй, точнее всего передает это короткое видео :).

Но если все же попытаться раскрыть суть чуть подробнее. Да, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки. Никакие элементы архаики, сохранившиеся в Emacs не могут преуменьшить те уникальные преимущества, которых больше нигде нет. Тут дело не в том, что в других редакторах/IDE они хуже или, скажем, они пока недоработанные. Их просто нет.

Итак, в продолжении темы предыдущей серии, я перешел на 1,5 года на VS Code.

Плюсы:

1. Производительность UI, который рендерится на GPU.
2. Производительность JavaScript (спасибо Electron/NodeJS/V8).
3. Вменяемый API.

Минусы:

1. Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.
2. Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов. Тут же 8 плагинов, половина из них заброшена в 2015-м, другая половина помимо необходимой функции добавляет еще 100500 других. Доков нет, докстрингов нет, что кто-то другой будет открывать код плагина и в мыслях не было. Спасибо, если есть ридми, пусть и не обновляемая много лет, и уже не релевантная коду.
3. Культура разработки. Вне официального кода от Microsoft ее нет (см. выше). Писать плагины на ClojureScript возможно, но не вполне натурально (как проба пера, например advanced-navigation-cljs). Да, есть еще joyride. API неплох, да, но многие вещи гвоздями прибиты и всего не настроишь.

Наверное, основной вопрос в плане конфигурации VS Code по сравнению с Emacs в том, что для Emacs можно было не особо переключаясь из контекста текущей деятельности быстренько перейти в .emacs, что-то там подправить и вернуться к основной задаче. В VS Code флоу совсем иной. Если ты вдруг понял, что тебе нужно что-то доконфигурировать, ты понимаешь, что либо на это нужно просто забить, либо мысленно сказать что-то вроде, «ну что ж, а теперь девочки и мальчики мы все бросаем и осваиваем/вспоминаем специальность «конфигуратор/плагинописатель» для VS Code», ибо быстренько что-то подхачить там не выйдет. Например, тебе дополнительно нужен инстанс среды для тестирования изменений плагина. Плагин дописывается, отлаживается и потом устанавливается в рабочую среду. Если же, ко всему прочему, это не твой плагин (что почти всегда), то нужно понимать, что вникать придется долго, ибо комментариев и докстрингов нет примерно никогда (за исключением собственно описания API от Microsoft).

При этом, всегда надеяться на то, что все будет «просто работать» нельзя. У меня например, после очередного обновления как-то отваливалась Calva (Clojure IDE) и edamagit (Magit for VSCode). Опять же, в Emacs у меня тоже были случаи, когда достаточно мейнстримовые плагины приходили с ошибками после очередного обновления. И в этой ситуации всегда можно быстренько это на лету починить, зарепортить багу или сразу прислать пулрек мейнтейнеру.

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

Плюсы:

1. Производительность UI, для чего делаются отдельно UI клиенты. Я по итогу выбрал neovim-qt
2. Производительность Lua. Чуть хуже, чем JavaScript, но сильно лучше EmacsLisp. Впрочем, про производительность UI на относительно больших файлах будет ниже оговорка.
3. Fennel - Lisp, работающий на Lua прекрасен. Это дает в чем-то схожий флоу конфигурации, что и в Emacs, когда поведение меняется на лету (см. подробнее: conjure)
4. Сопоставимая с Emacs экосистема. Например, Magit (для Emacs), Edamagit (для VSCode) и NeoGit (для NeoVim) работают почти одинаково.

Минусы:

1. Модальность. Для кого-то это плюс, я ее не люблю. Я настраивал конфигурацию без модальности. Но тут периодически натыкаешься на ограничение возможностей Vim по тонкой настройке.
2. Менее удобная работа с Fennel, чем то, что предоставляет Emacs для EmacsLisp. На самом деле, они, конечно, не сопоставимы. Т.е. NeoVim не может быть такой же удобной IDE для Fennel как Emacs для EmacsLisp, уже по причине невозможности такой же интроспекции.
3. Довольно причудливый API, многие вещи прибиты гвоздями еще со времен царя-гороха. Например, для некоторой функциональности нет полноценных функций, которые можно было бы вызвать через API, есть только хоткеи, т.е. приходится эмулировать их нажатие для вызова этих функций. Ситуация прежде всего в NeoVim постепенно меняется к лучшему, но до API Emacs пропасть неизмеримых размеров.

Но вот то, что реально заставило меня отказаться от пути использовать NeoVim и планомерно конфигурировать его в соответствии со своими предпочтениями, это то, что на больших файлах он стал повисать прям конкретно на десятки секунд. В Neovim Qt это очень сильно сказывалось. В Neovide лучше, но там нет антиалиасинга. А хотелось бы. В консольной версии аналогично. Отключил все плагины - ситуация не сильно поменялась. И максимальным шоком стало то, что Emacs с этим файлом спокойно работал. Подвисал, да, но на доли секунд.

Про Lapce и Helix, наверное, пока говорить рано, они довольно экспериментальные еще.

В общем, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки.

Решил на досуге попробовать Neovim. Но именно с идеей минимальных ограничений по модальности. Т.е. копирование и вставку текста хотется делать однообразно для всех модальностей. Фактически ключевой вопрос в следующем:

Как сделать ЛЕВУЮ часть курсора основной?

Сейчас поясню что это значит на примерах:

1. Есть текст (здесь и далее # - курсор в режиме команд, который закрывает собой стоящий справа от него символ, | - курсор в режиме вставки):

behave# mswin -> i -> behave| mswin -> C-c -> behav#e mswin

Я ожидаю, что он вернется к позиции behave# mswin. Это можно настроить?

2. Выделяю для копирования слово слева

behave mswi#n -> C-S-left -> behave |mswin

но выделить последнюю букву я не могу, т.к. она стоит в конце строки, а в командном режиме переместиться в крайнюю правую позицию невозможно, таким образом будет выделено слово mswi вместо mswin. Т.е. единственный вариант переключаться сначала в режим вставки, но можно ли настроить редактор, чтобы перемещение в конец строки было возможно в командном режиме?

3. Собственно вставка в командном режиме

behave# mswin -> C-v -> behave msw#imswin

Я тут хотел бы, чтобы текст вставлялся относительно левого края курсора, т.е. в идеале, чтобы результат выглядел так: behavemswi# mswin.

P.S. Что до использования Neovim в соответствии с ожидаемым поведением (т.е. в режиме модальностей), то это, наверное, правильно, но не является темой топика.

Хочу странного. Есть некая модель данных, которая должна быть отображена в читаемый человеком формат. Собственно, пока этих форматов 2: Excel и PDF (через LaTeX). Идея в том, чтобы сформировать некий промежуточный формат до вывода в Excel и LaTeX, чтобы унифицировать код вывода и заодно написать тесты (писать тест, который бы делал дифф полученного и ожидаемого XLSX пока мне кажется диковато).

У кого-то возникали похожие задачи? Есть мысли что это может быть? Json? Markdown?

Краткое содержание предыдущих серий: 12 лет на Emacs.

Нынешняя ситуация: использовал Emacs для работы со Scala (через lsp-сервер Metals). Проблема известная - подвисание UI. Большую часть lsp-ui я уже отключил, стало возможно как-то работать, но все же буквы появляются из-под клавиш весьма не спеша… Частично решается только апгрейдом железа.

Есть попытки как-то решить проблему - прикрутить Webrender использующий GPU, но пока в очень экспериментальном виде:

• https://github.com/remacs/remacs/pull/1581
• https://github.com/emacs-ng/emacs-ng

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

Сразу ремарка по поводу Neovim: насколько я понял, реактивный UI они сделали, но я не люблю режимы. Идея повесить все хоткеи на один режим и расширять редактор в Lua была, но насколько это будет натурально: использование Vim-а без режимов?

Light Table, насколько я понял, более-менее заброшен. Впрочем, с их подходом Data-driven configuration, они могли использовать для конфигурации условный FortranJS вместо ClojureScript (надеюсь, понятно почему :)).

Собственно к VSCode. В продолжении тем:

• История переезда на VSCode
• Обсуждение возможного очеловечивания Emacs
• Emacs vs Atom по производительности

Вот, например, по первой ссылке автор испытывает только положительные чувства от смены Emacs на VSCode. У меня это такого дикого и безоговорочного энтузиазма не вызывает.

Да, конечно, проблемы рендеринга UI там нет как класса. V8 js engine сам по себе демонстрирует шикарную производительность, уже только он шустрее движка Elisp, UI в своем потоке, а главное он наконец-то рендерится GPU, а не CPU. Ок, замечательно, я переместился в будущее: из середины 70-х в наши дни.

Но проблема в том, что в нем нет… Emacs, нет REPL (и я сейчас не про этакую интерактивную командную строку говорю, а про то, что в Emacs все есть REPL - встаешь курсором (точкой) на любом куске кода, выполняешь его, получаешь результат и мгновенно меняешь поведение редактора). И нет s-выражений.

Взять конфигурацию. Вот я редактирую свою тему. Что-то поменял. В Emacs я просто исполняю файл с темой и все - все изменения мгновенно отображаются. Тут у нас что: https://stackoverflow.com/questions/44390765/vscode-how-to-reload-theme-after-editing-its-style Нужно перезагружать редактор? Да ладно? Вообще-то после Reload Window lsp-server тоже перезапускается, ага заново частично компилирует, индексирует.

Далее, хочу M-x function-name. Ну казалось бы, в VSCode такое точно есть. А вот и нет. Хочешь вызвать функцию - назначь ей или алиас или кейбиндинг: https://stackoverflow.com/questions/58382100/triggering-commands-by-their-command-id-or-a-custom-string-alias

Теперь что до файла конфига. Да, изменения в конфиге подхватываются на лету, но для случая симлинков (вот хочется мне конфигурацию в одном месте держать) это работает только если открыт симлинк, а не файл, а не на который он ссылается, а значит гитовый плагин не видит диффа. Ну ладно, допустим. А если у тебя открыто несколько… фреймов, хорошо, окон редактора, например для случая 2-х мониторов, то нужно в каждом открывать конфиг, типа «изменять» его и сохранять, чтобы изменения подхватились. Ну ладно, хоть что-то. Аналогично с темой.

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

К слову, пример плагина на ClojureScript внушает некоторый оптимизм на тему дальнейших возможностей расширений и кастомизаций «как в Emacs»: https://github.com/Saikyun/cljs-vscode-extension-hello-world Правда, насколько я понимаю, ClojureScript по-прежнему не может обойтись без Java, т.к. компиляция макросов происходит в JVM. Проект Lumo выглядит заброшенным. Альтернативы есть?

Вообще, я не сильно люблю статическое созерцание кода. Гораздо удобнее, когда код можно изменять на лету, вылепливая из него что-то как из пластилина и тут же получая результат. И речь не только о собственно конфигурации Emacs. На самом деле, в Emacs, я мог, например, в текстовом выхлопе какого-то генератора вертикально выделить столбик, скопировать его, поставить вверху и внизу скобочку, нажать C-x C-e и получить сумму:

(+ 23,32
-7,04
135,7
-15,22
8) => 144,76

Все. Никуда не выходя из Emacs. В VSCode что? Есть некий плагин eval. Судя по времени выполнения, он запускает nodejs всякий раз. Словом, к возможности тут же вычислить любой объект как код на Elisp привыкаешь очень сильно.

Смотрим на расширения. О культуре разработки, сложившейся в Emacs комьюнити я ужи писал на лоре, но на этот вопрос по прежнему не обращают внимания. Пакет Emacs для того попасть с MELPA проходит код ревью. В итоге, мы имеем докстринги к большинству функций, подробные readme. Да и даже без код ревью люди просто привыкли так писать, это уже стало хорошей традицией. Что в VSCode? Даже у некоторых более-менее популярных пакетов нет ни одного комментария, ни одной докстроки к функции в исходном коде. В менее популярныйх пакетах - спасибо, если есть readame, а от бывает и его нет.

P.S. Пока складывается впечатление, что я снял свой старенький экзоскелет и взял вместо него каменный топор. Да, экзоскелет был старенький, ржавый, и краска облезла, и скрипел весь, и гидравлика протекала, и проводка искрила и коротила, местами была обильно замотана изолентой, некоторые болты были жевачкой прилеплены, чтобы не отвалились и потерялись, некоторые вообще приварены. Там что-то приходилось периодически чинить, подкручивать, приклеивать ;). Но в нем можно было и дом перепрыгнуть и машину поднять и нашествие пришельцев, при необходимости, остановить. А каменный топор, да из обсидиана, да со стразиками, да с удобной сенсорной панелью на рукоятке, да с авианосцем в комплекте, но все же не то. Вот теперь сижу и думаю как его доработать напильником до звездолета.

P.P.S. Да, я понимаю, что весь мир не обязан быть Emacs-ом, но ведь люди уже переходили из Emacs и не вчера, наверняка эти проблемы уже как-то решились. Какие-то сушествуют решения, рекоммендации, комьюнити?

P.P.P.S Вот так и представляю себе группу психологической поддержки, тех кто ушел из Emacs. Захожу в комнату, там в форме круга расставлены стулья, на них сидят такие же бывшие емаксеры. Я говорю: «Привет, меня зовут Костя и я перестал пользоваться Emacs.» и все такие: «Привет, Костя». :))))))))

Добрался обновить Emacs на Винде. Результат - некорректное отображение русских букв.

Картинка: https://drive.google.com/file/d/1LLSfQfQPNds5hgj3wf9OXgeFcwbX-JmC/view?usp=sharing

С emacs -q аналогично. В 26.x все было ок. Шрифты юникод поддерживают, но на всякий случай попробовал разные - аналогично.

Кто сталкивался, как чинить?

Собственно идея в том, чтобы выбрать такой дистрибутив, которым можно будет пользоваться действительно долго, но что бы при этом он оставался сравнительно простым в обслуживании. Сейчас на компе у меня стоит Debian, ему уже много лет. Это почти хорошо, но есть проблемы. Например, я не делаю Dist-upgrade, т.к. обычно это приводит к тому, что существенная часть ранее работавшего софта отваливается - приходится просто ставить новый дистрибутив с нуля. Это тоже не такая проблема, т.к. конфиги сохраняются, но все же… Поэтому, дабы продлить срок жизни текущей инсталляции, я просто ставлю софт тот который можно через dpkg -i или checkinstall, который так не получается, что через make install или просто в /opt. Но и у такого подхода есть предел - рано или поздно, но новый софт начинает требовать зависимостей, которые сложно или невозможно установить вручную, а пакетный менеджер ссылается на недостаточно новые версии пакетов. Кроме того, со временем это только снижает maintainability и уменьшает вероятность успешного Dist-upgrade.

Казалось бы, очевидный выбор - rolling-based дистрибутив. Пробовал Arch - ничего не понял: настройка всего того же, что было в Debain занимает на порядок больше времени, но это ладно, Youtube в Хроме хочет звук через Alsa, а вот Скайпу подавай Pulseaudio (или наоборот - не помню уже). Ок настраиваем так, что бы при запуске Скайпа одно включалось, другое выключалось. Здорово. 3 дня пользуюсь. Прилетают обновления - звук пропадает вообще весь.

Чем больше я читаю про Gentoo, тем больше у меня понимания, что в обслуживании он еще более трудоемкий, чем Arch.

Беглый просмотр того, что есть в Nix показал, что там далеко не всегда можно так же легко и просто найти готовый пакет как, скажем, в Debian или Arch.

Подскажите в какую сторону копать? Нужен простой в обслуживании Linux, который может работать с новым софтом в течение многих лет.

Расскажите на чем сегодня прогрессивное человечество пишет динамические опердени для веба на Common Lisp. Гугл выдает кучу веб-серверов, библиотек и фреймворков разной системы закваски и поддерживаемости. Планируется отдача статического контента + динамика через рест. Посоветуйте стек библиотек.

Посоветуйте легковесный браузер, графический. Кроме шуток. Памяти мало. Хром прекрасен, но оно памяти съедает вагон. Лиса туда же. Всякие lynx, elinks для работы не годятся. Шутки про память тоже не интересно, все что может в принципе поддерживаться материнкой уже установлено.

Поставил midori - оно гуглом не поддерживается, старый мол. Ну и так, ошибки бывают по мелочи.

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

~/.Xresources:

...
URxvt.perl-lib:                ~/.urxvt/ext/
URxvt*perl-ext-common:         fullscreen,default,clipboard,keyboard-select,tabbed
...
URxvt.keysym.Control-w:        perl:tabbedex:kill_tab

> xrdb ~/.Xresources

Расширение tabbedex пробовал искаробочное (rxvt-unicode (urxvt) v9.20 - released: 2014-04-26) и какой-то форк в ~/.urxvt/ext/ добавлял.

Control-w не работает, Control-d работает. ЧЯНТД?

Лет 8 пользуюсь Emacs. По функционалу вопросов нет, но вот под оффтопиком тормозит (банально низкая отзывчивость на ввод символов, перемещение курсора, форматирование кода, переход на просмотр дифов в магите и т.д.). Под онтопиком - тоже не фонтан, но намного лучше. Плагинов много, самопального кода тоже много, но почти без ненужных излишеств, т.е. почти все что подключено, так или иначе используется.

Соответственно вопрос, стоит ли смотреть на что-то более хипстерское, молодежное, современное, типа Atom? Не получится ли так, что освоив его, накачав необходимых расширений, написав свои расширения и конфиги получишь тормоза еще большие чем в Emacs?

Перемещено tailgunner из development

Тему organic-green запилил давно. Обычно у публики она вызывает изумление (иногда недоумение), но я сколько не пытался, перейти на что-то более общепринятое так и не смог (ни темные, ни светлые не подошли). Зеленое на зеленом почему-то меньше всего напрягает. Может на ЛОРе найдутся те кому это тоже понравится )).

Дистр Arch, stumpwm. Еще скрины с зеленью:

• Емакс в png
• Консолька
• Обои с коньками

Шрифты в emacs и urxvt - Fira Mono Medium, в stumpwm - Terminus.

>>> Просмотр (1680x1050, 595 Kb)

Если некоторое время работать в Emacs (с включенным CUA), то через некоторое время CUA начинает тормозить (при любом значении cua-prefix-override-inhibit-delay). А потом и вовсе повисать.

Выделил текст, нажал C-c. Текст не скопировался, выделение не исчезло. Т.е. Emacs находится в режиме бесконечного ожидания override key. Если нажать, например, любую клавишу движения курсора, то произойдет все необходимое: текст скопируется, выделение исчезнет, курсор переместится. Это ужасно раздражает.

Пробовать искать такое поведение с emacs -Q нет смысла, т.к. проблема возникает случайно и непредсказуемо через несколько минут/часов (как повезет) использования emacs. Отключать различные режимы после того, как такие зависания начались (искать виновного) тоже бесполезно - проблема сохраняется после отключения всех кастомных режимов.

Сейчас для меня это блокирующая функциональность более широкого использования Emacs.

Кто-нибудь сталкивался? Как дебажить? Если, что вполне возможно, проблема в .emacs/одном-из-расширений, то как найти сбойный модуль/фрагмент кода? Автоматическое редактирование (небольшой тест набросал: https://gist.github.com/kostafey/8594475) не приводит к появлению ошибки, только ручное редактирование.

UPD: Emacs 24.3.1. OS: обе Windows и Linux (одинаковая картина и там и там).

Есть какие-нибудь современные средства проверки кода на лету в emacs для java?

JDEE & malabar-mode не поддерживаются.
Emacs вики читал, но там тоже не шибко все актуально. И потом, это получается нужно только make-ом запускать, т.е. make-файл для java-проекта должен быть? По-другому нельзя?

Сейчас вроде как flymake вообще не слишком активно развивается, а flycheck - это стильно, молодежно, современно. Кто-то даже flycheck-java пытается пилить. Это конечно выглядит как кустарное решение, но лучше чем ничего и, возможно даже (еще не пробовал), работает.

Словом, просьба сориентировать меня, если кто в курсе, в какую сторону копать.

И да, я в курсе, что emacs с java - это ССЗБ, вещества и т.д. и т.п., если кто-то хотел меня удивить ;).
Многое не работает - да, но многое и работает, и хорошо работает.

Инициализирую plist как nil.

(setq pl nil)
(lax-plist-put pl "a" '(1 2))
pl

pl - nil

Инициализирую plist как (nil nil).

(setq pl '(nil nil))
(lax-plist-put pl "a" '(1 2))
pl

pl - (nil nil «a» (1 2))

Я понимаю, что nil - не совсем лист (хотя формально равно '()) и такой код не работает:

(setq pl nil)
(add-to-list pl '("a" '(1 2)))

Так как можно создать plist чтобы потом наполнять его, не делая при этом предположений относительно того есть там элементы или нет?

Ранее уже обсуждался этот вопрос

http://www.linux.org.ru/view-message.jsp?msgid=2446507

однако, я так и не смог понять как настроить одновременную работу словарей.

Версии ПО:

• GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
• International Ispell Version 3.1.20 (but really Aspell 0.50.3)

Фрагмент .emacs:

(setq-default ispell-program-name "aspell")
(setq ispell-dictionary "english")
(setq ispell-local-dictionary "russian")
(setq flyspell-default-dictionary "russian")

При таких настройках

M-x ispell-buffer проверяет правильно только русский текст английский текст распознается как ошибка, варианты замены не предлагаются.

flyspell-mode проверяет русский текст, английский игнорирует.

В упомянутой выше ветке предлагают использовать ispell-multi

http://www.dur.ac.uk/p.j.heslin/Software/Emacs/Download/ispell-multi.el

Располагаем файл ispell-multi.el в load-path

Фрагмент комментариев из ispell-multi.el:

;; If all you want to do is to change the behavior of ispell so that
;; it uses multiple ispell processes for different buffers, then
;; (require 'ispell-multi) is all you need to do.

Добавление этой (require 'ispell-multi) строчку в конце фрагмента .emacs:

(setq-default ispell-program-name "aspell")
(setq ispell-dictionary "english")
(setq ispell-local-dictionary "russian")
(setq flyspell-default-dictionary "russian")
(require 'ispell-multi)

не изменяет поведение, добавление (require 'ispell-multi) в начале фрагмента .emacs приводит к следующим ошибкам:

M-x ispell-buffer

Starting new Ispell process [english] ...
apply: Creating process pipe: no error

M-x flyspell-mode

Starting new Ispell process [english] ...
Enabling Flyspell mode gave an error

Подскажите решение.