Ричард Столмен - Руководство по GNU Emacs - 1999 всё ещё актуально?

База осталась той же. Акценты сместились, но это легко добрать по необходимости.

Самое главное - elisp, остальное приложится

Я лет десять поначалу использовал emacs с уровнем знания elisp’а (setq переменная значение) и для базовой настройки хватало.

Зачем читать какую-то воду для «универсального» редактора? Высокий порог входа не делает его хорошим решением. Если ты на Linux, то посмотри в сторону Kate (KDE), или же в VSCodium (если любишь open source). Готовые и хорошие решения из коробки. Если ты пират, то качай sublime text. Конечно, все эти варианты не подходят для сложной разработки, но если стоит цель просто открыть проект и глянуть что там, то они подойдут. Хорошая программа - это та программа, в которой не надо долго разбираться.

Охренеть просто. Вместо того, чтобы один раз прочитать документацию на emacs и потом просто пользоваться им десятилетиями, нужно скакать между kate и vscodium, пиратить sublime, а потом они ещё и для сложной разработки не годятся (на что они вообще нужны тогда?). Количество лишних телодвижений и умственных затрат с emacs’ом как раз минимальное.

Kate (KDE), или же в VSCodium

Так много ошибок в слове VIM.

Не нужно скакать, достаточно просто использовать Kate.

Вим и имакс это к Эскобару.

Шуткую, сам-то я использую kwrite и geany, а vi только если иксы упадут.

Не нужно … использовать Kate.

Ну да конечно, нужно использовать ваше недоразумение из 70-х в 2026 году, очень смешно.

Вместо того, чтобы один раз прочитать документацию на emacs и потом просто пользоваться

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

Зачем? То, что используешь часто, и так помнишь. Редкие вещи происходят редко и делаются скорее через команды (там же можно и аккорды подсмотреть), которые как-то более-менее осмысленно называются.

Зочем так извращаться?

Альтернатива-то какая? Если есть автоматизация для редкого действия, то тут или помнить, или записать в документации. Других вариантов не просматривается. Разве вручную всё сделать, но вам emacs в режиме блокнота точно так же никто не запрещает использовать.

но вам emacs в режиме блокнота точно так же никто не запрещает использовать

В качестве блокнота можно использовать что угодно, например у нас некоторые студенты Kompas 3D используют для набора текстовых документов. Но правда жизни такова, что блокнот в качестве блокнота, заруливает любой не-блокнот, в том числе и имакс. Потому что блокнот это изначально, by design - блокнот. А имакс by design это лисп-машина. Общее решение не может быть эффективнее частного узко заточенного, такова философия.

Вы теоритезируете, а это неинтересно.

Ну да конечно, нужно использовать ваше недоразумение из 70-х в 2026 году, очень смешно.

Ты так говоришь, как будто в 2026-м году кто-то осилил написать альтернативу.

Я тут узнал, в kwrite есть всё, что нужно домохозяйке, но оно легче, чем Kate

Смотря для каких задач, может и так.

LaTeX не пригоден для написания текстов? В этом и вопрос - назревает задача создания довольно объемного документа в LaTeX, и я возвращаюсь к извечной проблеме: а как его, собственно, писать? Какие есть приложения.

Требования:

1. Проверка орфографии и желательно пунктуации, на уровне не хуже hunspell + LO Writer. Желательно лучше.

2. Возможность произвольного выделения кусков текста цветами, шрифтами В ИСХОДНИКЕ документа. Еще раз, внимание - в исходнике, а не в итоговом документе! В итоговом, конечно же LaTeX позволяет оформить как угодно. Надо в исходнике, чтобы я это видел в процессе набора, и чтобы это не было связано с LaTeX разметкой, ибо выделять будет надо намного больше и намного разнообразнее, чем предполагается в сверстанном документе!

3. Подцветка макросов LaTeX в исходнике.

4. Возможность корректного открытия файлов с расширением .tex, и чтобы при этом независимо от файла сохранялось форматирование исходника по пункту 2. Я понимаю, что на 146% такого нет нигде и это невозможно. Но а вдруг.

5. Компромиссный вариант предыдущего - сохранение в rich text формат, с возможностью экспорта в plain text перед сборкой LaTeX.

6. Весь текст исходника должен вводиться в хотя бы 3 синхронизированных параллельных колонки. Зачем. В первой колонке - номер фрагмента текста. Во второй - набираемый текст, который станет потом входным для LaTeX. В третьей - опорный текст, который выдернут откуда-то, и на основе которого я пишу свой текст. Перед сборкой LaTeX, экспортируется содержимое второй колонки как plain text.

Вопрос - какие, хотя бы общие подходы можно применить для организации такого Workflow?

мне кажется, ты хочешь странного, хотя и интересного (я вот тоже хочу нечто подобного, только в виде какой-то IDE для грамотного программирования в WEB).

в чистом виде всех 6 требований – по моему, нигде нет. но можно изобразить нечто подобное.

в целом, иногда мне кажется что было бы неплохо реализовать например, WEB+TeX на каком-то Oberon: например, виндо-офисно-одинэсно-подобном BlackBox Component Pascal – в смысле, на его BCF *.odc с вьюшками и персистентными объектами, или даже на A2/AOS Active Oberon – в смысле, на его активных объектах + что-то типа того же BCF *.odc из BBCP виндоподобного или даже классического Project Oberon досо-подобного *.Text формата (примерно, как ранний BCF = виджеты и гаджеты на самом обероне в бинарных rich text файлах).

ещё, внезапно: Temple OS и его формат гипертекстовых документов юпитеро-ноутбукоподобный тут тоже в тему, похож на эти *.Text или *.odc (только там HolyC священной православной сишечки а не оберон)

по отдельности всё это есть как в каких-то IDE для TeX : LyX, TexStudio, TexWord, Texmacs, виндовый Bakoma TeX, ну и тот же Emacs org-mode + auctex.

в виде отдельных элементов. самый визивигоподбный, тут наверное : Bakoma TeX ==> TexWord, TexStudio, TeXmacs.

Texmacs = guile scheme + визивиг + IDE для TeX + свой основанный на scheme формат rich text документов, программируемый на своём API (есть что-то типо лиспового repl + орг-модоподобное, например, для guile и axiom; и что-то с поддержкой грамотного литературного программирования; в целом, там есть программируемый API где на guile можно изобразить что угодно, но нужно вникать в его DOM Blackbox Component Framework BCF гаджеты и виджеты и вьюшки с персистентными объектами API доступный из guile)

в целом: ничего готового в полном виде нет, но нечто из отдельных требований можно изобразить в разных IDE по отдельности (c) можноЗделать (tm)

например:

1. вкладки для структурного программирования, структурного объяснения, параллельных текстов.

взять какой-то редактор с Folding, складками в духе Occam IDE, Origami

(или: moria.de .. => fe , e?FTE, vim zf, emacs ???, Scintilla ???, THE/XEDIT/KEDIT команды в левом столбце с номерами строк s/x и т.п. настраиваемый фолдинг через all/set display и т.п. вплоть до скриптов на REXX , которые учитывают назные скобки начала/конца региона,

ну или делать в универсальном виде – см. как в fe который с moria.de написаны маны на troff:

в комментариях разметка вида начало/конец региона, по которым срабатывает фолдинг.)

в смысле: открываем простыню на *.web или *.tex – например, классические tangle.web/weave.web/tex.web.

здесь мы видим:

1. неинтересный код в виде %%%%комментариев

2. подключаемые стили, преамбулы, макросы и т.п. конфиги

3. @пробел или @* начало грамотной документации, очередной главы

4. @<название нового модуля блока кода@> = или += 4.1 = – устанавливающее определение 4.2 + – дополняющее определение

5. @p пошёл блок кода на паскале или ещё каком ЯП 5.1 @<цитата включаемого старого модуля блока кода@> внутри @p блока кода подставляет целиком

6. @пробел или @* – начало нового блока документации заканчивает старый блок кода

Здесь в принципе удобны складки/вкладки – короче, folding text чтобы свернуть например, сначала все вообще ненужные, потом раскрыть только нужные блок документации и/или блок кода.

и его тоже, сворачивать по областям вложенности, например начало-конец if/then/else, циклов и прочих begin/end (с метками по регионам, или, в идеале, полностью автоматически без всяких меток в комментариях)

вручную это и так делать можно, но самое удобное, тут на мой взгляд – реализовано как в KEDIT/THE/XEDIT, через s/x префиксные команды.

в целом, фолдинг удобен наиболее когда делать два параллельных текста чтобы на их основе сделать третий.

например: классические tangle.web/weave.web и сам tex.web – это программы на паскале.

а могли бы быть и на чём-то более разумном: например, алголе-68, модуле-2, Ada (есть в gcc 16 в gcc-snapshot в Debian Trixie testing, Sid) или например, том же обероне пассивном как в BBCP и BCF *.odc или активном, как в A2/AOS.

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

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

например, %%%закомментировав – теховскими или WEB комментариями.

по идее, нужно придумать нечто вроде сборки вариантами – типа сишного препроцессора #ifdef..#ifndef…#else…#endif.

в голом виде в WEB @d = #define, но #ifdef/#endif/#include нет (но есть в plain TeX).

есть ещё такое: gpp - universal preprocessor : GPP (logological.org): logological/gpp man.gpp(1) man.gpp.2 pdf (arxiv.org) где как раз есть такие макросы – с синтаксисами сишки, теха или xml.

можно им сообразить или даже какими-то awk или sed-ом (см. например, тетрис или сокобана или пятнашек на sed).

то есть: в духе gcc -E > file.i => первоначальный *.web исходник копируем в другой, который и обрабатываем препроцессором, потом напускаем на него tangle/compileObj/buildEXE/runEXE/testEXE или weave/compilePDF/viewPDF

ещё, вот например сам tex.web => weave: tex.tex -> texbook.pdf , tangle: tex.p -> tex.exe.

вот тут например texbook.pdf в формате гранок draft с пометками и комментариями.

это наиболее близко к твоему требованию №6.

ещё к требованию №6 – посмотри пример из SILE: Simon’s Text processor (на C Rust + Lua) – пример про библию и параллельные тексты в виде переводов.

вот что-то подобное и хотелось бы изобразить только для TeX-а или вообще для WEB изначального, где в блоках кода @p со старым вариантом – на паскакале, новый – например, на Аде.

то есть, SILE и пример с библией и параллельными текстами – показывает как относительно просто сделать такую вёрстку колонками, где слева оригинал, справа – перевод. правда, как это сделать на техе, а не на силе – тут хз, там кажется доработали текстовые фреймы в SILE в духе тех же фреймов в BCF *.odc или пижамкере с вентурами индезигновыми, то есть: как обычный текстовый фрейм в ворде, например. в техе, емнип с этим – вечные проблемы, в ConTex и LuaTeX – кажется, можно изобразить нечто подобное.

вот почему хочется какой-то «литературно-грамотный IDE» для всего этого, для параллельных текстов переводов блоков кода. вот например в том же A2 есть на активном обероне PET текстовый редактор, где одной кнопкой можно сделать compile, а слева видны регионы и теги и области вложенности.

а хотелось бы – слева складки и их определения и применения, по всем блокам кода + вариантам с #ifdef

а кнопками вот это самое LitProg IDE workflow: edit/save/compile/run/test напускаем на него tangle/compileObj/buildEXE/runEXE/testEXE или weave/compilePDF/viewPDF

– одной кнопкой, как выше compile/Run.

6. Весь текст исходника должен вводиться в хотя бы 3 синхронизированных параллельных колонки. Зачем. В первой колонке - номер фрагмента текста. Во второй - набираемый текст, который станет потом входным для LaTeX. В третьей - опорный текст, который выдернут откуда-то, и на основе которого я пишу свой текст. Перед сборкой LaTeX, экспортируется содержимое второй колонки как plain text.

копипасть три раза подряд, сворачивая в складки. отключай ненужное комментариями теховскими % или WEB-овскими.

а ещё лучше – через #if 0 … #else…#endif и каким-то отдельным препроцессором типа gpp.

PS. Верните тёмную тему для анонимусов, изверги. неудобно же стало, синеневеньким да по серому, глаза сломать можно. ещё и при постинге при предпросмотре выскакивает какое-то сообщение что закрыть окно просит, хотя предпросмотр работает, и постинг вроде бы тоже.

опять вёрстку сломали, изверги. верните как было.

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

Альтернатива-то какая? Если есть автоматизация для редкого действия, то тут или помнить, или записать в документации. Других вариантов не просматривается. Разве вручную всё сделать, но вам emacs в режиме блокнота точно так же никто не запрещает использовать.

в смысле, вот реальной альтернативой для твоих хотелок является что-то орг-модо-подобное, только допустим, на Texmacs + guile а не на чистом елисповом жму/емаксе.

или вообще, нечто в духе BBCP BCF *.odc «вьюшек с персистентными объектами на компонентном паскале» – тут тебе и отдельные фреймы для блоков кода, и иконки коммандерами для интерактивной запускалки, и прочие гаджеты и виджеты контролы вьюшками – и всё в rich text формате, с цветами и картинками, всё как ты любишь.

или нечто в том же духе или вообще Project Oberon изначального *.Text гаджетов и виджетов духе,

только в новой среде – той же A2/AOS/BlueBottle на обероне активном и акторном а не пассивном и компонентном.

для опять же, подобной оргмоду юпитеро-ноутбуко-блекбокс-обероновой компонентной модульной rich text среды со складками, фреймами, параллельными текстами и гиперссылками, для всего вот этого

– слоёв и аспектов в какой-то многослойной аспектно-расширяемой литературно-грамотной IDE.

для параллельных текстов закомментированных или #ifdef-ом отключенных два варианта которые сливаем в третий с интегрированными изменениями.

как параллельные тексты и перевод из первого на второй в третье.

собственно, у меня есть теория на этот счёт. что грамотное программирование – это как «память переводов» только не для структурного объяснения блоков документации – а для структурного программирования блоков кода.

то есть: имея один перевод, одну реализацию – можно невозбранно достигнуть желаемого, сделав себе сборку вариантами перевода блока кода на другую реализацию ровно того же алгоритма.

а изобразив сборку вариантами – сделать себе литературно-грамотный девОпсинг, сразу через define- прокидываемые из mk-файла в weave/tangle и далее в конкретный выходной конфиг дерева конфигурации где варианты исполнения которые собираются в какой-то вариант релиза.

чтобы потом например, weave по литературно-грамотному девопсингу сделал табличку по всем вариантам и их профайлингу – например, переписать tex.web с паскаля на Rust: уже есть tectonic аду, алгол-68 или ещё какой оберон, и показать сравнительно затраты за время запуска, размер бинарника и прочий тулинг без особого костылинга.

а вообще-то, с точки зрения теории и философии векторного и гипертекстового метапрога и его метапроганья, с конпелируемыми подфункциями.

вот WEB Дональда Кнута – это правильный, конпелируемый гипертекст. который в отличие от неправильного WWW Тима Бернерса-Ли становится более компактным и структурно-осмысленным. например, тот же PDF формат – это готовая ООСУБД БД, с объектами и их метаданными.

в этом смысле, теория и философия правильного гипертекста – векторного и конпелируемого: примерно такова.

WEB грамотного литературного метапрограммирования – это метасистемный переход от простого одномерного линейного потока текста в многомерный – метатекст: гипертекст, кибертекст, паратекст

• метатекст – это «текст о тексте» в каком-то смысле уточняемого контекста этого самого мета

• гипертекст – это буквально «текст высшего порядка», hyper – для текстов многомерных гиперобъектов в смысле first class objects, firsrt class environments, first class binding (lexical and dymanical, relations, links: hyperlinks).

• кибертекст – это программный текст, генерируемый алгоритмом: зорком информовым на ZIL, ллм-кою или например: метапрогом, обходящим гиперссылки; или метаконпелятором метапрепроцессора текста высшего порядка, например для WEB это weave или tangle в текст одномерный, например, *.tex или *.pas. тут например: *.pas из блоков кода это откровенный и неприкрытый, голый исполняемый кибертекст. а *.tex тьюринг полный, так что тоже зачот.

• паратекст – это набор пар в параллельном тексте, оригинал и перевод; или «структурное объяснение» на языке документирования и «структурное программирование» на языке блоков кода.

в этом смысле, WEB – это все четыре эти свойства: и метатекст как текст о тексте; и обзираемый гипертекст со ссылками и индексе; и кибертекст как исполняемый код который запустить и пощупать можно; и паратекст на человекопонятном псевдокоде естественного языка, и на языке кодирования, понятном контуперу.

частично упорядоченные по отношению частичного порядка топологической сортировки, частичные решётки включённые блоки документации и блоки кода представляют собой монаду – моноид моноидов в пространстве эндофункторов: одновременно и метатекст, и гипертекст, и паратекст, и кибертекст.

здесь нас интересует объяснительная способность метатекста, ссылочная гипертекста, и наглядно-показательная на примерах пар – паратекста, и исполнительная — кибертекста.

этот метатекст – конпелируемый, и вот почему.

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

first class object, first class type, first class environment блоков кода как объектов/метаобъектов/с метаинформацией и рефлексией, наследованием и т.п. – является исходным материалом для конпелирования.

из которых ссылки трансклюзии, или ссылки цитирования (@<included@> внутри @p блоков) – задают join , а что-то ещё – и meet операции для частичных решёток топологической сортировки. TOP задаёт выходной файл точки сборки корневого блока кода, по всем таким головам – лес а не дерево если много выходных файлов а не один как в классическом tangle/weave.

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

можно сказать так: поскольку Дональд Кнут писал на паскакале стандартном исо, у которого даже модулей не было – он изобразил себе свой include с блекждеком и преферансистками – по имени блока кода, возможно сокращ... – а не по имени файла , как инклуды в сишечке.

при этом специяльно запрещены макросы, переписываюшие макросы – то есть, @d внутри @p блоков – чтобы избежать зацикливания и тьюринг-полноты (полагаю, что и #ifdef не реализован по той же самой причине).

всё это позволяет сделать истинный гипертекст — конпелируемым, а не интерпретируемым.

конпеляцию и сборку из метатекста *.WEB в кибертекст *.pas и гипертекст *.tex выполняют отдельные утилиты мета-макропроцессора.

которые и реализуют метасистемный переход – из линейного текста кода в многомерный, гиперссылочный, многоуровневый и нейрообразный –

метатекст: гипертекст, паратекст, кибертекст

vscode единственная альтернатива kate как альтернатива емаксу просто смешно

при этом ещё во времена Дональда Кнута и TeX изначального – на прототипе алголе SLAC в середине 1970х годов по сути было всё равно на каком языке писать эти «алгоритмы компьютерной типографии», лишь бы алгоритмы были верные, и верстали красиво.

Кнут, можно сказать, сознательно пошёл по пути упрощения тьюринг-полноты, императивности, а не декларативности вот всей той plain tex макросни, которая к моментам LaTeX и ConTeX стала довольно опять-таки декларативной, а в LuaTeX – императивною.

Что ещё было из текстовых процессоров примерно в то же время?

• troff изначальный, тоже тьюринг полный и с немного менее красивыми алгоритмами. как compiler pipeline наподобие gcc driver: neatroff file.ms|eql|tbl|grap | tee file.pdf | page,mupdf -

здесь мы имеем навороченный эмулятор терминала вместо nroff который на выходе делает в devutf из которого потом и распечатывается *.ps и далее *.pdf.

но в целом, troff это тоже императивный текстовый метаязык. где переменные это строки или числовые регистры, счетчики. а циклы и ветвления – заданы явно. в итоге стили становятся недостаточно декларативными, вся эта макросня на troff-е типа *.ms, *.mm, *.mom каким-то образом должна научиться рассчитывать всё это исходя из каких-то ограничей описываемой display model страницы.

• SCRIBE на лиспе

• GML, SGML, и т.п. WGML у IBM и Watcom (примеры в open watcom man, books, help; или в INF OS/2 help).

SCRIBE синтаксически выглядел как texinfo но был зело проприетарным.

но в целом, кажется сейчас что эту линейку и надо было развивать в сторону повышения декларативности и конфигурябельности: Scribe, SCRIBE, skribillo, exscribe на схеме, cl, зеталиспе и всём прочем таким нейрообразным.

в этом смысле, то что есть сейчас в Emacs org-mode на Elisp и частично в Texmacs на guile scheme – это лишь зайчатки истинного метапрога: декларативного, компилятивного, генеративно смысло-тексто порождающего, да ещё и – с конпелируемыми подфункциями : как по реализации, так и по порождаемому rich text бинарному артефакту многомерного _векторного и гипертекстового _ документа, а не его одномерному линейно-текстовому обобщённому single source WEB-исподнику.

а вот уже юпитеро-ноутбуко-подобное или Curl: the unified language for the WEB – с тыкалкою в коммандеры и вьюшки блекбоксовые, с ихнею интерактивною запускалкою, написанною на самом себе — уже гораздо ближе к теме.

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

с конпелируемыми подфункциями на самом себе, словно Object Talk какой-нибудь: только не JavaScript, а нормальный лисп или Curl. или схема или дилан или коммон лисп вообще какой-нибудь.

Альтернатива-то какая? Если есть автоматизация для редкого действия, то тут или помнить, или записать в документации.

Нет, посмотри тот же DOS-овый Multiedit, да и любой другой Text-mode редактор с адекватным меню. На помнишь комбинаций - делаешь через меню. В меню еще и все комбинации возле каждого пункта написаны. Будет действие постоянным - выучишь комбинации естественным образом. И не надо лезть в настройки, вычитывать закопанные сведения в документации и ковырять скрипты автоматизации. Решение уже давно было сделано бородатыми старцами, и эти старички оказались более прогрессивными чем линуховые нетакусики с ихним убогим emacs-ом и vim-ом, которые только пищат и портят текст :)

линуховые нетакусики с ихним убогим emacs

emacs и под windows есть. для вендовых нетакусиков

На помнишь комбинаций - делаешь через меню

Здравствуйте.

Здравствуйте.

Здрафствуте. Так какую кнопку нажать, чтобы это меню увидеть? Давайте начнем с этого. Как об этом должен узнать пользователь? Неужели на всем экране в строке статуса не нашлось местечка для того чтобы неопытному пользователю написать этот шорткат? Ай-яй-яй, как неудобно получилось, юзерфрендли интерфейс сломался даже не начав работать.

На помнишь комбинаций - делаешь через меню.

Зачем?

Во-первых, лучше использовать консольный вариант.

Во-вторых, есть же M-x и автодополнение по TAB, даже если ввел буквы из середины команды.

есть же M-x и автодополнение по TAB, даже если ввел буквы из середины команды.

А что такое M-x? А как запомнить команды? КОМАНДЫ. Какой ужосо.

Продолжаем разговор. Вот так выглядит emacs по умолчанию. Надеюсь, я ответил на ваше недоумение. Отдельно отмечу:

Неужели на всем экране в строке статуса не нашлось местечка

Да, блин. Не нашлось. В современных интерфейсах раздражает необычайно, что пространство экрана занято чёрти чем и на сравнительно большом мониторе с диагональю в 24 дюйма рабочая область — как пачка сигарет. Поэтому у себя в emacs’е я убираю все менюшки, панельки, боковые полосы прокрутки и т.д. Так удобнее.

А что такое M-x?

ALT-x, а потом вводишь команду, как в shell только автодополнение работает не только для конца команды, а для букв из середины тоже.

А как запомнить команды? КОМАНДЫ. Какой ужосо.

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

из консоли работай: emacs -nw

xemacs это emacs для свистелок и перделок, чтобы в латехе формулы сразу как формулы отображались, чтобы картинки зразу вставлялись и пр. Оно не нужно, имхо.

Работать из консоли в emacs’е неправильно. Правильно работать в консоли из emacs’а.

Одно другому не мешает.

PS: и еще советую использовать emacs-daemon, или как он там в твоем дистрибутиве называется.

Высокий порог входа не делает его хорошим решением.

Чем сложней инструмент, тем больше усилий нужно для его освоения.

Сравнивать Emacs с Kate это всё равно, что сравнивать мультитул лезерман с отверткой.

Да блина, у вас спеллчекер не чекает, а вы философствуете как правильно. А хоткеи чтобы при не-английской раскладке ломались и это надо было героически преодолевать, это очень правильно?

Where will we be ten years from now? CRT’s will be a thing of the past, multimedia will no longer be a buzzword, pen-based and voice input will be everywhere, and university students will still be editing with emacs.

≈1991

Общее решение не может быть эффективнее частного узко заточенного, такова философия.

«Универсальность — не обязательно неудобство. Отвёртки с насадками и ножи шеф-повара достаточно удобны даже для профессионалов.»

Короче, не слушай всех этих мышковозов. Читай руководство. Не старайся всё запомнить сразу, оно само придет, со временем. Просто ознакомься с тем, что доступно в редакторе и потом возвращайся в нужные разделы.

Главное, что пользователи блокнотоподобных редакторов не понимают об Имакс, это то, что всякие elisp, почта и телеграм в Имакс далеко не главное. Главное в нем это базовые возможности навигации по тексту и базовые операции редактирования. В блокноте это все отсутствует — даже чтобы просто выделить предыдущие три слова нужно раскарячить руки так, чтобы умудриться нажать одновременно Ctrl+Shift+Left. А чтобы перейти к слову foo в предыдущей строке нужно судорожно тыкать стрелки, словно играя в Пакман.

Неужели на всем экране в строке статуса не нашлось местечка для того чтобы неопытному пользователю написать этот шорткат?

Не отрицаю пользу этого взгляда, но замечу, но так сделано во многих программах. File -> Save — это современная идиома.

vscode единственная альтернатива kate как альтернатива емаксу просто смешно

В этом и дело. Хороших редакторов текста много. В том числе и лучше, чем Emacs, хотя тут расширяемость последнего всё ещё вне конкуренции. А вот альтернативы среде нет и не предвидится.

Да блина, у вас спеллчекер не чекает, а вы философствуете как правильно. А хоткеи чтобы при не-английской раскладке ломались и это надо было героически преодолевать, это очень правильно?

Проверка орфографии есть, но в браузере я ее часто игнорирую. Горячие клавиши при переключении раскладки не ломаются (специально не настраивал).

у вас спеллчекер не чекает,

Не у нас, а у вас. Я не знаю в чём дело, должно быть карма.

А хоткеи чтобы при не-английской раскладке ломались

надо переключать раскладку встроенной emacs’овой переключалкой. Я, кстати, согласен, что это недостаток.

Сложно конечно как-то с выбором редактора ты, с этим я не согласен.

Но посыл в целом правильный. Нет смысла пытаться изучать технологии древних, и относится это и к Vim, и к Emacs и наверное даже к Ed. :D

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

Я не знаю в чём дело, должно быть карма.

Это называется иначе - избирательное зрение. Как некоторые, тиринг не видят например.

надо переключать раскладку встроенной emacs’овой переключалкой

Не удобно, я всегда обходил это костылями, но сейчас, в нынешний «наскок на Emacs», наверное попробую переключать встроенной. Еще кстати неудобно, что некоторые хоткеи пересекаются с системной переключалкой языка, и передают привет.