Emacs таинственный: Путешествие в калькулятор

[xytop]

Плюсанул,
редактор мощный, статья интересная :)
Но пробовать примеры и пытаться снова попытаться победить Emacs желания нет.
Это прошлый век уже.

[Anton_Menshov]

Кроме пары vi\emacs я не встречал ни одной среды разработки, с помощью которой можно разрабатывать высокопроизводительные приложения, в частности — для суперкомпьютеров. MPI\OpenMP, параллельное программирование на десятках-сотнях узлов, разработка через SSH. Вдобавок, что есть мощного и абсолютно совместимого для комфортной разработки консольных (!) приложений на Mac\Windows\Linux, в которых среда ведет себя на 99% одинаково? :) Разумеется, то, о чем говорю я — специфическая разработка. Но точно не разработка прошлого века, но нынешнего.

[xytop]

На все это ответом будут продукты от JetBrains. Ну или эклипс/netbeans как бесплатная альтернатива.
Vi/Emacs — это не среды разработки, а редакторы. К тому же на серверах по умолчанию стоит только vi, а Emacs нужно устанавливать отдельно.

[BelBES]

А JetBrains/Eclipse/Vi позволяют работать только при помощи клавиатуры, без использования мыши?

а Emacs нужно устанавливать отдельно.

Так Emacs и не нужно на сервер ставить, ему достаточно ssh доступа, чтобы на удаленном ПК работалось также как и на локальном.

[xytop]

Позволяют конечно.

[Anton_Menshov]

Vi\Emacs могут быть средами разработки в зависимости от обвеса.
Расскажите мне, как человеку, которые НЕ пользовался больше пары часов ничем из JetBrains, и который пару лет кодил в Эклипсе. Что же я получу при помощи Eclipse\NetBeans\JetBrains, чего я не имею в Emacs? Где же будет та гибкость в настройке emacs, что-то я сильно сомневаюсь в сопоставимой конфигурабельности вышеупомянутых продуктов.
Более того, имея файлик настройки emacs, я легко переношу его на другие кластеры, и наслаждаюсь стандартной для меня процедурой разработки. Переключение: Latex\C++\Fortran\Python в мгновение ока? :)

[xytop]

что же я получу при помощи Eclipse\NetBeans\JetBrains, чего я не имею в Emacs?

Например умное автодополнение по проекту и подсветка/исправление ошибок/предупреждений, все это с учетом контекста.
Умный рефакторинг…
Ни для vim ни для Emacs такого не написали еще. Есть всякие ctags и подобные, но им слишком далеко до JetBrains, потому что регулярки не могут быть лучше AST.
Тут можно больше посмотреть: https://www.jetbrains.com/idea/features/

[kx13]

При использовании продуктов JetBrains ты получаешь уже готовую и настроенную среду для разработки на определенном языке (Java, Php, Python, C++).
Все то же самое (или практически все) можно настроить и в Emacs, но для этого надо потратить некоторые усилия (найти и настроить большое количество пакетов). Вот и вся разница по сути.
Но если при использовании продутов JetBrains ты отходишь от использования заранее определенного набора языков (например захотел покодить на Fortran) ваша крутая IDE превращается в обычный редактор уровня Notepad++.
Пользователь сам выбирает что ему важнее в данный момент: просто работать, используя готовый набор операций, может не всегда оптимальный, или потратить время и сделать так как нравится лично ему.
В общем цели у продуктов JetBrains и Emacs слегка разные, поэтому меряться у кого круче фичи совершенно бессмысленно.

[xytop]

Для фортрана это может быть и будет обычный Notepad++, но для поддерживаемых языков и диалектов (а их 178 поддерживается, просто подключаем плагин) интеграция будет гораздо глубже.
И я снова вставлю: emacs — это не IDE, а редактор.

[Anton_Menshov]

Учитывая, что граница между IDE и редактором довольно абстрактна, особенно, в случае с конфигурабельным и имеющим богатый набор пакетов emacs, — спор довольно бессмыслен. А вот что я точно вставлю, так это «emacs — это не прошлый век.» Я думаю, весь тред это довольно неплохо аргументирует.

[teleavtomatika]

Дайте я угадаю. У вас проблемы с версткой потому, что вы текст в эмаксе набирали?

[BelBES]

А какие у emacs могут быть проблемы с версткой, при живом org-mode?

[teleavtomatika]

Я про то, что в статье каждая вторая строка половинной длины. Не видите?

[samo-delkin]

Сегодня время выкроил и склеил строки через сочетание Ctrl + u + Alt + ^, записанное в макросе :)

[samo-delkin]

Сначала в org-mode всё набрал, потом перевёл на хабра-стайл. Это надо было все лт гт менять, пробелы он тоже съедает (даже в тегах code). Благо в Emacs'е это всё делается быстро, учитывая то, что у меня сделан ещё режим для Хабры, в котором эти вещи автоматизированы. И, естественно, всё это под гитом.

[BelBES]

Хм, теперь вроде как можно практически из коробки делать конвертацию org -> markdown, а Хабра умеет понимать маркдаун.

[samo-delkin]

Markdown она как-то криво приняла, заголовки второго уровня не стала вообще выделять. Кстати, галки "запрещать склеивание строк" не стояло. Если в прошлый раз (прошлой статье) они склеились и смайлики удалились, то в этот раз ничего такого не произошло.

[kostyfisik]

Ещё есть вариант in-place evaluation. Прямо в тексте, где потребовалась какая-то цифра, вводишь выражение для её вычисления (например 3.14*2.718^2), выделяешь его, нажимаешь hotkey — получаешь результат (23.19682536). Это заметно быстрее, чем копировать в буфер, переключаться в калькулятор, делать счет, переносить результат обратно… Типичный пример применения: в тексте часть значений оказалась в дюймах, их надо перевести в сантиметры… Макросы для этого доступны тут http://blog.jorgenschaefer.de/2012/03/emacs-snippets-calculation-helpers.html

[kx13]

У такой методики есть только один недостаток: если пользуешься этим редко, то быстрее скопировать и запустить калькулятор, чем вспоминать хоткей.

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

[kostyfisik]

Против этого помогают хорошие комментарии в .emacs и полнотекстовый поиск. Много раз проверено :) Тут тот же принцип, как только раз пять попереключаешься туда-обратно с калькулятором, подумаешь что в Emacs это могло бы быть сделано и поудобнее, и сразу вспомнишь, что это уже есть в твоём .emacs. Найти нужное место — дело одной минуты (или меньше..)

[samo-delkin]

Там пример про лису как раз это и делает — вычисляет корень на месте.