>как по мне nvi-1.79 всё же лучше будет ;)

я тоже юзал (на фре) долгое время, а потом забил и поставил вим, ибо у нви нету подсветки синтаксиса=(

> Я не передергиваю -- я интересуюсь, появился ли в emacs OS _нормальный_ текстовый редактор.

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

>Я не передергиваю -- я интересуюсь, появился ли в emacs OS _нормальный_ текстовый редактор.

Именно передергиваете. И просто завидуете, что там где для "emacs OS" достаточно написать несколько строк, вам приходится ждать vim 2.0 :-))

>Не о том шла речь.

Как раз так об этом.

> > Вас прет от C-xC-aC-n и прочей эквилибристики? Вы мазохист?
            
> Удобней чем 25 режимов.

Да, конечно, надо только педальки для Control и Shift прикрутить. :)

Субъективно. Мне удобнее одиночными (bindings из 1 -- 2 клавиш + режимы),
Вам -- очередями.

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

Даже такой маразм, как modeless editing, тоже можно сделать.

> > Во-вторых, уже написали.

> Где?

google:vimacs, google:vim cream


> Долго. Долго читать,

Не дольше, чем elisp manual. Тем более, что все равно потом
придется RTFS...

> долго разбираться,

Это можно про любую софтину сказать, которую в первый раз видишь.

> долго компилировать.

Чушь. За 5 минут весь собирается.

> Скучно и непрактично.

Это филология уже пошла.

> > Я не передергиваю -- я интересуюсь, появился ли в emacs OS
> > _нормальный_ текстовый редактор.
            
> Он там был всегда.

Не было его там никогда. И сейчас нет. И не будет никогда, скорее всего.
Зато хлама всякого -- хоть ж@#ой жуй...

> Самый удобный, 

Еще раз: удобство -- вещь субъективная. Modeless editing, например,
далеко не всем нравится. Elisp, как _единственный_ язык расширения --
тоже.

> самый гибкий,

Даже слишком.

> самый интересный (за копанием во внутренностях можно спокойно
> ночь просидеть и не заметить).

Меня его внутренности не интересуют. Редактор -- это просто инструмент.

А всяких интересных штук, в которых можно копаться, и не то что всю
ночь -- всю жизнь, хватает и без emacs'a.

> Субъективно. Мне удобнее одиночными (bindings из 1 -- 2 клавиш + режимы), Вам -- очередями.

Просто постоянно приходится держать в голове помимо всего прочего, в каком режиме сейчас находишься. Сколько ни пытался совладать с вимом -- постоянно оказывался в ситуации, когда думаешь, что находишься в одном режиме, а на самом деле это не так. У меня есть что в голове держать, когда я тексты редактирую. Если тебе нечего, то нафига тогда вообще нужен текстовый редактор?

> Не дольше, чем elisp manual. Тем более, что все равно потом придется RTFS...

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

> Это можно про любую софтину сказать, которую в первый раз видишь.

Можно разобраться практически в любом елисповском коде достаточно быстро (если не особенно вникать в подробности). Ты тоже можешь сразу сказать, зачем предназначен тот или иной патч для сорцов вима? Сходу, даже без экспериментов?

> Чушь. За 5 минут весь собирается.

eval-defun занимает меньше секунды. Разницу в 300 раз ощущаешь? И ты хочешь сказать, что всегда сходу пишешь безбажный код, и компилируешь все один раз и навсегда?

> Именно передергиваете. И просто завидуете, что там где для "emacs OS"
> достаточно написать несколько строк,

Про modeless editing я уж и говорить не буду -- уже надоело.

Но вот сколько г@%^на надо перелопатить, чтоб просто написать подсветку
синтаксиса для языка...  Это охренеть можно...

> Не было его там никогда. И сейчас нет. И не будет никогда, скорее всего.

Хорошо, что тебе конкретно не нравится?

> Зато хлама всякого -- хоть ж@#ой жуй...

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

> Modeless editing, например, далеко не всем нравится.

Хм, есть viper :))

> _единственный_ язык расширения -- тоже.

Важно не количество, а качество. Если честно, у меня елисп после CL'а, вообще чуть ли не отвращение вызывет. Но все же, его мощности хватает на 10 вимов.

> Даже слишком.

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

> Меня его внутренности не интересуют. Редактор -- это просто инструмент.

А инструментом нужно владеть, для того, чтоб работа была эффективной.

> Но вот сколько г@%^на надо перелопатить, чтоб просто написать подсветку синтаксиса для языка... Это охренеть можно...

Ага, прочитать в manual'е про font-lock. Охренеть конечно можно, но совсем не обязательно это делать. :)

Зато, для того, чтоб написать _нормальную_ поддержку нового ЯП для вима уж точно можно охренеть. :)

> Просто постоянно приходится держать в голове помимо всего прочего,
> в каком режиме сейчас находишься.

Не нужно. Достаточно на нижнюю строчечку глянуть. 

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

Дык все равно куча недокуметированных вещей, что там, что там придется
RTFS.

> Можно разобраться практически в любом елисповском коде достаточно
> быстро (если не особенно вникать в подробности)

А кто мешает столь же быстро разобраться в <подставить нужное>?

> Ты тоже можешь сразу сказать, зачем предназначен тот или иной патч
> для сорцов вима?

Нет.

> eval-defun занимает меньше секунды.

Речь шла о компиляции _с нуля_, всего vim'а, а это совсем другая вещь.

> И ты хочешь сказать, что всегда сходу пишешь безбажный код,

Нет.

> и компилируешь все один раз и навсегда?

Нет. Но ccache и distcc весьма помогают.

> Ага, прочитать в manual'е про font-lock.

За это время можно не то что охренеть, а напиться и  протрезветь...

> Зато, для того, чтоб написать _нормальную_ поддержку нового ЯП для
> вима уж точно можно охренеть. 

А в &runtimepath . "/syntax" не пробовали заглянуть? 

> А кто мешает столь же быстро разобраться в <подставить нужное>?

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

> Речь шла о компиляции _с нуля_, всего vim'а, а это совсем другая вещь.

Хорошо, сколько займет перекомпиляция, перелинковка и переустановка вима в таком случае?

>> И ты хочешь сказать, что всегда сходу пишешь безбажный код,

> Нет.

Поэтому, написание расширение под емакс занимает гораздо меньше времени, чем написание аналогичного патча для сорцов вима.

> Нет. Но ccache и distcc весьма помогают.

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

> А в &runtimepath . "/syntax" не пробовали заглянуть?

Подсветка -- это 5% поддержки ЯП в текстовом редакторе. Куда важней выравнивание, взаимодействие с внешними процессами и т. д. Взгляни на feature-list slime'а, например.

http://common-lisp.net/project/slime/

http://www.cliki.net/SLIME%20Features

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

> Тебя его не то что использовать, даже на диске держать никто не заставляет.
> Или ты комманду rm еще не освоил?


find /usr -type f -name '*.el*' | xargs rm -f

> > _единственный_ язык расширения -- тоже.

> Важно не количество, а качество. 

Про качество даже не говорю -- глядеть на него тошно... Ну почему
не scheme, в конце концов?

> Я уверен, что ты используешь далеко не все возможности своей ОСи,
> чего ж ты не ропчешь, что ОС слишком гибкая? 

Потому, что ее гибкость не идет в ущерб простоте и производительности.

Остапа понесло...

> Большая часть емакса написана на елиспе, поэтому RTFS в случае с
> емаксом гораздо легче. 

Дальше от машины -- не значит ближе к человеку.

> Поэтому, написание расширение под емакс занимает гораздо меньше
> времени, чем написание аналогичного патча для сорцов вима.

И чего, elisp -- это такой могучий язык, в котором любая синтаксически
допустимая программа семантически верна?

> А еще говоришь, что текстовый редактор -- всего лишь инструмент.

А тогда нечего его хакать, работать надо :)

> Куда важней выравнивание,

Глядеть в &runtimepath . "/indent"

> взаимодействие с внешними процессами 

Оно вообще на# не нужно, ибо нефиг по pipe'ам навоз качать.
Bindings к скриптовому языку для редактора _и_ софтины-которой-нужно-рулить. 


P.S.

Все, хватит flame разводить.

Сколько раз нужно обсудить вопрос "что лучше -- vim или emacs?", чтоб
это _всем_ надоело?

> Потому, что ее гибкость не идет в ущерб простоте и производительности.

Каким же образом гибкость емакса идет в ущерб его простоте и производительности?

> Про качество даже не говорю -- глядеть на него тошно... Ну почему не scheme, в конце концов?

Если был бы scheme, я б еще 10 раз бы подумал, стоит ли использовать емакс. Это самый отстойный из нынешних диалектов лисп, так как в нем нет макросов. Коненчо, продолжения рулят, но использовать их для конфигурации приходилось бы редко.

То что elisp отстой, я согласен. Но все же это лучший _реализованный_ язык расширения редакторов, поэтому приходится использовать его. Учитывая то количество кода, который уже написан, этот период продлится еще очень долго, если, конечно, кто-то не напишет compatibility layer между CL и elisp'ом :)

> И чего, elisp -- это такой могучий язык, в котором любая синтаксически допустимая программа семантически верна?

Нет, просто цикл Write->Compile->Eval при использовании елиспа занимает гораздо меньше времени, ты это фактически признал.

> Дальше от машины -- не значит ближе к человеку.

Согласен, но в нашем случае это именно так. Ну и не забываем, что макры рулят ;)

> А тогда нечего его хакать, работать надо :)

Это тонкий философский вопрос. ;) Анекдот про дровосека и тупую пилу напомнить? :)

> Оно вообще на# не нужно, ибо нефиг по pipe'ам навоз качать.

А для чего они, по-твоему, предназначены :)

Не нравится пайп, юзай сокеты :) Вариантов много.

> Bindings к скриптовому языку для редактора

Ну почему тогда в таком отстойном редакторе, как емакс все работает на ура, а в виме только в теории все круто, а на практике как HURD?

http://www.io.com/~dierdorf/emacsvi.html

Ламерский вопрос: как поменять цвет в подсветке синтаксиса? Вим подсвечивает комментарии мерзким тёмно-синем цветом, которого, если запускать вим под иксами, нефига не видно! Я так понял цветовая гамма вима расчитана на белый фон, но белый фон - это 3.14здец глазам!

> Если был бы scheme, я б еще 10 раз бы подумал, стоит ли использовать емакс. Это самый отстойный из нынешних диалектов лисп, так как в нем нет макросов. Коненчо, продолжения рулят, но использовать их для конфигурации приходилось бы редко.

CL-овских макр нет в R5RS. И только. Там есть гигиенические макры. Ну а полноценные макры есть в mzscheme и ЕМНИП в guile (возможно и в других реализациях). Scheme гораздо более красивый язык, чем CL и тем более ELisp.

> То что elisp отстой, я согласен. Но все же это лучший _реализованный_ язык расширения редакторов

Распространенных редакторов (работоспособных)

> если, конечно, кто-то не напишет compatibility layer между CL и elisp'ом :)

Уж лучше guile scheme и elisp'ом

> Там есть гигиенические макры.

Это не макры, фтопку их. Дурацкая защита от дурака.

> Ну а полноценные макры есть в mzscheme и ЕМНИП в guile (возможно и в других реализациях).

В guile есть, лично проверял. В любом случае, стандарта нет, все implementation dependent, а реализации, в основном, хуже CL'овских.

Еще можно добавить отсутствие хорошей системы ввода/вывода и малое количество библиотечных функций.

Еще CLOS и Condition'ы. Вторая вещь рулит особенно.

> Scheme гораздо более красивый язык, чем CL и тем более ELisp.

Может быть, но практически CL более пригоден для использования. все же, программирование -- это инженерия прежде всего, и тут прагматизм отодвигает математическую романтику на второе место. Хотя, программы на CL красивы по-своему, ИМХО.

> Распространенных редакторов (работоспособных)

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

:set background=dark

Даже я знаю :) Хотя, мне положено знать лишь одну комманду: `:q!'

Зачем так извращаться есть есть давно JEdit а к консоли минимум Joe. Оказывается не вывелись еще мазохисты.

слушай, nsav-ng, забань себя сам, а? Ато "мене нервують люди, тi що думають мало" (с) Скрябин

Да - не вывелись. Ведь ты еще жив :-)

>Ламерский вопрос: как поменять цвет в подсветке синтаксиса? Вим
>подсвечивает комментарии мерзким тёмно-синем цветом, которого, если
>запускать вим под иксами, нефига не видно! Я так понял цветовая гамма
>вима расчитана на белый фон, но белый фон - это 3.14здец глазам!
Весьма приличные цветовые схемы идут по дефолту в комплекте:
:colorscheme darkblue

Если интересно почитать то можно:
:h colorscheme

Ну и на сладкое:
http://www.vim.org/scripts/script.php?script_id=625
140 цветовых схем в одном пакете!
Юзайте на здоровье.

>И скажи, почему такого рода расширений в виме нет. Не обязательно для >лиспа, их вообще нет. Что то не понятно - ну кастомизация для lisp на страничке той описана, и что там такого суперского? Я в лиспе не спец, поэтому интересуюсь - какого рода расширений нет в Vim'e? Выравнивание в Vimе есть для кучи языков. Взаимодействие с внешними процессами - есть. Мои скрипты на перле из Vim'а к сокетам спокойно обращаются и тянут нужную инфу.

>Важно не количество, а качество. Если честно, у меня елисп после CL'а, >вообще чуть ли не отвращение вызывет. Но все же, его мощности хватает
>на 10 вимов.
Граждане любители лиспа - все в дружно переходим на Vim.7.
Там таки появились возможности писать макросы на mzscheme.
Так что ваш любимый лисп уже таки есть в Vim'е.
Так что ждем-с...
:h mzscheme
:))

>Специально для тех кто не в курсе что к виму можнописать плагины только на одном языке: http://vimdoc.sourceforge.net/htmldoc/if_perl.html#:perl
Что значит "только"?
Не "только"!
К виму можно писать плагины ЕЩЕ на одном языке http://vimdoc.sourceforge.net/htmldoc/if_pyth.html
К виму можно писать плагины ЕЩЕ на одном языке
http://vimdoc.sourceforge.net/htmldoc/if_tcl.html
К виму можно писать плагины ЕЩЕ на одном языке
http://vimdoc.sourceforge.net/htmldoc/if_ruby.html

Да нам и в Emacs очень неплохо... Уж если буду переходить, то на Yi когда его доработают

--

Господа :)
Ну вы как дети малые ))
mcedit рулит форева, или ed
Нафиг монстров разводить :))

> Граждане любители лиспа - все в дружно переходим на Vim.7. Там таки появились возможности писать макросы на mzscheme. Так что ваш любимый лисп уже таки есть в Vim'е. Так что ждем-с...

Чукча писатель, чукча не читатель. Пройдись выше по треду и почитай, прежде чем умничать.

пока emacs загрузится со своими elispами, в vim уже успеешь все сделать;)
vim это идеальный баланс быстродействия, удобства, расширяемости и функциональности.
А emacs неповоротливый монстр, который, кстати и офтопик в данной ветке...

> пока emacs загрузится со своими elispами,

Аптайм емакса у нормальных пользователей достигает порой 2-х суток, так что скорость загрузки -- не недостаток. Раз в двое суток можно и потерпеть. :)

> > Оно вообще на# не нужно, ибо нефиг по pipe'ам навоз качать.
            
> А для чего они, по-твоему, предназначены :)

pipe'ы -- костыль. Нужный для убогого (как язык) shell'а и убогих
(если их рассматривать как функции этого языка) утилиток (которые принимают
в качестве аргумета строку и строки же выдают; пример -- ls возвращает
не список из dirent, а просто кучу текста).

> Ну почему тогда в таком отстойном редакторе, как емакс все работает
> на ура

Даже _элементарные_ вещи в emacs сделаны через задний проход.
Вместо простеньких

y}

или

C-vGwhdw[p

надо целую симфонию слабать (viper -- отстой, там и десятой части
нужных keybindings нет).

> а в виме только в теории все круто

Там и так все, что нужно для _редактора_,  работает. Работать  в
составе IDE vim умеет, а в том, что у софтины <blah> нет нормального
API для "remote" control, разработчики vim не виноваты, и кривых
work-around'ов a la GUD изобретать не будут, скорее всего.

В vim 6 есть команда :colorscheme плюс в поставке несколько готовых схем -- выбери себе по душе или подправь под себя наиболее подходящую.

На другой машине у меня vim 5.7, там этой команды нет, а проблема с темно-синими комментариями на черном фоне была та же, что и у тебя -- я просто добавил в .vimrc строчку

hi Comment ctermfg=cyan

Всего-то? У меня аптайм Emacs'а достигает 1,5 - 2 недель.

> pipe'ы -- костыль. Нужный для убогого (как язык) shell'а и убогих (если их рассматривать как функции этого языка) утилиток (которые принимают в качестве аргумета строку и строки же выдают; пример -- ls возвращает не список из dirent, а просто кучу текста).

Про unix-way ничего не слышал? По-твоему, его идиоты придумали?

> Даже _элементарные_ вещи в emacs сделаны через задний проход. Вместо простеньких

> y}

> или

> C-vGwhdw[p

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

> надо целую симфонию слабать

Просто надо настроить один раз в жизни кейбиндинги и не мучаться.

> Там и так все, что нужно для _редактора_, работает.

Может, у тебя просто требования примитивные? Не задумывался над этим? Уверяю, что если бы ты хоть 5% своего рабочего времени уделял бы изучению эффективности работы с редактором, то вима тебе уже бы не хватило.

> Работать в составе IDE vim умеет

Вижу, все же для тебя интеграция -- это никому не нужный, пустой звук.

> а в том, что у софтины <blah> нет нормального API для "remote" control, разработчики vim не виноваты, и кривых work-around'ов a la GUD изобретать не будут, скорее всего.

Угу, религия не позволяет. Даже если GUD и идеологически неправилен, он работает и отлично справляется со своими функциями. Не вижу причины его не использовать. Если виммеры такие уж фанатики, то что можно поделать? Я не психиатр, и лечением заниматься не буду.

> Про unix-way ничего не слышал?

1) Каждый инструмент делает только одно дело, и делает хорошо.
2) Каждый инструмент умеет работать в связке с другими.

Но как эта связка делается -- этого другой вопрос.  BTW, emacs
очевидным образом нарушает оба требования. :)

> По-твоему, его идиоты придумали?

Идиоты пытаются слепить из (недоделанного) "текстового редактора"
замену всему /usr.  Похоже, они искренне верят в то, что *NIX-way --
это всю жизнь гонять по pipe'ам помои и парсить, парсить их до
посинения...

Заставь дурака б-гу молиться...

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

Чья б мычала :) Еще раз, для тех, кто в танке: большинство keybindings
в vim'е состоит из одной-двух клавиш (потому как есть insert и command
mode, в отличие от ...), поэтому одна и та же последовательность команд
вводится быстрее.

> > надо целую симфонию слабать

> Просто надо настроить один раз в жизни кейбиндинги и не мучаться.

Просто взять нормальный редактор и забыть про emacs, как про 
кошмарный сон.

> > Работать в составе IDE vim умеет

> Вижу, все же для тебя интеграция -- это никому не нужный, пустой звук.

Таки умеет, :h workshop, например. С m$ VS (не к ночи вспомнить) тоже
работает.

FYC, господа gdb developers, писать костыли для вашей кривой поделки
никто не будет.

> Угу, религия не позволяет.

Да, нечего превращать редактор в навозную кучу a la emacs. Не будет
в vim'е ни mule'к, ни GUD'ов, ни прочего дерьма.

> 1) Каждый инструмент делает только одно дело, и делает хорошо.

Емакс -- это интерпретатор емакс-лиспа, поэтому он удовлетворяет этому требованию.

> 2) Каждый инструмент умеет работать в связке с другими.

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

> Но как эта связка делается -- этого другой вопрос.

Ты все же почитай, например в TAOUP, какие интерфейсы используются в юниксе. Почитай, и подумай.

> Чья б мычала :) Еще раз, для тех, кто в танке: большинство keybindings в vim'е состоит из одной-двух клавиш (потому как есть insert и command mode, в отличие от ...), поэтому одна и та же последовательность команд вводится быстрее.

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

> Просто взять нормальный редактор и забыть про emacs, как про кошмарный сон.

Если отбросить удобства (там скорее играет субъективный фактор, поэтому спорить довольно тяжело), то что такого есть в виме, чего нет в емаксе?

> FYC, господа gdb developers, писать костыли для вашей кривой поделки никто не будет.

И кому от этого хуже? :) Больше свободных дебаггеров в юниксе нет :)

> Да, нечего превращать редактор в навозную кучу a la emacs. Не будет в vim'е ни mule'к, ни GUD'ов, ни прочего дерьма.

Опять, кому от этого хуже?

> пока emacs загрузится со своими elispами

Не в тему. Пока vim загрузится со своими pluginами... все равно ждать
придется.

>  который, кстати и офтопик в данной ветке...

\begin{анекдот}
Встречаются в море два корабля, один из СССР в Израиль плывет,
другой -- из Израиля в СССР. Пассажиры сгрудились у бортов,
крутят у виска, пальцами кажут на другой корабль.
Капитан у боцмана спрашивает, что, дескать происходит-то?
-- Да, приветствие у них такое...
\end{анекдот}

Вот, когда встречаются юзвери vim'а и emacs'а, происходит нечто
подобное...

> Емакс -- это интерпретатор емакс-лиспа, поэтому он удовлетворяет
> этому требованию.

Да! Я так и знал, что текстового редактора там нет! :)

> Емакс прекрасно работает в связке с другими программами,

Наглая ложь. emacs -- вещь в себе. "Работает в связке" и "есть костыль
для кривого поделия blah-blah" -- разные вещи.

> Если учесть время, которое тратится на определение, в каком ты режиме,

ноль

> и переходы из одного режима в другой,

Во время _ввода команд_ не нужно переключаться.

> К клавише ESC очень далеко тянутся, в отличии от контрола, альта и шифта.

Ага, хоть на педали выноси эти control, alt и shift! BTW, за Meta в
keybindings надо яйца отрывать, чтоб не размножались хотя бы...

> Если отбросить удобства (там скорее играет субъективный фактор, 
> поэтому спорить довольно тяжело), то что такого есть в виме,
> чего нет в емаксе?

Именно эти удобства (плюс development policy) и есть решающий фактор. 

> > FYC, господа gdb developers, писать костыли для вашей кривой
> > поделки никто не будет.

> И кому от этого хуже? :)

А за это по голове бить надо, ногами. C#ки, монополисты похлеще m$,
пишут кривую по@$отину, пользуясь тем, что деваться юзверю некуда. 

> Больше свободных дебаггеров в юниксе нет :)

Монополистов -- вешать на столбах!

> > Не будет в vim'е ни mule'к, ни GUD'ов, ни прочего дерьма.

> Опять, кому от этого хуже?

Никому. Все, что есть, работает _нормально_, а не на соплях.
Локализация, в частности, нормальная, а не шизофрения в стиле
emacs'а.

> Наглая ложь. emacs -- вещь в себе. "Работает в связке" и "есть костыль для кривого поделия blah-blah" -- разные вещи.

В юникса программы работать в связке могут лишь обмениваясь через пайпы текстовыми потоками. Это Unix way by design. Не вижу в этом ничего предосудительного.

> Во время _ввода команд_ не нужно переключаться.

А ты только лишь комманды вводишь, а для набивания текста дома секретутку держишь?

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

> Ага, хоть на педали выноси эти control, alt и shift!

control я нажимаю ладонью, альт большим пальцем, шифт -- мизинцем. Удобно. До ескейпа тянутся тежело, да и попадаешь не всегда.

> BTW, за Meta в keybindings надо яйца отрывать, чтоб не размножались хотя бы...

не понял?

> А за это по голове бить надо, ногами. C#ки, монополисты похлеще m$, пишут кривую по@$отину, пользуясь тем, что деваться юзверю некуда.

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

А вообще, обмен текстовыми потоками через пайпы и сокеты гораздо удобней и гибче, чем писать биндинги на каждый чих. Если ты этого не понимаешь, то пиши свой дебаггер, биндинги и т. д. Вперед. От этого ты никому кроме себя хуже не сделаешь.

> Никому. Все, что есть, работает _нормально_, а не на соплях.

То есть, вообще не работать, это значит работать нормально. Жжошь!

> Локализация, в частности, нормальная, а не шизофрения в стиле emacs'а.

input method'ы в виме так и не удосужились сделать...

> В юникса программы работать в связке могут лишь обмениваясь
> через пайпы текстовыми потоками.

Ложь.

> Это Unix way by design.

К счастью, *NIX way не имеет ничего общего с этим идиотизмом.

> Не вижу в этом ничего предосудительного.

Я не окулист, вылечить от красноглазости не могу, но тем не менее...
Текст -- это далеко не оптимальное представление данных _для программы_.
Поэтому, если интерфейс предназначен _исключительно_ для программы,
на кой черт нужно перекидываться текстом? 

> А ты только лишь комманды вводишь, а для набивания текста дома
> секретутку держишь?

Не держу, ни секретуток, которые могут по 108 emacs'овых keybinding'ов
в минуту выбивать. Текст набиваю сам, поэтому пользуюсь текстовым
редактором, а не интерпретатором elisp'а.

> > BTW, за Meta в keybindings надо яйца отрывать, чтоб не
> > размножались хотя бы...

> не понял?

Чего тут не ясно? 

emacs -nw

И либо у emacs'а не работает Meta-S, либо не вводятся 8-битные символы.

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

Знакомая песня. Место таким поделиям -- на помойке, а их авторам -- в
биореакторе (или на бирже труда, в крайнем случае).

> А вообще, обмен текстовыми потоками через пайпы и сокеты гораздо
> удобней и гибче, чем писать биндинги на каждый чих.

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

> Если ты этого не понимаешь, то пиши свой дебаггер, биндинги и т. д.

Есть два типа идиотов: одни пытаются _все_ данные _везде_ представить
в бинарном виде (или какой-нибудь сранью вроде XML), другие -- в виде
текста. Подумать, где нужно применять один способ, а где -- другой,
им не дано...

> input method'ы в виме так и не удосужились сделать...

А прочитать :h XIM слабо?

> В юникса программы работать в связке могут лишь обмениваясь через пайпы текстовыми потоками. Это Unix way by design. Не вижу в этом ничего предосудительного.

В этом Unix by design is broken. Потому что обмен проиходит последовательностями символов (происходил бы обмен объектами произвольного типа - это правильно (не надо мне говорить про print/read - я знаю, но это костыль, если реализуется прриложением - на уровне ОС/либ - пожалуйста)).

> А вообще, обмен текстовыми потоками через пайпы и сокеты гораздо удобней и гибче, чем писать биндинги на каждый чих.

RTFM на предмет Erlang.

> control я нажимаю ладонью, альт большим пальцем, шифт -- мизинцем.

Если _так_ скорячить руку, она отвалится через 5 минут.

> Удобно.

Простите за нескромный вопрос, Вы Камасутрой не злоупотребляете, а?

> До ескейпа тянутся тежело,

Не понимаю, зачем до него "тянуться": вот он, прям под пальцем.

> да и попадаешь не всегда.

Где ж трава такая растет?! Я тоже хочу!

> Ложь.

Как же ты все таки любишь аргументировать...

> Я не окулист, вылечить от красноглазости не могу, но тем не менее... Текст -- это далеко не оптимальное представление данных _для программы_. Поэтому, если интерфейс предназначен _исключительно_ для программы, на кой черт нужно перекидываться текстом?

Твои предложения? В общем, насколько я понял, юникс ты презираешь всеми фибрами своей души. Хотя, не можешь в этом признаться.

> И либо у emacs'а не работает Meta-S, либо не вводятся 8-битные символы.

У меня лично все работает, ровняй руки.

> Знакомая песня. Место таким поделиям -- на помойке, а их авторам -- в биореакторе (или на бирже труда, в крайнем случае).

Они пишут для себя в первую очередь. Этих ребят не волнует, что прийдет дселект и скажет про них, все что думает.

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

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

> Есть два типа идиотов: одни пытаются _все_ данные _везде_ представить в бинарном виде (или какой-нибудь сранью вроде XML), другие -- в виде текста. Подумать, где нужно применять один способ, а где -- другой,

Да, ты явно не понимаешь, что такое unix-way... им не дано...

>> В юникса программы работать в связке могут лишь обмениваясь
>> через пайпы текстовыми потоками.

> Ложь.

Обмениваясь последовательностями байт - писать в сокеты/сообщения непосредственно структуры - бред.

>> Это Unix way by design.

> К счастью, *NIX way не имеет ничего общего с этим идиотизмом.

Unix-way к сожалению не всегда следуют в Unix - тот же shell как язык программирования.

> Я не окулист, вылечить от красноглазости не могу, но тем не менее...
> Текст -- это далеко не оптимальное представление данных _для 
> программы_. Поэтому, если интерфейс предназначен _исключительно_
> для программы, на кой черт нужно перекидываться текстом? 

Чтобы сгладить различия ABI клиента и сервера. Особенно в случае если они написаны на разных языках.

>  emacs -nw

> И либо у emacs'а не работает Meta-S, либо не вводятся 8-битные символы.

А C-\ уже отменили?