Да причем здесь хук на хуке

При том, что пока они не выполнятся, реакции интерфейса не будет.
Я у себя такие проблемы отлавливал.

Про винду ничего не знаю, у меня её нет.

Даже emacs быстрее, чем intel atom.

linum нужен

не нужен, ну вот вообще, в modeline текущая линия отображается + осиль закладки и avy

nlinum vs no nlinum

https://postimg.org/image/awvy11zdj/

Кстати про nlinum и emacs24 Патч для работы nlinum в emacs daemon mode

Решение. Хинт emacs на windows почему-то вызывает gc гораздо чаще. По ссылке решение с помощью тюнинга настроек gc.

cast Kostafey

Отрисовка в emacs реально тормозная

Просто собирайте/используйте емакс с athena, и все будет если не летать, то ехать с приличной скоростью.

подсветка синтаксиса тоже не фонтан - на больших файлах с «макаронным» кодом бывает дико тормозит

Это наверное из-за тормозного cc-mode, но тут, пожалуй, ничего особо не поделаешь. Его можно подтюнить, но супер быстро оно рисовать не будет, это правда.

Просто собирайте/используйте емакс с athena

Ты понимаешь саму ущербность такого совета? Можно ещё в консоли запускать да. Сам использую с athena, жить конечно можно, но до плавности отрисовки/скроллинга очень далеко.

Это наверное из-за тормозного cc-mode

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

ничего особо не поделаешь

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

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

Это верно лишь отчасти. Ядро emacs действительно однопоточное и это накладывает свои ограничения. Но их возможно обойти. Например, js2-mode раскрашивает код асинхронно.

Ты понимаешь саму ущербность такого совета? Можно ещё в консоли запускать да.

Нет, не понимаю. Расскажи.

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

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

Нет, не понимаю. Расскажи

Рассказываю - ты предлагаешь использовать костыль, вместо того чтобы решить проблему.

Это из-за того, что емакс красит код на тормозном елиспе

В этом вообще вся суть эмакса же.

Можно вынести обработку в отдельный процесс. С 25го можно вынести в отдельную либу. Но некому этим заняться

Никто и не будет в массе, т.к. это тоже костыль. Нормальное решение это: 1.сделать многопоток на лиспе, 2.комипилировать лисп в натив. Т.е. то что можно сделать на CL. Но «некому этим заняться».

Рассказываю - ты предлагаешь использовать костыль, вместо того чтобы решить проблему.

Костыль - это билды на gtk, от которого ничего кроме панелек и меню не используется. А тормозит он сильнее.

В этом вообще вся суть эмакса же.

Суть емакса в удобстве работы с текстом. Не все что происходит в емаксе реализовано на елиспе.

Никто и не будет в массе, т.к. это тоже костыль. Нормальное решение это: 1.сделать многопоток на лиспе, 2.комипилировать лисп в натив. Т.е. то что можно сделать на CL. Но «некому этим заняться».

комипилировать лисп в натив

Ну, да. Дополнительно 40 метровый рантайм компилятора - то что нужно.

Дополнительно 40 метровый рантайм компилятора

JIT же, что вроде бы в теории должен принести guile emacs (но неизвестно когда, т.к. людей нет). Или +40м рантайм это про него?

JIT же, что вроде бы в теории должен принести guile emacs (но неизвестно когда, т.к. людей нет). Или +40м рантайм это про него?

40 - это про CL.

40 метровый рантайм компилятора - то что нужно

Да, это то что нужно, т.к. это намного лучше чем во всяких эклипсах. У меня сейчас эмакс отжирает 200метров оперативки просто потому что открыто ~150 файлов.

Суть емакса в удобстве работы с текстом

Это удобство достигнуто только за счёт того что редактор построен вокруг elisp.

Не все что происходит в емаксе реализовано на елиспе

Что касается редактирования - всё.

Костыль - это билды на gtk, от которого ничего кроме панелек и меню не используется

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

guile emacs

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

есть надежда на то, что когда-нибудь большинство нетухлых пакетов можно будет легко перевести на CL.

Маловероятно. Очень много своих нюансов в emacs lisp. А переписывать все пакеты ради сомнительной выгоды авторы не побегут. Сколько емаксоклонов на CL сдохло? Что-то никто не ринулся портировать. В guile emacs идут другим путем - добавляют в vm elisp. В долгосрочной перспективе может взлететь.

В guile emacs идут другим путем - добавляют в vm elisp

Это будет какой-то странный guile без лексической видимости. А просто эмулировать/транслировать elisp можно и в CL.

Это будет какой-то странный guile без лексической видимости

Просто в guile-emacs ты сможешь использовать как пакеты на elisp, так и пакеты на guile scheme.

Правда оно еще очень сырое. К использованию пока непригодно совершенно. Там еще не все реализовано, а оптимизаций нет совсем.

замени на vim

так и пакеты на guile scheme

И как они предполагают протакскивать в elisp vm окружение которое делается в guile vm, замыкания например?

И как они предполагают протакскивать в elisp vm окружение которое делается в guile vm, замыкания например?

Они не собираются использовать elisp vm.

но не люблю модальность.

Наоборот — это красиво..
оживляет текстовый интерфейс...всмысле в текстовом интерфейсе модальные окна прекрасны
но на вкус и цвет
[да] [нет]

Да, это то что нужно, т.к. это намного лучше чем во всяких эклипсах. У меня сейчас эмакс отжирает 200метров оперативки просто потому что открыто ~150 файлов.

Мне бы так :(

ps -o rss= -p `pidof emacs`
1268528

Это удобство достигнуто только за счёт того что редактор построен вокруг elisp.

Это удобство достигнуто вменяемым интерфейсом с вменяемым минибуфером. С тем же успехом он мог бы быть написан на питоне, например.

Что касается редактирования - всё.

scroll-down is an interactive built-in function in ‘C source code’.

В целом, зависит от точки зрения, конечно..

Ну да, кроме того, что интегрируют редактор в современное окружение.

Чем же интегрирует? Может переключалкой языка?

На вяленого тоже с афиной переезжать планируешь?

Я надеюсь что замутят нормальный родной бекенд, а не это убожище.

Вы его под виндой пробовали пользовать? Особенно 25-й.

https://www.emacswiki.org/emacs/EmacsLispProfiler

Получил каккие-то цифры на self-insert-command и next-line. Ммм... это мне должно о чем-то сказать?

Почитай тут: http://tonsky.livejournal.com/306545.html

Классная штука. Да, провел замеры. Результаты буквально удручающие.

                Min,ms   Max,ms   Avg,ms   SD,ms
Emacs           100,4    416,5    240,1    78,6
Atom            61,0     99,8     84,6     8.1
IntelliJ IDEA   16,3     50,0     28,2     7,7

Сиди на емакс так как всякие Sublime'ы, Atom'ы - говно.

По функционалу - да. По отзывчивости - ...

Да я тоже видел как в маках Emacs летает. Неплохо и на линуксах. Я в разных системах работаю. Сейчас часто в винде. Хочется иметь единую среду для всех.

А то понаставят пакетов, а там хук на хуке и хуком погоняет после нажатия каждой кнопочки.

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

Да причем здесь хук на хуке, если проверка орфографии под виндой в emacs тормозит просто жутко. И отзывчивость интерфейса страдает - периодически подлагивает. Atom намного приятнее под виндой.

+1. Хотя был несколько неприятно удивлен, что до функционала емакса еще до луны пешком...

не нужен, ну вот вообще, в modeline текущая линия отображается

Так, мне linum нужен. Я в курсе про modeline, спасибо да.

+ осиль закладки и avy

Я за старый добрый ace-jump-mode.

nlinum vs no nlinum

https://postimg.org/image/awvy11zdj/

Спору нет. Можно вообще все отключить. Возможно linum и вкладывает существенный вклад в падение производительности, но мне он нужен.

Кстати про nlinum и emacs24 Патч для работы nlinum в emacs daemon mode

Ок, взял nlinum, поставил патч, смотрим:

                    Min,ms   Max,ms   Avg,ms   SD,ms
Emacs linum          100,4    416,5    240,1    78,6
Emacs no [n]linum     33.2    299.7    129.0    71.4
Emacs nlinum          34.2    333.4    150.4    72.4

Да, верно, отличная штука. Спасибо!

Решение. Хинт emacs на windows почему-то вызывает gc гораздо чаще. По ссылке решение с помощью тюнинга настроек gc.

Почти не сказалось на производительности (по сравнению с переходом на пропатченный nlinum), но все равно спасибо.

Просто собирайте/используйте емакс с athena, и все будет если не летать, то ехать с приличной скоростью.

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

принести guile emacs (но неизвестно когда, т.к. людей нет)

Баян. Отказались уже от этой идеи года полтора назад.

Наоборот — это красиво..
оживляет текстовый интерфейс...всмысле в текстовом интерфейсе модальные окна прекрасны но на вкус и цвет [да] [нет]

Нет, имелась в виду модальность редактирования текста, когда ты переключается между режимом вставки, командным и визуальным (в виме). К этому я привыкнуть не смог.

А вот модальные окна в текстовом интерфейсе - это совсем другое дело, это часть концепции TUI (в противовес GIU и CLI). Я сам большой фанат и энтузиаст TUI.

А зачем мне его юзать под виндой?

А зачем мне его юзать под виндой?

Работать можно и нужно на разных машинах. На них -внезапно- бывают различные ОС, это нормально.

-----------------
| Краткое резюме |
-----------------

• overall. Atom - штука симпатичная. Красивый рендеринг, плавный скролинг, быстрый ввод символов. Но до полного перечня возможностей Emacs ему пока весьма далеко (если они вообще когда-либо могут быть реализованы).
• magit. Например, magit для atom есть в полузаброшенном виде atomatigit. Оригинальный пакет Atom для работы с git git-plus гораздо менее удобный.
• paredit. Что касается paredit и paredit-everywhere, то в Atom есть несколько подобныйх пакетов. Все они в полузаброшенном состоянии и реализуют примерно 3-7% функциональности оригинальных.
• cursor movements. Какая-нибудь тривиальная forward-sexp из elisp, реализуется через сторонний пакет bracket-matcher, который умудряется недотягивать до функциональности исходной forward-sexp.
• commands. Хотите навигации по истории команд? M-x up/down - подожите или напишите свой плагин.
• extensibility. Все еще верите в хакабл текст эдитор фо зэ твенти ван сентури? Ну так вот, чтобы выполнить код для расширения редактора без его перезагрузки, нужно ставить дополнительный плагин run-in-atom, искаропки этого нет. Интерактивность расширения в целом есть, но все же не так удобна как в Emacs.
• packages. Что касается самих пакетов. Сформировавшееся вокруг Emacs комьюнити, весьма хорошее с моей точки зрения. Есть отличные гласные и негласные стандарты написания и документирования кода. Теперь попробуйте поищите комментарии или документацию к функциям в Atom даже в стандартных пекетах, неговоря уже о сторонних.
• self-documented. Самодокументированность. Атом в этом направлении как-то и не очень даже планирует двигаться. Т.е. непохоже, чтобы мы когда-либо увидели что-то подобное C-h f <function-name> в Atom.
• space-atom Из хорошего есть proton - пакет делающий из Atom Spacemacs, расширяемый на clojure-script. Но я пока не понял можно ли там как-то с clojure-script интреактивно работать (как с elisp) для изменения функциональности редактора налету или только после предвариельной компиляции в JavaScript.

  Хорошие отзывы также о nuclide, но сам пока не пробовал.

Работать можно и на своей машине.

Работать можно и на своей машине.

Ну можно, так можно. Как скажете. ;)

Так а всё же, что там под виндой в 25-й версии атома?

Так а всё же, что там под виндой в 25-й версии атома?

Какого атома? Atom сейчас 1.10.2. Я про Emacs 25. В начале отвечал на коммент

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

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

Понял, невнимательный, моя вина.

Из того же треда:

I tried the different builds. IMO the 64-bit build was noticably slower than the previous (and current) 32-bit, so in the end, I decided to stick to the 32-bit builds.

I've removed the automatic visual-line-mode from my config and given myself a keybinding to quickly toggle it, in case I ever do need it (probably this will almost never be the case). What an easy way to get a huge performance boost. Thank you so much!

Not your specific issue but... Opening files on emacs in MS-windows is extremely slow. The file-file-hooks invoke version control magic for every single file you open. In emacs 25 a different hooks needs to be removed to get rid of the nonsense.

(if (>= emacs-major-version 25)
    (remove-hook 'find-file-hooks 'vc-refresh-state)
  (remove-hook 'find-file-hooks 'vc-find-file-hook))

I tried the different builds. IMO the 64-bit build was noticably slower than the previous (and current) 32-bit, so in the end, I decided to stick to the 32-bit builds.

А где-то есть вменяемые сборки? Я что-то не могу нагуглить.

I've removed the automatic visual-line-mode from my config and given myself a keybinding to quickly toggle it, in case I ever do need it (probably this will almost never be the case). What an easy way to get a huge performance boost. Thank you so much!

visual-line-mode и не использовал. Использую fill-column-indicator, может он тоже вносит свой вклад в падение производительности, но штука удобная.

Opening files on emacs in MS-windows is extremely slow.

Ну у меня такой проблемы и не было. Убрал хуки как в примере - разница на глаз незаметна.

Вообще, даже в Vim DirectX прикрутили. В Emacs пока подобное только периодически обсуждают.

Да я тоже видел как в маках Emacs летает.

А я не видел) Emacs хуже всех поддерживает macOS, только 25 перестал тормозить на больших файлах. Как быстрый пример: cегодня Yamamoto Mitsuharu прислал патч на мой баг-репорт о неправильной ширине глифов под macOS. По отзывчивости в порядке убывания: Linux, Win32, macOS. Винда правда есть только в виртуалке и это XP.

Можно вообще все отключить. Возможно linum и вкладывает существенный вклад в падение производительности, но мне он нужен.

А я показывал что он практически не влияет на производительность. Latency ~4ms без патча. Мой развесистый конфиг стартует за 1s и я не пользуюсь режимом демона.

Результаты буквально удручающие.

Ошибка среднего >70ms а минимальный отклик 100ms, - это очень много, такое ощущение что gc дергается после каждого символа. проблема на вашей стороне, вооружайтесь профайлером.